Rumors of COBOL's demise have been greatly exaggerated: Meet GnuCOBOL

6 readers like this
6 readers like this
COBOL programming language

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 transpiler; 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.

Ruth Holloway has been a system administrator and software developer for a long, long time, getting her professional start on a VAX 11/780, way back when. She spent a lot of her career (so far) serving the technology needs of libraries, and has been a contributor since 2008 to the Koha open source library automation suite. Ruth is currently a Perl developer and project lead at Clearbuilt.


I worked in COBOL for the first 8 years of my programming career. If you ever see an ancient program with ADD INSULT TO INJURY. in it, chances are it's one of mine! I always included that statement somewhere in my code.


You're not the only one to do that, Marty; such snark as ADD INSULT TO INJURY was humor I spotted fairly-often at the religious institution where I was working in my COBOL days. With the wordiness of the language, there were lots of such things you could easily add in. COBOL coders are a different breed, to be sure...

In reply to by MartyMonroe

West Texas A&M University computer science has a four course track on enterprise computing, including a whole semester in COBOL. The annual IBM Master the Mainframe contest introduces students to the language. It's still being taught, you just have to seek it out.

That's impressive. I was pretty miffed when Purdue stopped teaching Fortran in the mid 00s. It certainly wasn't a cool language by then, but it was heavily used in the geosciences (particularly in weather modeling), and I thought it would be a useful class for me to take as part of my meteorology degree. I ended up filling my CS elective with a Matlab class instead. It was not helpful.

In reply to by Vance Morris (not verified)

Unlike C++, Java and all the rest, which are "Object Oriented" languages, COBOL is "PROCESS ORIENTED". Process orientation is better for business applications.

Hello Ruth,
your article magically brought a smile into my face. :)
In the 90s of the last century until 2006 I worked for a large Insurance Company as COBOL programmer on IBM Mainframe with OS390 - a lot of work in "Year 2000" and "EURO currency" projects. It was a great time I don't want to miss.
The time I left the company, there were more than 25.000 COBOL Programs under maintenance. 2 months ago I had a lunch with my "old" colleagues from that time. The amount of COBOL programs there has not decreased significantly.

COBOL is dead, long live COBOL! ;)

Thanks a lot for this very nice article.

COBOL is actually a top 20 programming language. It hasn't gone anywhere and it isn't going anywhere anytime soon.

Isn't GNU Cobol an extremely incomplete implementation? I recall reading that only proprietary compilers are up to date with current COBOL standards

In my poking around, I did find some notes that it's not *completely* up to standard. The GnuCOBOL team makes a point of saying that they do not *guarantee* any particular level of standards-compliance, that they do work for as much as they can; it's a small niche, and they don't have a lot of developers working on it.

Proprietary compilers, naturally, have a solidly-vested interest in maximum compliance, particularly if it lets them talk smack about community-driven efforts. But it is those communities that is interested in. :)

In reply to by Ryan McCoskrie (not verified)

I'm going to say no to that question, Ryan. Quite the opposite. GnuCOBOL is a surprising complete implementation of COBOL. GnuCOBOL does not have any Object COBOL features, yet, but I think you'd be hard pressed to find a feature from COBOL 85 that isn't fully supported. And you will likely be pleasantly surprised at the depth of coverage of other 2002 features. Only a few pieces of the 2014 Compiler Directive and Text Manipulation Facility are yet to be written.

As far as I known, GnuCOBOL was one of the first compilers to implement some of the new 2014 spec. For instance, ISO 8601 compliant FUNCTION FORMATTED-CURRENT-DATE. There is also a growing body of free software User Defined Function repositories. One of the first things that happens after the 2.0 pre-release show is moving the fully featured ReportWriter branch into trunk.

But, go ahead and try it, Ryan, GnuCOBOL is a GNU free software project. Need some critical piece of support for your COBOL treasure pile? You are free, and encouraged, to modify the compiler to meet needs and desires. And although the development team is small, it is growing, and always up for helping with simple, and complex, COBOL programming challenges.

