Message from SHARE: A Full-Throated Defense of COBOL

By Scott Fagen, SHARE Director of Industry Influence

Over the past few months, many facets of the world have been changing because of the outbreak of COVID-19. We’re learning about new concepts like “pandemic,” “shelter-in-place,” “social distancing.” We’re learning that those in positions of responsibility will say almost anything to avoid being blamed for the failures of the agencies and systems under their purview. While not a new thing, we’re re-learning that it’s easy to blame something that has no voice nor ability to respond. We’re learning that COBOL, a programming language, is at cause in the failure of millions of people trying to claim benefits promised by their governments.

I am here to give a full-throated defense of COBOL. Here it is so you can quote me:



That’s right I have no defense for COBOL. Not because it is indefensible, but rather, no defense is necessary.

If the walls of your house, built with hammer and nails, fell down after 40 years of trouble-free service (and little to no maintenance), would you blame the hammer and nails because there were screwdrivers and screws available since the building of the walls? Would anybody feel compelled to defend the poor hammer, its being so old and obsolete?

COBOL is a programming language, a tool used for the last 60+ years to encode data definitions and algorithms that a computer can execute to produce some result. Other than being older than many programming languages and younger than a few, COBOL behaves in the same way as any programming language. Every programming language has two primary distinguishing characteristics that are apparent to the programmer: a vocabulary (what words you use to describe your program) and a grammar (how you arrange those words so that the program can be understood and executed). These characteristics are what distinguishes COBOL from C from C++ from Java, etc.

Beyond these two characteristics are important distinctions in how the program becomes executable for the computer (compiled, interpreted, JITed) and the set of tools that helps designers and developers correlate and collate their programs. And while these languages may take different paths to the CPU, they are all ultimately processed in the native machine language of the computer system where they are run.

Unless we are going to undertake a highly specialized task, the programming language is an interchangeable part of the design and development mix. In today’s world, I probably would not start a clean-sheet application with COBOL, and there are also many reasons why I wouldn’t “rip and replace” an existing system written in COBOL. First and foremost, software doesn’t rust and it doesn’t wear out. A computer program written in any higher level language will continue to provide the same service as the day it was written.

In fact, a key reason driving the development of programming languages was to provide “machine independence.” Early programs, written in machine or assembler code, were not portable to other machines or architectures. When the new computer was rolled in, all the programs had to be rewritten. A compiled or interpreted higher level language allowed the users of the program to be able to run the program on different computers as time moved on. In the world of COBOL, a program written in 1959 would likely still compile and run today (orders of magnitude faster and more efficiently) on a machine that bears little resemblance to its primitive ancestor.

Second, and more importantly, there is inherent risk in trying to reimplement a system, and the risk increases as the size and complexity of the system increases. From a business perspective, why spend months or years of development time to accomplish the goal of rewriting the application into a different language with the same exact capability? What is the cost of misinterpreting the current system and what are the odds of the new system not behaving like the old one?

If a contractor came to you and said, “Hey, your walls are held up by nails. Let’s say we take those walls down and put them all back up in the same places with screws?” What would you do? How much would you pay for the same structure?

So, finally, what is responsible for the failures in these systems? Let’s just consider two circumstances that are contributing to the problems we’ve been seeing in the news. In order for there to be a successful roll out of any new or changed governmental program that relies on an IT system, two things must be true (regardless of whether the system was programmed in COBOL or any other language):

  1. The IT system must be updated (programmed) to encode the new and changed elements of the governmental program, including understanding where the changes need to be made, updating the programs, and testing the programs.
  2. The underlying hardware (compute, memory, network, storage disk/tape) must be evaluated to ensure that there is enough to handle the anticipated increase in the load.

It would appear that in the publicized cases, neither of these was handled satisfactorily. Consider some of the “facts” that have been presented:

“COBOL is an IBM proprietary language.”

The reality of the situation: COBOL was designed by a consortium of public/private entities, with a number of different companies producing COBOL compilers for their computer systems. To this day, COBOL has a standards body (outside of IBM) which directs the evolution of the language.

“The state agency runs on a 40-year-old system.”

To this I would say, “Amazing!” The hardware and software were so well built that, during a period where the population of the United States increased by nearly 50%, a computing system designed and built in 1980 was able to manage the increases in load, with no memorable outages, until this unprecedented wave of unemployment hit the system.

The reality of the situation: While the state agency has likely never been on the latest technology, the mainframe supporting this and other applications really can’t be much more than nine years old (z114). Given that laws and programs change over time, it’s also highly unlikely that the COBOL programs processing the claims are exactly the same as when rolled out in 1980.    

“It will take months to do all the work.”

The reality of the situation: Management has no idea how long the changes will take. There just aren’t enough skilled people on staff to do the evaluation. The system has run so well for so long (it’s been 40 years) that inevitable cuts in funding/staffing have resulted in COBOL skills being let go first (or not replaced on retirement). This sort of management philosophy is not lost on the developers within these agencies and they will stay away from COBOL like it’s a plague.

“Citizens are having trouble getting onto the website to make claims.”

The reality of the situation: While the COBOL application will be involved with processing claims, it is unlikely to be part of the interaction with the claimant on their browser. It is more likely that there just isn’t sufficient capacity within the servers (on-prem or cloud) used to host the website and application.

“We are looking for volunteers to solve this problem.”

The reality of the situation: While I tip my hat to anyone who comes out gratis to solve this problem, this is just another symptom of the mismanagement that created the current situation. There are two clear choices to break the cycle:

  1. Staff to appropriate levels, through hiring and training to keep the application current.
  2. Bite the bullet and rewrite the application in a “modern language.” Spend the money and take the risk.

While #2 is much more exciting, #1 is almost always more economical and less risky. You don’t have to look far for highly successful systems that have been and continue to be largely in COBOL (or PL/I, another language used on mainframe computers):

  1. Banking
  2. Credit Card Processing
  3. Finance
  4. Insurance
  5. Retail
  6. Logistics

While it’s true that these systems have been enhanced with “modern languages,” like C++ and Java, and have distributed components, the lion’s share of the code that ultimately processes the transaction remains in COBOL.

To conclude, I will leave you with these two aphorisms:

  1. Don’t fix it if it ain’t broke.
  2. It’s a poor craftsman who blames his tools.
Recent Stories
Mainframe Jargon and Shibboleths

Pervasive Encryption: Upgrading AT-TLS to TLS 1.2 or 1.3

Message from SHARE: Year In Review