The Origins of COBOL
Grace Hopper was a phenomenon. She earned a doctorate in mathematics from Yale, was a professor at Vassar, and left the U.S. Navy with the rank of rear admiral. Her contributions to the field of computing can be judged by the number of foundations and programs that have been created in her memory. The National Energy Research Scientific Computing Center named its Cray XE6 supercomputer after her. The Navy also named its guided-missile destroyer, the USS Hopper, after her. The ship’s motto, “Aude et Effice” (“Dare and Do,”) might well have been coined with Hopper in mind.
Driven to create a programming language closer to English than the machine-code computers understand, Hopper developed the first compiler. This opened the door for the first compiled languages, such as FLOW-MATIC. This earned her a seat on the Conference/Committee on Data Systems Languages (CODASYL) of 1959.
She was also instrumental in the specification and development of the Common Business-Oriented Language (COBOL). The first meeting took place on June 23, 1959, and its report and specification of the COBOL language followed in April 1960.
COBOL Was Radical
COBOL contained some groundbreaking concepts. Arguably, the most significant of these was the ability to run on hardware produced by different manufacturers, which was unprecedented at the time.
The language was elaborate and provided a near-English vocabulary for programmers to work with. It was designed to handle huge volumes of data and to be exceptionally mathematically accurate.
Its vocabulary of reserved words (the words that make up the language) runs close to 400. A programmer strings these reserved words together so they make syntactical sense and create a program.
Any programmer who’s familiar with other languages will tell you 400 is an incredible number of reserved words. For comparison, the C language has 32, and Python has 33.
Another quirk of COBOL is its strict requirement that certain program lines begin in certain columns. This is a hangover from the days of punch cards. Today, programmers have more freedom when formatting COBOL, and no longer have to type everything in caps. This makes working with it less prescriptive and shouty, but it’s still very much a creation of its time, as shown below:
COBOL Is a HIT
As clunky as it might seem today, COBOL was revolutionary when it launched. It found favor within the financial sector, federal government, and major corporations and organizations. This was due to its scalability, batch handling capabilities, and mathematical precision. It was installed in mainframes all over the world, took root, and flourished. Like a stubborn weed, it just won’t die.
Our dependency on systems that still run on COBOL is astonishing. A report from Reuters in 2017 shared the following jaw-dropping statistics:
There are 220 billion lines of COBOL code still in use today. COBOL is the foundation of 43 percent of all banking systems. Systems powered by COBOL handle $3 trillion of daily commerce. COBOL handles 95 percent of all ATM card-swipes. COBOL makes 80 percent of all in-person credit card transactions possible.
As you can see, it’s difficult to make it through a day without using a system that depends on COBOL. Bank accounts and check-clearing services, as well as public-facing infrastructures, like ATMs and traffic lights, still run on this code written decades ago.
COBOL Is a Problem
The programmers who know COBOL are either retired, thinking about retiring, or dead. We’re steadily losing the people who have the skills to keep these vital systems up and running. New, younger programmers don’t know COBOL. Most also don’t want to work on systems for which you have to maintain ancient code or write new code.
This is such a problem that Bill Hinshaw, a COBOL veteran, was coerced out of retirement to found COBOL Cowboys. This private consulting firm caters to desperate corporate clients that can’t find COBOL-savvy coders anywhere. The “youngsters” at COBOL Cowboys (the motto of which is “Not Our First Rodeo”) are in their 50s. They believe 90 percent of Fortune 500 business systems run on COBOL.
Of course, private businesses, corporations, and banks aren’t the only ones that need to number-crunch gargantuan amounts of financial data. Federal, provincial, and local government services have the same requirements. Like all the others, they use mainframes and COBOL for this.
The dreadful impact of the coronavirus pandemic has led to heartbreak, fatalities, and economic uncertainty for business owners, employees, and the self-employed. The huge numbers of furloughed and fired staff in New Jersey led the governor to appeal for experienced COBOL programmers to come to the aid of the state’s aging back-end systems. These are straining to cope with the 326,000 new registrations.
The Open Mainframe Project is running a volunteer-based initiative to help. If you think you might be able to assist, they’d be glad to hear from you.
New Jersey isn’t alone in this predicament. Over 10 million people have registered for unemployment, and that figure is rising. Connecticut is struggling to process a quarter of a million new registrations on the state’s 40-year-old systems.
This is a widespread and deeply embedded problem. A 2016 report from the Government Accountability Office listed COBOL systems running on mainframes up to 53-years-old. These include systems used to process data related to the Department of Veterans Affairs, The Department of Justice, and the Social Security Administration.
Why Not Migrate and Upgrade, Like, Yesterday?
Upgrading these legacy systems isn’t as simple as it sounds. The systems are vital, 24/7 fulcrums on which the financial, governmental, and business worlds pivot. The code is old, multilayered, and, often, poorly or completely undocumented. It also has to work, all the time. The prospect has been compared to taking the propellers off an aircraft and trying to fit it with jet engines—while airborne.
The risk aside, the economic argument to migrate to modern systems is also a tough one. The money that’s been pumped into keeping these mainframes and COBOL applications operational is astounding. Should institutions throw it all away and start again while that COBOL code is still running and functional? That’s a hard pitch to a board that probably isn’t particularly technically inclined. A COBOL migration won’t be cheap, nor fast.
“I just got through a conversion to go from COBOL to Java,” Hinshaw said. “It’s taken them four years, and they’re still not done.”
When the Commonwealth Bank of Australia replaced its core COBOL platform in 2012, it took five years at a final cost of $749.9 million ($1 billion Australian).
And that’s when it goes according to plan. U.K. bank, TSB, was forced to migrate from a COBOL-based system in 2018 due to a buyout. It didn’t go well. Because the bank was unable to trade for days, the cost of the migration ended up being 330 million pounds. That was in addition to the budgeted cost for the engineering work for the actual migration. TSB also lost 49.1 million pounds from financial fraud while its systems were melting down.
Customer compensation topped 125 million pounds, and the bank had to spend 122 million pounds hiring new staff to deal with the 204,000 customer complaint cases. The chief executive resigned and the company is still mopping up the damage two years after the event.
The COBOL Conundrum
Things can’t stay as they are, but the prospect of doing something about it is hardly appealing. Nevertheless, the only way things are going to get better is to conduct controlled, careful migrations to modern soft- and hardware.
To achieve that without disruption, data loss, and downtime will require modern expertise and money, which is 50 percent of the equation. The other half is COBOL expertise and time. Unfortunately, those are the two ingredients we’re almost out of.
Perhaps a new breed of COBOL cowboys will ride into town.
