A recent article on Slashdot points out with some chagrin that the Department of Homeland Security and Department of Veterans Affairs in the United States still use COBOL, originally invented in 1959, based on work by the late Rear Admiral Grace Hopper. The implication is—and has been for some years in the IT community—that COBOL is a completely dead language. Not so! In 1997, the Gartner Group reported that 80% of the world’s business ran on COBOL, and surveys in 2006 and 2012 by Computerworld found that more than 60% of large financial organizations use COBOL (more, in fact, than use C++, a much newer language), and that for half of those, COBOL was used for the majority of their internal code. The COBOL standard has continued to be updated, with the most recent change being in 2014.

There are, of course, problems with using a technology as venerable as COBOL; notably, almost no college or university IT programs teach it any more, and the population of coders who can use it is “aging out” and retiring. I learned COBOL in college, and used it in my first professional job, but in my late forties, I’m a little young for the rest of the COBOL crowd. Also, vendor maintenance for most COBOL compilers is growing more and more sparse, if it’s happening at all.

But if you want to delve into COBOL, there is an open source compiler. GnuCOBOL, which was initially released as OpenCOBOL in 2002. In 2013, version 1.1 was renamed to GnuCOBOL, and version 2 is, according to the core development team, “on its way to pre-release.” GnuCOBOL is licensed under the GPL, with the runtime libraries LGPL, so it would be usable for production code in any environment. There is an active community of users and developers, and documentation is extensive. The GnuCOBOL project is working toward keeping in line with the COBOL 2014 specifications, and to include non-standard features common in commercial compilers. The developers do not claim any particular level of standards compliance, but the current version passes more than 9,000 of the tests designed by the National Institute of Standards and Technology for the COBOL 85 test suite.

Strictly speaking, the GnuCOBOL system is a cross-compiler; it translates the COBOL statements into C code, which is then compiled using the GNU C compiler on the system. For this reason, GnuCOBOL is compatible with almost any system where GNU C is available—virtually any Unix or Linux system, Windows, and even Android and iOS. The GnuCOBOL compiler has proven usable in production, with minimal porting work from most mainframe operating systems to Linux systems. One of the features of COBOL is the ENVIRONMENT section of a code block, wherein you tell the compiler somewhat about the system on which it is running; most of the time, translations to Linux systems involve substantial change in the ENVIRONMENT block, but almost everything else just works.

COBOL was and is an entirely different method of programming, one that most computer scientists, even of its heyday, were not involved with. COBOL required a lot of thought about your data declarations, and to avoid truly chaotic code, thought needed to go into your execution paths. It wasn’t “bad,” although many academic computer scientists would tell you it is—merely different. I actually enjoyed my work in COBOL, although it is a typing-heavy language. I occasionally get a little bit nostalgic, and peek in at what is happening in the COBOL world. People have actually written web compatibility tools and frameworks, object-oriented programming, JSON handling libraries, and many other modern tools for COBOL.

For years now, the IT community has called COBOL “dead,” but with with projects like GnuCOBOL, it’s still very much alive, preserving legacy functionality, and developing new tools.