As early as the mid-1980s, people were quite certain Cobol was on its way out. Most of us looked for opportunities to learn emerging technologies and shifted our career focus away from Cobol and from its primary platform, IBM mainframes.
At that time, opportunities opened up for those who understood the old technology and could help re-implement solutions in the new. It was a way for us to learn other technologies and build a new career path.
There was pressure to replace older applications based on Cobol, as the mainframe was due to die at any moment.
Cobol forgot to die
But a funny thing happened on the way to the cemetery. Writing in Forbes in July, 2020, Tom Taulli notes:
- “[Cobol] powers about 80% of in-person financial services transactions and 95% of ATM swipes.
- On a daily basis, it processes $3 trillion in commerce.
- There are over 220 billion lines of code and 1.5 billion are written each year.”
See COBOL Language: Call it a Comeback?.
This may not be obvious to us as we go about our day-to-day business, as we don’t see much evidence that mainframes or Cobol are in play. We see webapps and mobile apps. And we see blue screens of death, Java stack traces, and HTTP 500 errors appearing on kiosks, advertising screens, and other public displays.
We don’t see anything that resembles JCL or S0C7 abends or the good ol’ “standard 11-column report.” From that lack of evidence we might surmise there are no mainframes or Cobol in the mix anymore.
That would be a faulty conclusion. It isn’t because those things aren’t involved in our transactions; it’s because they occur deep in the back-end, and the error messages don’t bubble up to the UI.
Growing demand for mainframe skills
I’ve noticed growing demand for training of object-oriented developers to support legacy Cobol applications, and for training of Cobol developers to learn Java on the mainframe to support new applications.
Is it a fluke, or a one-time problem? In the late 1990s there was a mad rush to prepare for the Y2K event. Demand for Cobol skills enjoyed a temporary bump. During the 2020 Coronavirus pandemic, some US states had difficulty keeping up with demand for unemployment benefits, and again there was a temporary boost in demand for Cobol skills (although that was a bit late to start addressing legacy code).
But the general rise in demand does not appear to be associated with a one-time event. IBM has continued to evolve mainframe technology, and that platform stands to play a major role in Things to Come.
Of course, an obvious reason for growth in Cobol jobs is that the older generation of Cobol developers is retiring, and there’s no end in sight for the mission-critical and market-differentiating applications built in Cobol. But that’s not the only reason.
It turns out a modern mainframe, known as a zSeries system, is an ideal platform to support a cloud infrastructure. Current models can run upwards of 8,000 Linux VMs concurrently, while still handling traditional batch and CICS workloads without a hiccup. CICS itself can act as a TCP/IP server and an HTTP server.
A single z/OS system can host multiple instances of several operating systems, and up to 32 such systems can be linked in a Parallel Sysplex environment. Security features of the zSeries are unmatched by any other business computer system.
A zSeries system circa 2021 is not just another network node, like a Linux or Windows instance. It’s more akin to a whole network. It’s a cloud in a box. Well, several boxes. But you get the gist.
IBM is starting to offer this class of resource as a cloud-based service. Mainframe shops are well-positioned to implement a hybrid cloud strategy with little or no risk to their mature systems.
As they used to say in that old TV commercial, it’s not your father’s Oldsmobile.
What accounts for the mainframe’s longevity?
Come to think of it, that’s not quite true. It is your father’s Oldsmobile. Simultaneously, it’s the latest Ferrari.
In my view, the primary reason the mainframe and Cobol and all that jazz is still around and still supporting the global economy is backward compatibility.
Prior to the IBM 360 in 1964, companies had to replace all their application software every time they upgraded their computer hardware. Each system had its own architecture, its own operating system, and its own programming languages.
The situation was a bonanza for consultants, but not so great for customers. IBM decided to make backward compatibility a core design goal for their latest system, the 360.
They have adhered to that goal all these years. A z15 in 2020 can run executables that were compiled on a 360 in 1964, while doing all the New Things at the same time. With high security. With 24×7 availability, even while being upgraded or repaired.
Today’s mainframe does everything any other contemporary system does, and still does everything its predecessors did.
On the downside, that’s the reason companies largely forgot about keeping their systems and applications up to date all through the latter half of the 20th century. Their mainframe just ran everything, old and new. So they let it ride.
And thus, companies have deep, deep dependencies on code that is so old and so arcane no one alive understands it. In many cases, it wouldn’t matter if people could understand it, because the source code was lost years ago. The old applications aren’t replaced because they can’t be.
Things they are a-changin’
That’s a career opportunity for software developers.
And it comes in the nick of time. According to Career Planner, we can expect an 8% reduction in computer programming jobs (across the board, not just Cobol) by 2026, amounting to a net loss in the US of nearly 23,000 jobs.
Pay rates for this work have been in decline for some time already, and that trend is expected to continue. In 2020, with 43 years of experience, I was worth the same number of dollars per hour as I was in 1985, with 8 years experience. The spending power of a 2020 dollar was far less than that of a 1985 dollar. So, I have more to offer but I command lower pay than my former self.
That trend will continue, for all of us. Coronavirus has taught us that remote work is quite effective. That means companies will be looking for talent wherever it may be found. Good news for programmers living in countries that currently have low pay; not so good news for those living in countries that currently have high pay.
Building new skills upon old
I mentioned that when the mainframe was expected to die, there were opportunities for mainframers to bring their expertise to conversion projects, where they could sell themselves based on what they already knew and learn new marketable skills on the job. That’s the path I took, along with many thousands of my peers.
Today, we have a similar opportunity going in the opposite direction. While mainframe technologies have continued to evolve over the years, that world has not yet embraced contemporary software development methods in a serious way.
Practices like test-driven development, pair programming, mob programming, incremental refactoring, continuous integration, and continuous deployment are only now gaining traction in that environment, and the major mainframe-focused software vendors are only now getting around to supporting such practices in their software development products.
Those of us who have been “away from home” for a while can bring those skills back in.
Teaching new dogs old tricks
I’ve started to do my part by developing and facilitating training courses to bring programmers familiar with object-oriented languages up to speed with Cobol and the mainframe environment, and vice versa.
I’ve also started an open source project called Cobol Check that aims to support fine-grained unit testing or microtesting to the Cobol language. I’d love to have more participation in that project. Let me know if you’re interested.
Mainframe software vendors have been working hard to modernize the day-to-day working experience of Cobol developers. IBM, Micro Focus, Compuware, and CA all offer IDEs that run under Microsoft Windows and exploit the pluggable architecture of Eclipse to provide mainframe developers with a more-contemporary working experience than the traditional OEDIT editor on ISPF, running through a 3270 terminal emulator.
The old toolset was holding people back from doing basic things like refactoring and unit testing. Now that those things are becoming feasible, we need to help mainframe specialists get started with them.
As the saying goes, we are living in interesting times.