https://git.symas.net:443/cobolworx/gcc-cobol/ https://github.com/Apress/beg-cobol-for-programmers
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 (https://savannah.gnu.org/projects/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 asking. 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. --jkl
