gcobol

[Bill Gunshannon]

On 3/15/22 12:57, Paul Koning wrote:
> 
> 
>> On Mar 15, 2022, at 12:39 PM, Bill Gunshannon via cctalk <cctalk at classiccmp.org> wrote:
>>
>> On 3/15/22 09:12, Paul Koning wrote:
>>>> On Mar 14, 2022, at 9:05 PM, Bill Gunshannon via cctalk <cctalk at classiccmp.org> wrote:
>>>>
>>>> On 3/14/22 20:53, Paul Koning via cctalk wrote:
>>>>> Saw a note on the GCC list that I thought some here might find interesting: it announces the existence (not quite done but getting there) of a COBOL language front end for GCC.  Interesting.  For those who deal in legacy COBOL applications that want a more modern platform, I wonder if this might be a good way to get there.  Run old COBOL dusty decks on Linux, yeah...
>>>>
>>>> We already have GnuCOBOL which works just fine (most of the time).
>>> Yes, although that one is apparently more limited.
>>
>> In what way?
> 
> I thought I saw a comment to that effect in the announcement; looking more closely that isn't the case, other than the limitations you get from going through C as an intermediate language.  (Same sort of reason why the C++ to C converter is no longer used.)

Same comment.  I have done quite a bit of COBOL with GnuCOBOL and
find no limitations other than things they haven't implemented yet.
I am not expecting the OO stuff but then I don't know any real COBOL
programmers who are.  :-)  I have taken examples of COBOL I could
find from IBM Mainframes, and other systems and other than the
obvious modifications of things like file names I have not found
anything that doesn't migrate.  Would love to get other examples
from Systems like Univac, Primos, VMS, etc. to see how easily (or
hard) they migrate.

> 
>>> And GnuCOBOL is a COBOL to C converter.  gcobol is a full front end.
>>
>> Is there some shortcoming in using C as an intermediate language?
> 
> Yes, debugging.  It means the debugger sees a C program, and it's somewhere between difficult and impossible to apply the original source semantics while debugging.

Interesting. The explanation in the FAQ seems to disagree with that
but as I said, I have never run into a problem that couldn't be
debugged using the source and my brain.  COBOL just isn't that
complex.  The last time I did have to do anything like that was
on a 4331 running VM370 about 40 years ago.  IBM made it real easy.

> 
>>> One difference is that GDB will be able to do COBOL mode debugging.
>>
>> Never had a reason to try it but I thought GnuCOBOL allowed the use
>> of GDB.  FAQ seems to say it can be used.
> 
> Yes, but presumably in C language mode.

But I thought there was a comment that because of the liberal use
of comments it was easy tracing a problem back to the COBOL source.

I'll probably never find out.  :-)

bill