15 Mar
2022
15 Mar
'22
1:18 p.m.
On 3/15/22 12:57, Paul Koning wrote:
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
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.
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
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:
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.) 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. 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? 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.