On 3/15/22 12:57, Paul Koning wrote:


On Mar 15, 2022, at 12:39 PM, Bill Gunshannon via cctalk 
<cctalk@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@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

Reply via email to