Misunderstanding the Need for “COBOL Programmers”

Posted May 7, 2020 in Business Technology & Digital Transformation Strategies
Misunderstanding the Need for “COBOL Programmers”

This is not another COVID-19 story, although our new social and economic conditions have given rise to the visibility of an enormous problem that has been lurking in our information infrastructure for a long time. Rapid and unprecedented changes to the unemployment laws have created both a tidal wave of transactions that need to be processed, and significant changes to the programmed business processes that execute those transactions.

Those business processes are entombed in old COBOL code on old mainframe systems. People are starting to panic about needing COBOL programmers. Yes, but.…1


Let’s start there. There is nothing mysterious or especially difficult about it. Compared to JavaScript, Python, and any other modern program languages, COBOL is certainly more teachable and learnable. That is not the problem, and teaching COBOL will not solve anything. “Teach them to code.” Yes, but….

There is a huge misunderstanding of the problem, and it’s all based on ... a huge misunderstanding of the solution. When you hear people say “COBOL,” what they most likely are talking about is the millions (or maybe billions) of programs written in COBOL and running on systems that nobody understands. It’s not the language that’s the challenge, it’s the platform — and the platform is probably good old IBM mainframes.

It takes a book to describe the architecture of an IBM mainframe, mostly because it has evolved over 50 or so years. And unless you were along for the ride, it’s a daunting task to merely open a book and figure it out. A lot of it only makes sense in the historical context of IBM’s sometimes heroic efforts to maintain backward compatibility (a task at which they excelled) and the actual underpinnings of the so-called COBOL problem. The stuff that someone wrote 35 or 40 years ago is still there, and still works. The changes to that stuff that someone else made (perhaps to solve the Y2K problem), well, that’s still there, too. But the platform has evolved, always maintaining life support for the applications. Without this perspective, and the ability to picture the environment as it was at the time the program was written, a person will stare at a screen full of code and wonder why on earth the programmer wrote it. It makes no sense. But in context, it makes a world of sense. It’s not the code that’s the problem, it’s the context.

Context is everything, and here’s where it gets really interesting very quickly. Pushing aside all the wonderful and novel computing concepts that have engaged the ambitions and interests of computer scientists over the ensuing decades, let’s consider just business transactions. Surely these have not entertained academia and commercial think tanks, but they are the basis of the current “crisis.” Good old transaction processing — nice, safe, simple, mundane, transaction processing. Debit this, credit that; journal this, journal that. And please remember to save all work. Why is it so hard? There are three reasons.

So Why Is It So Hard?

Reason 1: The Brain Space

Interaction between simple programs, no matter the language and the environment in which they’re running, requires a particular knowledge, not only of the conceptual facilities, but in the way the various components stitch together and one’s ability to “see” the interactions. Writing a program that sits in a little logical container and does something in a huge, shared environment requires an understanding of the edges at which the program interfaces with the environment.

Reason 2: The Tower of Babel

I’m going to go out on a limb here and tell you that there’s a very limited number of things that a good, common, business-oriented program will do. But it has to talk to the environment. Try this experiment: find a reasonably good programmer under the age of, I don’t know, let’s say 35. Give that programmer a copy of the ANSI standard description of COBOL, then ask for a simple program to be written for the mainframe system. No cheating … we’re not merely changing something that’s already in place, we’re writing something new. The COBOL will take about 40 minutes to write, if that, but along comes z/OS, CICS, VSAM, VTAM, SNA, DB2, ISPF ,LU2, LU6.2, CPI-C, JES, JCL … and so on. What are these strange things? How do they work? How do they interact? What’s a RACF, and why is it important? And why isn’t there one now? Where did it go?

“Oh, wait … did you mean that the SNA CPI-C LU6.2 MFH type 5 is really the same as a TPC RPC? Cool!”

Reason 3: Evolution Exists As a Continuum

In order to understand what is going on in a piece of legacy programming, regardless of the language, you must understand the environment it was written for as it existed at the time the program was written. Think about that. Are there better ways to accomplish this? Probably, yes, there are, now. So why is it done this way? Well, maybe there weren’t, then. There’s an old saying, “When the only tool you have is a hammer, everything looks like a nail.”

COBOL, as used now by the few who actually use it, may not even resemble the COBOL of yesteryear. A quick note about “COBOL,” quoting from IBM’s website:

