Much of the defense of COBOL as a programming language is based on the volume of code that exists today in production. These mission-critical workloads support both government and commercial needs all over the globe. Something used to prop up such critical workloads MUST be valuable, right?
Well, the volume of COBOL is more a function of history than an overwhelming acceptance of it as a superior architecture or programming language. It’s not as if anyone is predicting COBOL programs to just stop working as the rust of age begins to overtake the code!
Yes, COBOL programs are still here, and they do still work.
However, the concerns over a sufficient global workforce to support its maintenance needs are valid, let alone significant new development. Defenders of this language rarely point to its inherent technological worthiness over others. Nor do they suggest it’s a better choice for modern web, distributed, or cloud computing platforms. It rarely exists in that arena, and that’s where the world is moving!
Other than IBM, COBOL is dominated by a single vendor – Micro Focus. Over the last decade or two, Micro Focus has gobbled up every potential competitor and absorbed them into its maintenance revenue universe. Where will the global open-source minded innovation come from in such a restricted world?
The Battle Cry of the Risk Adverse
The most realistic defense for the lack of significant COBOL modernization is “if it’s not broken, don’t fix it.”
If organizations can extend the value of the business processes in these programs by adding web front ends, with the addition of functionality through packaged software solutions, or through duplication of some information or business functions on alternative platforms, then these systems continue to run.
Are they the focus of attention? No, not really. Is their continued execution a valid defense of a continued dependence on COBOL? Not so much!
A Worn Path
Some have tried to continue the evolution of COBOL usage by improving the development environment of the language. Particularly in the IBM mainframe world, the character-based TSO interface, enhanced by the IBM ISPF screen-based development environment, has been the predominant technology for application development. This environment consumes mainframe computing power (MIPS) and is highly limited when compared to modern, work-station-based interactive development environments (IDEs). These IDEs can auto-predict statement syntax to aid developers in writing new code and provide a much more visually appealing interface for development.
This approach presumes the problem with COBOL is the antiquated TSO/ISPF interface and that adding a more productive IDE will revitalize the language. This simply hasn’t happened. Many COBOL developers have habits firmly entrenched in the old TSO/ISPF paradigm and have been reluctant to move to these new IDEs. Younger developers, on the other hand, quickly realized there were more promising technologies that enhanced their careers more than COBOL would and moved on to these opportunities.
Mistakes Were Made
Twenty years ago, an object-oriented version of COBOL (OO-COBOL) was introduced and was intended to bring the language to a modern architectural development style. This failed miserably. Those that understood COBOL were steeped in the procedural language style and couldn’t understand object orientation.
Those who did understand it didn’t see COBOL as the language for this approach. The industry investment for object-oriented technologies in Microsoft or Linux development grew exponentially and did not consider COBOL a viable technology. It doesn’t matter whether it “could have been.” It wasn’t!
The failure to resurrect COBOL through these attempts created a gap in usage. Furthermore, with the growth of modern computing platforms using dramatically different technologies than COBOL and the mainframe to support mission-critical workloads, the application portfolio of organizations continues to marginalize this legacy language in today’s computing platforms.
There are other options for modernization. However, they also have concerns that must be addressed. These options include cross-compiling COBOL source code into another language, such as Java, or transforming its syntax to an entirely new language.
The results of these efforts have been uneven. When done incorrectly, they create a mixed universe of languages and architectures that straddle two styles and leave organizations in a precarious position, trapped in a kind of limbo between the two.
The worst-case scenario with cross-compiling is when the code transformation solution generates unreadable and unmaintainable code, or JOBOL – a program in the syntax of Java, but the structure of COBOL!
JOBOL programs live in a no man’s land – the COBOL developers can’t read it, and the Java developers won’t touch it!
The Promise of a Brighter Future
The good news is that there are solutions that overcome these limitations. As we’ll see, modern code transformation or cross-compiling solutions can overcome the challenges of earlier versions of these approaches.
Find Out More
Learn more about Renovate.