Full disclosure, I'm completely biased in my opinion, having spent a good part of the last 8 years building up a 1,200 page document exploring the potentials of COBOL in the internet era, all centered around GnuCOBOL and its C roots. A C++ emitting version also exists if that is more appropriate to wants and needs. Integrate and embed Rexx, Python, Ada, Fortran, MathGL, Vala/Genie, GTK, Tcl/Tk, Node.js, Java, Nim, Javascript, GRETL, BASIC, REBOL/Red, you name it. As far out as working samples for esoteric programming with Piet and Shakespeare embedded in COBOL programs, but that was just for fun.

In reply to by Ryan McCoskrie (not verified)

> Isn't GNU Cobol an extremely incomplete implementation?

No. It is the other way around. GnuCOBOL is an extremely complete implementation.

In our own case, we had over 200,000 lines of COBOL-74 code that we converted to GnuCOBOL. 100% of the COBOL-74 lines compiled and ran correctly. The only lines that did not compile were SELECT and extended ACCEPT statements (which are not under COBOL standards).

We have used GnuCOBOL to modernize the code to COBOL-85. We have found very few instances where GnuCOBOL came up short.

In reply to by Ryan McCoskrie (not verified)

Hello Ruth,

I'm started using COBOL (RM/COBOL to be exactly) in the late of 80s, and since then I'm still using it (AcuCOBOL since around 1996 IIRC), until today. I'm currently maintaining an old application for a couple of companies here in Catalonia.

Of course, programming COBOL is no longer my main daily job. So C, ASM and Perl languages need to co-exist (from time to time) with COBOL! :-)

Thanks for your article!

I'm tickled that old code lives on, but there is a dark side. The "if it's not broke, don't fix it" has a strong allure and is not without merit, but as support becomes more and more spotty, "work-around" broke becomes less likely than "drop-dead" broke. With no disrespect to the working code out there, if it really is a larger code base than all of C++ then there is a substantial risk of disruption.

Cross-compiling to C suggests that code could live on indefinitely but (assuming the generated C code is in fact readable) you have a code set which the maintainers cannot read requiring maintainers who don't understand the code. It doesn't sound very appealing to me.

I don't think you actually see the C-code. As far as I recall, the GNU compiler system only has one final compiler that converts to machine code. All the languages that are supported need to initially compile to one master (wikipedia calls it abstract, syntax free), which must be at the very least, a superset of C, and then that is compiled to the final machine code.

In reply to by John Navratil (not verified)

I will give you the C code source if you use the -C compiler option.

In reply to by John Navratil (not verified)

Very interesting article.

I would add that there are a number of online resources available to learn the COBOL language. Vance mentioned a great program from IBM already. For those that prefer a self-directed approach, I'd encourage you to take a look at this site:

You can download a FREE version of modern COBOL. The download includes a free tutorial to learn procedural and modern COBOL programming with code samples. Definitely worth a look.

I paid a fortune to learn COBOL in the late 80's here in the Philippines. All our textbooks have 'Structured COBOL' in their titles and we all thought we were learning structured programming -- until I started learning Pascal and later C. I never got the chance to ask our instructor how the COBOL program he taught us to write could ever be called 'structured'.

If you have and use the proper discipline, and truly understand what makes for a structured program, a structured program can--and indeed should be--written using any language.

In reply to by Emmanuel Celiz (not verified)

COBOL is no more dead than FORTRAN, which is even older.

It's been popular with various levels of government as well.
Some use pre-processor validation, but there's no guarantee that tool knows Standard.

I was using COBOL for most of my programming career, from 1980 until 2001.
I still like the way that it is intuitive, procedural, and relatively easy to debug.
I would say check out Microfocus COBOL, which can be run in VS Studio.

"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."

Um, that's a transpiler. A cross-compiler is a compiler that runs on one machine but produces executables that run on a different machine. If you're going to write "strictly speaking", please verify that you are being accurate ... especially if you are writing about something that you clearly are not familiar with.

"Given enough eyes, all bugs are shallow." While I've been in the IT trade--not just journalism--for a great many years, I'd never spotted that distinction. Thank you for the note; I've made a correction to the article.

In reply to by Marcel Kincaid (not verified)

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.