Standard COBOL refers to the COBOL programming language as defined in the document entitled American National Standard for Information Systems - Programming Language - COBOL, ANSI X3.23-1985, ISO 1989:1985, updated with the content of the following documents, in the order they are listed:

  • ANSI X3.23a-1989, American National Standard for Information Systems - Programming Language - Intrinsic Function Module for COBOL and ISO 1989:1985/ Amd.1:1992

  • Programming Languages - COBOL, AMENDMENT 1: Intrinsic function module

  • ANSI X3.23b-1993, American National Standard for Information Systems - Programming Language - Correction Amendment for COBOL

  • ISO/IEC 1989 DAM2 Programming Languages - COBOL, AMENDMENT 2: Correction and clarification amendment for COBOL.

  • FIPS Publication 21-4, Federal Information Processing Standard 21-4, COBOL

Things evolve. Any student of modern American history knows that things are not the same in 2020 as they were in 1970. Not culturally, politically, economically, and certainly not technically.

Fixing It

So, what next? Well, as always, we somehow muddle through the next disaster and emerge somewhat unscathed, and there are options.

  • Drag the old guys back into the battle. This may provide some short-term relief, but I refer you to the term “old guys.”2 This is not a solution. Whether motivated by altruism or consulting fees, we’re still old. Many are retired, some are now your CTO. Some teach. Some write articles about COBOL programmers.

  • Cross train existing staff. You have programmers, and they understand your business model. This is a huge plus. Most likely diverting their time and attention to this problem can help ease the strain, but they’re on your payroll because they’re preforming a necessary function already, and that will slow down or stop. Introducing them to COBOL shouldn’t be hard. They’re professionals.

  • Find new COBOL programmers. Yeah, sounds good, let’s do this one. There aren’t any, of course, so we’ll make some! Fortunately, the old law of supply and demand predicts this will happen, and there are signs of this already.

    There’s help coming, maybe. IBM is, of course, doing what it can to help. After all, the vast number of COBOL applications still surviving in the world reside on IBM mainframes. Whether those machines are called “The IBM Z Ecosystem” or any of the older names, they’re fundamentally the same from the perspective of the COBOL application. If you need to train people already familiar with the voodoo of mainframes, to ask questions, or look for experienced hands-on people, try IBM.

  • Google “how to learn COBOL.” As of this writing, there were 8.4 million hits. Don’t bother reading them; it will probably not help.

  • Be aware that knowing COBOL counts for nothing; it’s just one small part of the solution. COBOL is a language that is used to define a problem space and a strategy for transforming some input into some output. That’s all it is. English is also a language, and is the one used in creating this document. Without a contextual framework, however, this is all gibberish. Yes, English proficiency is necessary. Try this experiment: print this article and hand it to 10 random people, all of whom are proficient in English ... watch their eyes glaze over, it’s kind of fun.

  • Do not even consider replacing in-place production systems that are running along happily on mainframes by “transplatformation.”3 There are many very good reasons to leave them in place, especially in the case of financial systems. Those systems went on the mainframe for good, practical reasons. Changing them is HARD. (If you have the time, read about the COBOL COMP-3, packed decimal, and excess 6 notation. And the differences between ACISS and EBCDIC.)


In order to “fix” the old COBOL systems, we need a working understanding of the environment as it is now, and as it was when the system that is “broken” was written. And, apparently, even the COBOL language itself as it is now and as it was at the time it was written. Yes, just as in Y2K, we can (and will) somehow patch, update, patch, update, patch, update, and things will work. Perhaps this new crisis will open our eyes to the realities of our information enterprise. Somehow, I doubt it.

Sorry for the headache. For once, it’s useful to be old.

1 Back in the days when I was working at a Japanese company, I was taught never to say “no.” One said “yes” or “yes, but….”

2 If you remember what an IBM green card was, you’re old.

3 “Transplatformation” is a term that my long-time friend, mentor, co-conspirator, and Cutter Consortium Fellow Ken Orr and I invented back in the days of “wow, with all these PCs and servers and stuff, we can finally get off the mainframe.” It refers to the somewhat dubious practice of moving an application from one environment to another for no good reason other than moving it. Yes, there were many good reasons. And there were many bad ones.

About The Author
Andy Maher
Andy Maher is an IT professional who concentrates in enterprise architecture, business intelligence, metadata management, systems integration, knowledge management, and solutions for a whole range of impossible problems. He has written extensively on data warehousing and systems architecture. Mr. Maher has spent the last 10 years working “in the channel,” involved in all aspects of the distribution business, with a concentration in BI and B2B… Read More