Announcement: gcobol

James K. Lowden
Mon Mar 14 20:34:37 GMT 2022

Greetings, gcc!  We come bearing gifts! 

When you set your clock ahead an hour yesterday, you might not have
realized you set your calendar back to 1985.  There's a new gcc COBOL
compiler. We call it: gcobol.

On the books, we have 1 man-year invested: two full-time
programmers since October 2021.

We have so far compiled just over 100 programs from the examples in
"Beginning COBOL for Programmers", by Michael Coughlin. We are near the
end of that phase of the project, and expect to have ISAM and
Object-Oriented Cobol features implemented in the next few weeks.  We
are working on compiling the NIST COBOL test suite, which we expect
will take a few months to complete.  We have begun work on  gdb, too,
and hope to have it working by year end. 

Our project should not be confused with GnuCOBOL
(  That project is a Cobol
translator: it compiles Cobol to C, and invokes gcc to produce
executable code.  Our gcobol compiler is (currently) a fork of gcc.  It
implements a gcc frontend for Cobol and (obviously) invokes the gcc
backend to produce executables.  (We have a friendly relationship with
GnuCOBOL, and its maintainer supports our undertaking.)

Ours should also not be confused with prior efforts to create a gcc
Cobol compiler.  Others have tried and failed.  Failure wasn't an
option for us.  I won't say it was easy, but here we are. 

Eventually, if the gcc maintainers are interested, we would like to
pursue full integration with gcc.  For the moment, we have questions
we're hoping can be answered here by those who ran the gauntlet
before us.  Given the state of the internals documentation, that seems
like our best option. We've been rummaging around in the odd sock
drawer for too long.  

If you're like me (like I was), your visceral response to this
announcement can be summed up in one word: Why?

The answer is as easy as it is trite: the right tool for the job.

I wouldn't write an operating system in Cobol.  But I wouldn't write
one in Python or Java, either.  Cobol has a niche no other language
occupies: a compiled language for record-oriented I/O.  

That might sound strangely specialized, but it's not.  Record-oriented
I/O describes, I would argue, nearly *all* applications.  Yet, since the
advent of C, nearly all applications have relegated I/O to an external
library, and adopted the Unix byte-stream definition of a "file".

If you've written a CGI web application, you know what I'm talking
about.  Cobol eliminates a lot of gobbledygook by reducing free-form
run-time variables to compile-time constants.

That's the rationale, and it's not just a theory.  Cobol is alive and
kicking.  Estimates vary, but they all say north of 100 billion lines
of Cobol are still in use, with millions more written every year, even
now, in the 21st century.  Odds are your last ATM transaction or credit
card purchase went through a Cobol application.

There's another answer to Why: because a free Cobol compiler is an
essential component to any effort to migrate mainframe applications to
what mainframe folks still call "distributed systems".  Our goal is a
Cobol compiler that will compile mainframe applications on Linux.  Not
a toy: a full-blooded replacement that solves problems.  One that runs
fast and whose output runs fast, and has native gdb support.

I am happy to debate the lunacy of this project and the viability of
Cobol, either here or off-list.  Today, we want to make the project
known to those in the technical community who might most want to know
what we're up to, and explain why we'll be asking the questions we're

Also, if you want to give it a whirl, please don't hesitate.  We're
happy to help, and expect to learn something in the process. 

Thank you for you kind attention.


More information about the Gcc mailing list