[Info-vax] VMS Cobol - GnuCOBOL

[Arne Vajhøj]

On 2/22/2023 8:16 AM, bill wrote:
> On 2/22/2023 7:52 AM, Scott Dorsey wrote:
>> Paul Gavin  <paulgavinco at gmail.com> wrote:
>>> Having attempted to move sample code from two flavors of COBOL code 
>>> (OpenVM=
>>> S terminal and HP-UX ANSI format) to GnuCOBOL, I had to modify every 
>>> commen=
>>> t and most continuation lines to get them to compile. Shell script 
>>> was fair=
>>> ly simple to write to fix these issues, but still changed the code. 
>>> None of=
>>> the VMS code used by descriptor calls in the main code, but calls to 
>>> syste=
>>> m services on both side were a pain. Both had database precompiler 
>>> needs (C=
>>> ODASYL and Informix) and those certainly would not work at all.=20
>>
>> The comment and continuation issues are addressed with compiler flags.
>> Not that updating the code that way might not be a good idea anyway.
> 
> I wold love to hear why people might think that GnuCOBOL isn't
> ready for production use.  And unreadable C intermediate code
> is not a valid reason as it was never intended to be read or
> modified by humans any more than the RTL in other compilers
> or the assembler they generate.

The original comment seems to relate to source format.

My (extremely small) experience is that if I move Cobol
code written as I (a non-Cobol programmer) write Cobol
from VMS to PC and compile with GnuCOBOL using -free
switch the it works.

But I do see a few issues:
1) indexed files where options are:
      - BDB and release your code under GPL
      - BDB and pay Oracle
      - VBISAM and live with what it doesn't support
2) the performance of COMP-3 arithmetic is
    horrible
3) it has a weird approach to endianess on disk:
      - default COMP are stored big endian not native
      - COMP-1 and COMP-2 are stored native

Arne