This is going to be a technical piece, so be warned.
COBOL was trending on Twitter this weekend. Neat, but it wasn’t because there’s been a sudden increase in folks wanting to learn how to program in COBOL. Nope, the Governor of New Jersey asked for volunteers from “Cobalt” programmers to help in maintaining (I assume) mainframe applications used in unemployment claims that are being overwhelmed due to the “Great Timeout”. Now, I know that New Jersey Governor Phil Murphy really meant “COBOL”, but I point out “Cobalt” because I believe it shows a general lack of awareness and understanding of the importance of these mainframe applications–that is, until the proverbial stool hits the rotating air moving device.
Sensationalist journalism likes to use the terms “old”, “outdated”, “creaky”, and other pejoratives that scare the reader into thinking that mainframe hardware and software hasn’t been updated since Nixon was in the White House, but that’s usually not the case. Companies and governments that continue to use mainframe systems (IBM Z) regularly upgrade the hardware and software, so your data isn’t likely running on a computer that was installed in the 1960s.
Here’s a bit of background: the IBM Z environment is more than just COBOL (the “name” COBOL itself is really an acronym for “COmmon Business Oriented Language” and is actually a standardized programming language). Yes, a lot of applications are written in COBOL, but it’s more than just that. Think of it as an ecosystem where there are a lot of supporting systems and roles. You have your systems administrators (also called systems programmers) who work on administrative tasks and do installs of software including the operating system (z/OS). You have storage administrators that maintain the vast amounts of storage that the mainframe needs, security administrators, database administrators (me!), network administrators, computer operators, job schedulers, etc. And, of course, applications developers who write the applications on the mainframe. These applications can be written in COBOL, HLASM (High-Level Assembler), or other less-common programming languages. Sometimes these specialties overlap, but in large organizations, you have to have teams that support one particular function.
Now, I suspect that the issue that the State of New Jersey is facing is one where they ran out of capacity. This is me purely speculating. I don’t have any data to back up this, but indulge me.
You don’t go out and “buy” a mainframe. Most of the time, you enter into a leasing agreement with IBM, and you buy a certain amount of capacity (measured in Millions of Instructions Per Second–MIPS, for short) that you expect to need. You can always buy additional capacity where you see a spike in utilization, but generally you try to keep your MIPS usage low.
According to this Quartz article, New Jersey saw a 1,600% increase in unemployment claims volume in a single week. That would tax any system whether it be mainframe-based, Linux/UNIX-based, Windows-based, or cloud-based (though, most cloud-based systems really are Linux/UNIX or Windows, but I digress..). Now, that doesn’t mean that there aren’t opportunities to tune the application, underlying data sets and databases, and the transaction environment to boost throughput and response times, but it’s not necessarily the age of the application. The problem likely lies in the fact that these systems have been put in “set-it-and-forget-it” mode. They probably get regular system patching, but the application enhancements are minor (break-fix type stuff). You can’t expect any system to be flexible and nimble if you aren’t working on enhancements to improve the system.
Companies and governments have known for quite some time that the median age of IT professionals with a mainframe background will continue to increase as time goes on. The loss of resident knowledge increases every year, but rather than working to train a new generation of mainframe professionals, the “solution” seems to be outsourcing. The reliance on offshore contractors to help maintain these systems usually is more of an economic decision rather than a talent decision, so you tend to get what you pay for.
Businesses do realize and talk about–albeit not publicly–the fact that they need to beef up their in-house IT staff with mainframe skills. That’s why I’m encouraged that the University System of Georgia has been listening to the needs of industry and working with them to build curricula to equip talent with the mainframe skills that are needed.
This current public health emergency has exposed some gaps, and I do believe there should be an open, honest conversation about what worked and what didn’t with the response by both state and federal governments including what critical systems need additional support in times of crisis.
They may get dunked on by other IT professionals and the public as a whole, but mainframe systems are a crucial component of our day-to-day lives. You usually don’t notice them until they don’t work. I hope this highlights their importance rather than be seen as scary, antiquated systems that are no longer useful. The fact that our checking accounts, debit and credit cards, and other financial transactions work without interruption shows the reliability and longevity of these mainframe systems.
Georgia is working towards being the “Silicon Valley of the East Coast”, and we can help build upon the groundwork started by the University System of Georgia through public-private partnerships to equip people looking to get into IT with mainframe skills.