The massive rush of new traffic to their websites, due to the Covid-19 pandemic, is causing havoc on these legacy COBOL Mainframe setups, which translates into delays or even system crashes during a time when people need their unemployment checks more than ever.
But it's not only State Labor and Employment agencies that are affected by the sudden surge of traffic taxing their aging COBOL mainframe systems. A high percentage of banks, hospitals, and other industries (like airlines and hotels) still rely on this ancient computer language plus mainframe setup. Why? Because of that also ancient developer philosophy of "Don't fix it if it's not broken."
The problem is that we're fast barreling into a situation where there will be no one left who knows COBOL. What will happen when something critical written in COBOL breaks... like some essential hospital system or financial system?
It has become challenging to find programmers who know COBOL because most COBOL Cowboys retired in the 1990s. They were briefly recalled in 1999 for Y2K, but now, 20 years later, most COBOL Cowboys are either completely retired or no longer with us (i.e., gone to that COBOL dude ranch in the sky).
But like a Clint Eastwood movie (think Space Cowboys), the few COBOL Cowboys still around are gearing up for their last rodeo to show these whippersnappers a thing or two (who's "OK Boomer now?).
COBOL (an acronym for "common business-oriented language") is actually not a hard programming language to learn, and ironically it doesn't work worse than it did before. You can even get more done in COBOL, and in fewer lines of code than before, because developers can now run it on more powerful systems that weren't available in the 1970s.
A Macgyvered COBOL mainframe system in 2020 can crunch data at blazing speeds, in very complex environments like bank databases and unemployment rolls. Hence the reason so many of them are still around.
COBOL fell out of favor with new generations of coders who considered it "too verbose" when compared to C, Perl, and PHP. But where are those languages now? They are now also being called obsolete in favor of whatever the new concept of the season is.
Our current COBOL crisis is quite concerning when one thinks about today's tech stacks. How fast has MongoDB evolved? Angular? Elasticsearch? Five years is an eternity in today's developer's world. A language developed less than a decade ago may be out of date, incompatible, or have trouble finding developers willing to work on the old versions, let alone 60 year old COBOL, a programming language that hasn't been taught in US universities since the late 80's/early 90's.
But where did COBOL programmers come from in the 50s & 60s?
Corporations trained them. That's how employers used to create skilled workers before companies got addicted to only hiring already fully trained coders (preferably from a competitor).
In a nutshell, companies simply 'forgot' they could teach people.
To Migrate Or Not To Migrate
There are several COBOL migrating solutions out there. For example, Microfocus has an offering for COBOL on Azure. But the problem goes beyond learning COBOL. Ask any programmer tasked with updating a COBOL system, and they'll tell you that they're incredibly difficult to upgrade. Not due to the programming language itself, but due to the years (or perhaps decades) of different rules to unwind.
For example, you may find a COBOL payroll system with all the legislative changes for each period, spanning across all the years that employees have worked. Replicating this is not easy.
But why is it still devilishly hard to migrate these legacy COBOL systems?
Yes, commercial COBOL compilers for Linux exist. Some universities have COBOL programs running on Red Hat 6 and 7. But understanding the core code itself is the easy part. The main reason why it's so hard to transition away from old COBOL systems is because of decades of changes made to the code, making reading and comprehending of it such a nightmare for an outsider taking over the project.
Developers will tell you that debugging COBOL codes written years before they were born and reading through all that spaghetti code makes it practically impossible to debug.
Impossible to debug unless they have access to the original authors of the code: Let's call in the COBOL Cowboys!
First, a bit of history: COBOL's development started in 1959 and was adapted in 1962 as IBM's primary programming language.
In 1964, IBM came out with its System/360 series of mainframes, and at this point, most banks in the USA moved to mainframe-based back-office processing. Soon other industries followed suit and the COBOL mainframe system became ubiquitous in the American corporate world until well into the second half of the 1980s.
As personal computing took off in the 1990s, and companies like Apple, Yahoo, and Google became dominant, COBOL programming became a distant memory, only that it didn't.
All the "untrendy" industries like banking, state unemployment agencies, hospitals, even hotels, and airlines continued to rely on their old school COBOL mainframe systems for their back ends. Why? Because the UI/UX is simple, the system is very powerful, re-training users is expensive, and because if it isn't broken, why fix it? Right?
Only that they weren't counting on a massive traffic surge due to the Covid-19 pandemic.
The Federal Labor Department has reported that approximately seventeen million unemployment claims were filed between March 15th and April 4th. That's almost 13% of the US's workforce.
As more stores and businesses shutter as a result of the pandemic, more traffic will pile on top of the already unprecedented amount of traffic these legacy COBOL Mainframe systems are barely able to handle right now.
The situation has become so dire that IBM has started offering free online COBOL training courses as well as providing mainframe systems that are compatible with COBOL.
What can IT managers and developers facing COBOL migrations do? Apart from calling in COBOL veterans, there are some tools available nowadays that can make the transition more painless.
There are many more frameworks and toolchains available today that allow programmers to build cleaner code. Coders nowadays also have a better knowledge of what works and what doesn't (hindsight is 20/20).
The cost of computing power nowadays is a lot cheaper than when COBOL was initially developed.
Back in the 1970s, when a project failed, it commonly was because the system itself was too slow.
Nowadays, computer power and resources are cheaper, so it's more viable to throw a lot of computing power at a problem.
Even if you are an IT manager or developer not dealing with COBOL, it doesn't mean that you are immune to this problem (obsolete tech). So you should use this as a valuable lesson to future-proof your system.
Future-Proofing Strategy Tips
1-Embrace API and Modular Architecture.
That way, you can update third party systems via API as technology evolves without affecting your core system.
2-Embrace Training.
Make training and onboarding part of your philosophy. Using knowledge base portals for training and onboarding that can be updated as tech evolves and can be searched by anyone in your team, even years in the future.
3-Embrace Open Source.
Open-source systems are more future proof as there is an entire community built around it that can step in to answer questions when you hit a roadblock in the future.
4-Embrace Your Elders.
Who's "OK Boomer Now?" If all else fails, make sure your team has a COBOL cowboy on speed dial.