gcobol

Paul Koning paulkoning at comcast.net
Tue Mar 15 11:57:30 CDT 2022



> 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.)

>> 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.

>> 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.

	paul



More information about the cctech mailing list