14 Mar
2022
14 Mar
'22
5:53 p.m.
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. :-)
paul
14 Mar
14 Mar
6:05 p.m.
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
15 Mar
15 Mar
6:12 a.m.
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:
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.
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.
9:39 a.m.
On 3/15/22 09:12, Paul Koning wrote:
In what way?
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
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:
Yes, although that one is apparently more limited. 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). 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.
9:57 a.m.
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:
Yes, although
that one is apparently more limited. 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). 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.
10:18 a.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.
10:31 a.m.
On Mar 15, 2022, at 1:18 PM, Bill Gunshannon via
cctalk <cctalk at classiccmp.org> wrote:
On 3/15/22 12:57, Paul Koning wrote:
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
> ...
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.
10:38 a.m.
On 3/15/22 13:31, Paul Koning wrote:
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
On Mar 15, 2022, at 1:18 PM, Bill Gunshannon via
cctalk <cctalk at classiccmp.org> wrote:
On 3/15/22 12:57, Paul Koning wrote:
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? > ...
> 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.
11:30 a.m.
On Tue, 2022-03-15 at 09:12 -0400, Paul Koning via cctalk wrote:
The NAG Fortran compiler is a Fortran-to-C translator. One can do
Fortran-mode debugging.
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. 
14 Mar
14 Mar
6:53 p.m.
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.
7:38 p.m.
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.
10:11 p.m.
On 3/14/2022 6:53 PM, ben via cctalk wrote:
Good question. Does any one have card reader hooked
up to modern machine?
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 mloewen at cpumagic.scol.pa.us
Old Technology http://q7.neurotica.com/Oldtech/
????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 
15 Mar
15 Mar
9:31 a.m.
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
1014
days inactive
1014
days old
12 comments
7 participants
participants (7)
-
bfranchuk＠jetnet.ab.ca -
bill.gunshannon＠hotmail.com -
elson＠pico-systems.com -
jwsmail＠jwsss.com -
mloewen＠cpumagic.scol.pa.us -
paulkoning＠comcast.net -
van.snyder＠sbcglobal.net