Re: gcobol
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). I wonder if I can make build that front end with the pdp11 back-end. :-) I wasn't aware it was still possible to build the PDP-11 back-end. I thought support for that was dropped ages ago. bill
Re: gcobol
On 2022-03-14 6:53 p.m., 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... I wonder if I can make build that front end with the pdp11 back-end. :-) Good question. Does any one have card reader hooked up to modern machine? paul Ben.
Re: gcobol
I have a serial Documation M-1000. Not running at the moment, but adequate for such Two more M-600 parallel, and I think the number for the dinky one is M-150, also parallel. interface would go thru an arduino with 5v board easily to a USB serial or whatever (Ethernet maybe) thanks Jim On 3/14/2022 6:53 PM, ben via cctalk wrote: Good question. Does any one have card reader hooked up to modern machine? paul Ben.
Re: gcobol
On 3/14/2022 6:53 PM, ben via cctalk wrote: Good question. Does any one have card reader hooked up to modern machine? paul Ben. On Mon, 14 Mar 2022, jim stephens via cctalk wrote: I have a serial Documation M-1000. Not running at the moment, but adequate for such Two more M-600 parallel, and I think the number for the dinky one is M-150, also parallel. interface would go thru an arduino with 5v board easily to a USB serial or whatever (Ethernet maybe) thanks Jim I have a Documation M-1000L with a USB interface designed by Brian Knittel. I've used it to recover FORTRAN and data decks. Mike Loewen mloe...@cpumagic.scol.pa.us Old Technology http://q7.neurotica.com/Oldtech/
Re: gcobol
> On Mar 14, 2022, at 9:05 PM, Bill Gunshannon via cctalk > 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. And GnuCOBOL is a COBOL to C converter. gcobol is a full front end. One difference is that GDB will be able to do COBOL mode debugging. >> I wonder if I can make build that front end with the pdp11 back-end. :-) > > I wasn't aware it was still possible to build the PDP-11 back-end. I > thought support for that was dropped ages ago. No, it's still there. I picked it up when it needed a maintainer. It's actually been upgraded to deal with GCC changes, for example the new condition code handling which produces somewhat better code. (Also the new register allocator, as an option, which unfortunately produces somewhat worse code.) paul
Re: gcobol
On 3/14/22 19: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... I rejuvenated some old Pascal programs using the FPC (Free Pascal Compiler) that is basically the same idea. It was designed to take Borland Turbo Pascal and DEC Pascal extensions, and did quite well with it. In 1996 I built a laser photoplotter and wrote a Turbo Pascal program to convert Gerber photoplotter language to raster strips and run the plotter directly off the PC with a DMA card. That computer was getting REALLY old, and I was worried about keeping it working, so I migrated the plotting to a Beagle Bone with the PRU microcontroller emulating the DMA card. Then, I migrated the Gerber-raster converter program to FPC and cleaned it up a bit. Jon
Re: gcobol
On 3/15/22 09:12, Paul Koning wrote: On Mar 14, 2022, at 9:05 PM, Bill Gunshannon via cctalk 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? 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. I wonder if I can make build that front end with the pdp11 back-end. :-) I wasn't aware it was still possible to build the PDP-11 back-end. I thought support for that was dropped ages ago. No, it's still there. I picked it up when it needed a maintainer. It's actually been upgraded to deal with GCC changes, for example the new condition code handling which produces somewhat better code. (Also the new register allocator, as an option, which unfortunately produces somewhat worse code.) I may take a look at that although I'm a K&R kinda guy so things like DEC C and DECUS C are usually fine with me. bill
Re: gcobol
> On Mar 15, 2022, at 12:39 PM, Bill Gunshannon via cctalk > wrote: > > On 3/15/22 09:12, Paul Koning wrote: >>> On Mar 14, 2022, at 9:05 PM, Bill Gunshannon via cctalk >>> 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
Re: gcobol
On 3/15/22 12:57, Paul Koning wrote: On Mar 15, 2022, at 12:39 PM, Bill Gunshannon via cctalk wrote: On 3/15/22 09:12, Paul Koning wrote: On Mar 14, 2022, at 9:05 PM, Bill Gunshannon via cctalk 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
Re: gcobol
> On Mar 15, 2022, at 1:18 PM, Bill Gunshannon via cctalk > wrote: > > On 3/15/22 12:57, Paul Koning wrote: >>> ... > 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. :-) Same here since I'm not a COBOL programmer. What I meant: COBOL has data types like decimal numbers, which C doesn't seem to have. So how would GDB view such a variable? How would you enter a value if you want to change it? paul
Re: gcobol
On 3/15/22 13:31, Paul Koning wrote: On Mar 15, 2022, at 1:18 PM, Bill Gunshannon via cctalk wrote: On 3/15/22 12:57, Paul Koning wrote: ... 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. :-) Same here since I'm not a COBOL programmer. What I meant: COBOL has data types like decimal numbers, which C doesn't seem to have. So how would GDB view such a variable? How would you enter a value if you want to change it? Good point. Might have to check it out just out of curiosity. Last time I used any debugger was adb on System V 30 some years ago to patch some M68K kernels. The closest I have come to that level of debugging in a long time is to use -S option and read thru the assembler generated by the compiler. bill
Re: gcobol
On Tue, 2022-03-15 at 09:12 -0400, Paul Koning via cctalk wrote: > > We already have GnuCOBOL which works just fine (most of the time). > > Yes, although that one is apparently more limited. And GnuCOBOL is a > COBOL to C converter. gcobol is a full front end. One difference is > that GDB will be able to do COBOL mode debugging. The NAG Fortran compiler is a Fortran-to-C translator. One can do Fortran-mode debugging.
