COBOL Isn’t Slowing Anything Down
There are several misperceptions and assumptions with respect to COBOL and the latest difficulties several government entities have been experiencing due to COVID-19. COBOL and the IBM Z® platform were leading-edge technologies 40 years ago and they both still are today. They’re increasingly innovative with each release. Both are quite modern and expertly designed tools. Even systems that run on an expertly designed tool that has a sudden increase in traffic is susceptible to performance problems. Add a simultaneous requirement change and the problem is compounded. This is what has happened to state governments. The systems of record may be COBOL but COBOL isn’t the problem, nor is the mainframe. The problem lies in the increase in transaction volume and the need to make sudden changes to programs that happen to be written in COBOL.
Who Uses COBOL?
There are a number of states that use COBOL, a language that has been widely reported to have an estimated 220 billion lines of code being actively used today. Also, many banks, insurance companies, airlines, railroads and retail point-of-sale systems also use COBOL. If you use ATMs, electricity or have a bank account, you’re likely using COBOL built systems. So, safe to say that most Americans and people globally who do some of the same activities every day like banking, are using COBOL and the mainframes that run it.
COBOL and Compatibility
Many of us have installed a new version of Windows at some point and then spent countless hours trying to get other applications to work or Windows itself to work. We download new application versions, run programs as administrators or in compatibility mode to try getting everything functional. It has been painful for many users but vastly improved with each release. This past week though, I was wondering why no one ever says that that old PC OS, Windows, developed in way back in 1983, is the problem? We’re talking over 30 years old! Well, the difference is that many people globally, use Windows every day. Right?
Part of the problem is also part of the beauty of COBOL and mainframes. Mainframes and the infrastructure that runs on mainframes has always been written to support the work that was done before. This was done to ensure that applications customers wrote would continue to work without needing to change them just because a new OS was installed, or a new mainframe was cabled up.
The software I wrote many years ago will still run today on the newest mainframe and under the most current OS. I don’t see that in many other industries. Since the supporting infrastructure on the IBM Z platform, enables all customer code to continue running as upgrades are done, those applications simply continue to function. Customers can take advantage of the myriad number of advancements in new hardware and software if they choose or they can allocate time and resources to something else that is important to them. Imagine having to rewrite or reinstall hundreds of applications every time you bought a new mainframe or upgraded your OS? IBM Z customers and COBOL users don’t have this concern.
COBOL programs written years ago or 10 minutes ago are forward compatible. IBM has done this purposefully and expertly. If customers want to take advantage of the enhancements we build into the product they can, if they choose to. Even if they don’t, their programs will continue to run.
COBOL and Modern Languages
Like Windows (1983), COBOL (1959) was developed in the last century. Many see COBOL as archaic, which is misinformed and incorrect. Modern programming languages like Java (1991), C++ (1983) and Python (1991) support constructs like object-oriented programming, 64-bit addressing, and utilize APIs. Well, COBOL does those things too. In fact, COBOL applications can be invoked as services that connect frontend systems that use HTTP, Apache, JavaScript, etc.
COBOL is also equipped with tools that handle XML and JSON processing. Application programmers can utilize 64-bit addressing without changing their code. However, COBOL isn’t a general-purpose language. COBOL was purposely designed for applications that perform transaction processing like payroll, banking, airline booking, etc. You put data in, process that data and send a result out.
Identifying the Problem
Misinformed perceptions about COBOL often emerge for the following reasons:
- The press is writing stories that they know nothing about and didn’t research
- Volume and code changes occur which need to be done quickly
I’ll address the latter but not the former. Anyone who has been in information technology for more than a few minutes knows that if you suddenly increase the volume of transactions your application is processing, application behavior will change unless you have prepared for that to happen. Additionally, if you suddenly change the requirements that the code operates by and demand that those changes happen ASAP, you’ll need skilled programmers who know your applications to make those changes.
Rapidly changing transaction volumes can have deleterious effects on an application if provisions weren’t planned for. The areas that can be affected are widespread; network, routers, switches, storage and processing capacity. All of this can affect application performance. In the case of COVID-19 we have systems designed for a threshold of activity that has changed dramatically and rapidly. Not only is front-end infrastructure impacted, back-end infrastructure is too. New regulation is also forcing many of these systems to change. Those changes should be made by programmers who know the application if possible, not newly minted ones.
COBOL Programs Will Continue to Process
There are systems that must now accommodate a huge influx of sustained activity and simultaneously change to accommodate new requirements. Changing the software will likely be the easy part since the additional change necessary to suddenly handle 2x, 4x or 10x increase in traffic could take planning across several disciplines and money. Adding circuits, increasing bandwidth or making provisions to enable your systems to handle more data and transactions takes effort and expense.
COBOL is part of these systems but is only one of many and not the only area that needs augmentation and mitigation. Systems that see a relatively steady flow of traffic are often just left running and don’t get a lot of attention. Contrast that with systems that see routine spikes in traffic like retail enterprises plan for seasonal demand increases. They know what’s coming. State governments have been taken by surprise. Fortunately, COBOL programs will continue to process no matter how much is pushed through them and mainframe capacity can be changed dynamically if more processing power is needed.