On COBOL and Legacy Systems

Two recent articles1 (and I’m sure there are more which I haven’t seen yet) responding to a call for help from Gov. Phil Murphy of New Jersey decry the continued use of the COBOL programming language in legacy systems which have been in place for decades.

What’s irritating about these articles is the notion that COBOL is outmoded, outdated, old fashioned, because the language was first defined and implemented more than 60 years ago, and the applications which are having issues currently were written more than 40 years ago. I say, so what?

I spent several years—40 years ago!—programming in COBOL, supporting the financial systems of the University of Chicago. The most important thing to remember in financial systems is the maxim, If it ain’t broke, don’t fix it! The second is When it breaks, fix it right!

COBOL had two standards when I used it in my job, from 1968 and 1974. The differences were minuscule, mostly tightening up some ambiguities and eliminating minor features which had proven unuseful. Since then, new standards addressing new conditions came out in 1985 (structured programming primitives, freeform source permitted), 2002 (object-oriented paradigm added), and 2014 (whose changes I haven’t seen, yet, but I will, just because). Contrast this stability with the weekly updates from Microsoft, Apple, and the GNU/Linux communities.

The article by Steinberg points to the “pain” suffered in legacy systems when the so-called Y2K bug was a concern in the late 1990s. As those of us in the industry since the late 1960s are aware, that was a great deal of worry over nothing, because we had been aware of the possibility of our systems lasting that long when we wrote them. Yes, there were managers who insisted that none of this code would last long enough for two-digit years to be an issue, but front-line programmer/analysts who were supporting legacy code from the 1950s knew better, and did the right thing.

Those who do not know COBOL buy into the notion that somehow it is less secure because it is old, but data security has always been a concern in financial systems in traditional data processing shops, where the mainframe has been king all along. Who has ever heard of an on-line exploit targeting a weakness of a COBOL program running on a mainframe operating system, whether IBM or Unisys?2 The security systems created for those operating systems have always been strong, and were very rarely (never?) retrofits trying to fix weaknesses discovered by crackers.3

So, in my not so very humble opinion, the call to scrap these legacy systems and redo all the work in the flavor of the moment system is misguided, to say the least. The governor has the right idea: Get some people who know COBOL to fix the problems the right way, perhaps updating the language used where that is called for, and move on smartly. His call for “volunteers” to do the work is a wistful dream, of course, because the people who can do this work command hourly rates in the range of $200/hour, but they’re out there if the State of New Jersey is willing to do things right.

                                                                Of course, that’s just my opinion. I could be wrong.
                                                                                                                             –Dennis Miller

  1. COVID-19 Response: new Jersey urgently needs COBOL programmers (yes, you read that correctly) and Coronavirus pandemic signals need for COBOL computer programmers
  2. Sadly, there just aren’t that many mainframe class systems manufacturers any longer.
  3. I’m not the first to defend COBOL by a long shot. See the following from 2016: Exactly what is COBOL and why is COBOL still a widely used language in IT?