Who’s Afraid of the Big Bad COBOL?

May 5, 2020

When Grace Lee Hopper (and others) developed the Common Business-Oriented Language (COBOL) in 1959, she never could have imagined that it would be in the news in 2020.

“An ancient programming language is suddenly in demand” screams Salon. “COBOL back from the dead… again” according to Scoop. “Outdated Software Complicates Efforts to Keep State Unemployment Systems Running” bemoans WNYC Studios.

True, COBOL recently passed its sixtieth birthday. But rumors of its demise, to be sure, have been greatly exaggerated. By all measures, COBOL is as relevant and important today as it was six decades ago – perhaps more. So why all the consternation?

COBOL as Scapegoat

COBOL is, in fact, a fully modern language, because it was designed to remain current.

The word ‘common’ in its name actually reflects early mainframe customers’ desire for a portable language. Before COBOL, each computing platform required its own proprietary language. In contrast, COBOL works across different platforms – and perhaps more importantly, continues to work as vendors update their platforms from one generation to the next.

Furthermore, the ‘business-oriented’ part of its story means that lines of COBOL read much like English – common across today’s programming languages, but revolutionary in its day.

COBOL—and the mainframe platform that it runs on—still accomplish what they have always been good at exceptionally well. COBOL has always excelled at supporting programs that handle high-volume data and transaction processing – like the number-crunching that banks and government agencies have to do every single day.

COBOL was thus understandably the language of choice for such processing in the 1960s, and it is still largely the preferred language for the same tasks in the 2020s.

Finding the Real Culprits

If COBOL programs aren’t up to the challenges of a modern, pandemic-driven organization, the problem is often due to apathy towards maintaining legacy applications, modernizing the development environment, or keeping hardware up-to-date. The root cause, therefore, is more one of insufficient budgets and failures of corporate will, rather than a limitation in technology.

After all, IBM – the lone surviving mainframe vendor of any significance – continues to innovate its IBM Z mainframes. Today’s z15 product line contains some blisteringly fast machines that simply never fail.

Furthermore, IBM has updated its COBOL compiler along with the hardware to empower its customers to accelerate old programs dramatically simply by recompiling them, often without changing a single line of code.

Those customers can also run Linux, perform all the tasks of a cloud server, and support programs written in all modern languages – including COBOL.

Even if a COBOL-running organization upgrades its hardware to the latest and greatest, however, they may still have problems keeping their COBOL programs up-to-date.

Once again, the problem isn’t with the language itself. It may be with the tools developers use to update those programs, or the processes they follow to make the updates.

In some cases, following the largely obsolete waterfall software development methodology may be partly to blame. With waterfall, teams gather all the requirements before touching a line of code, and then wait until all code updates are complete before testing. This approach is slow and doesn’t respond well to shifting requirements – two situations that are likely to be the case in times of crisis.

In other situations, the development and testing tools are out of date. When the COBOL developers on staff have been using such ‘green screen’ tools for years, then older tooling may not be much of an issue.

But if an organization tries to bring in next-generation developers, they will be expecting modern development and testing tools similar to the ones they might use for modern cloud-centric development.

The Guilty Party: Testing

Of all the reasons why old COBOL programs struggle to meet the current needs of modern organizations – especially in a time of crisis – the real culprit is often testing.

Remember, the central challenge here is updating existing programs, some of which have been around for years. And nobody wants to monkey with something so old without knowing whether such a change will make things better – or worse.

There’s a lot that can go wrong when making such updates. New functionality might not work properly. Perhaps the new code works fine but causes some other, older code to break.

A third, common scenario: the new functionality works fine at low transaction volumes, but causes the system to slow down unacceptably or fall over entirely when those volumes ramp up.

If the development team doesn’t have visibility into these issues, they will understandably be loath to make the changes in the first place. The solution: modern testing tools like the mainframe testing tools from Compuware.

Compuware Topaz for Total Test automates unit testing, functional testing as well as integration and regression testing – giving developers the visibility they need into the workings of any changes they may introduce into a COBOL application, as well as the effects those changes have on the rest of the program.

And Topaz for Total Test, as with Compuware’s entire Topaz suite of products, provides developer and testers with a modern, familiar developer experience making it a lot easier for a ‘next-gen’ developer to become proficient.

Compuware has also recently added a new REST API and Jenkins integration to its Strobe application performance management solution, bringing mainframe performance management into the fold with other modern devops tooling across the appdev organization. Now mainframe developers young and old can determine the performance impact of any code updates they may create.

The Intellyx Take

Mainframe insiders have certainly been rolling their eyes at COBOL’s recent unflattering turn in the news. In spite of the bad press, however, this brief return to the limelight is largely a plus for all parties involved.

COBOL skills are in more demand than ever, improving the job prospects of COBOL experts and novices alike. COBOL-dependent organizations with obsolete hardware, processes, or tooling are likely to get the budgets and support they need to make long-needed changes.

And perhaps most importantly, the members of the public that depend on the efficient workings of mainframes in the global financial infrastructure, both within the private and public sector, can rest assured that the entire mainframe community is putting in overtime to make sure everything continues to work during this time of crisis.