It’s estimated that there are still between 200 and 250 billion lines of COBOL code in production. Around 70% of large corporations rely on COBOL for much of their mission-critical work. It’s also been estimated that there are 1.5 billion new lines of COBOL written each year. Currently at Version 6.4, COBOL uses an English-like syntax to describe almost everything in the program. That has two consequences. Firstly, it’s verbose, ie quite long compared to other languages. Secondly, it’s almost understandable, so it doesn’t need too many comments!
The past
COBOL was designed by CODASY (the Conference/Committee on Data Systems Languages) in 1959, but it has been updated since then. In 2002 it became object-oriented. It’s the programming language behind most ATMs, for example. IBM Enterprise COBOL for z/OS 6.4 was released this year (2022). It was used as the language of choice for most of the mainframe application programs written in the 60s, 70s, and 80s.
The present
Although COBOL was very popular with many people able to code using it, we now find ourselves in a situation where there are plenty of COBOL programs on mainframes running business-critical applications, but very few COBOL programmers available to modify those programs. Most teaching establishments focus on other programming languages with the emphasis on Java, Python, and similar languages.
This has led some organizations to consider transferring their COBOL programs to a modern language. And, I imagine, at the same time, the external companies brought in to help with this ‘translation’ would recommend changing their database and moving away from that ‘ancient’ mainframe!
An alternative approach is to do something that won’t affect the original COBOL code, but will make it accessible to modern programmers. And that is to use APIs. Application Programming Interfaces can be added to COBOL programs to link them to modern applications. In effect, there is a layer of middleware that will link RESTful applications from the front end with those venerable COBOL programs. Typically, this will maintain security, analytic, and audit requirements. That, in effect, for the time, negates the problem with people not being able to ‘read’ the source code. And it allows your organization to move to DevOps ways of working.
The future
There are plenty of applications that can be used with COBOL. And it is likely that in the near future these applications will be used much more. For example, the Open Mainframe Project has COBOL Check, which enables unit testing for COBOL applications on IBM Z mainframe. It also supports micro testing off-platform on Windows and Linux. The program is meant to improve the design, understandability, maintainability, and longevity of core business applications and supports IBM's mainframe modernization program by enabling restructuring of existing applications of APIs.
Making using those COBOL programs easier for people who don’t have a long history of working on a mainframe, there’s the ZoweTM Command Line Interface (CLI) interface, which leverages IBM Z Workload Scheduler extension of the Zowe CLI to manage job and jobstream submission and monitoring. It provides a way to schedule those COBOL jobs on the mainframe.
Automation is clearly the way forward. IBM Robotic Process Automation (RPA), for example, provides a way to automate business and IT processes at scale. These software robots (bot) can act on AI insights to quickly complete repetitive tasks.
Business processes can be improved using process mapping software like IBM Blueworks Live. It's cloud-based software that provides a dedicated, collaborative anywhere environment. Existing processes can be mapped quickly. And this can be used to identify efficiencies that can be made.
IBM also supplies IBM® Automatic Binary Optimizer for z/OS® (ABO), which lets users improve the performance of already compiled COBOL programs without needing to recompile them. ABO takes the compiled COBOL program modules as input. It doesn't need the source code, source code migration, or performance options tuning. It can then improve the performance of those COBOL modules.
With the growing use of Docker and Kubernetes we’ll see COBOL programs being used in containers to help organizations to modernize and better secure their systems and data, while streamlining the work. Existing COBOL application can be deployed as a batch job to the IBM Cloud Kubernetes Service.
With the growing use of Java, those programmers may want to link to a CICS program with a COMMAREA or to access a VSAM file. This, typically, needs a way to map the underlying record structure from a high-level language copybook to Java data types. Java data bindings in IBM Developer for z/OS can be used to create Java classes from COBOL data structures. These classes can then be used as input or output types in a CICS Java program that interacts with record-based language structures.
The Java EE Connector (J2C) tooling in IBM Developer for z/OS uses a set of wizards called the CICS and IMS Java data bindings. Part of the generation process lets users specify the encoding of character and numeric data types to correctly convert data when passing data from Java to the EBCDIC runtime in CICS.
Alternatively, the IBM Record Generator for Java can be used. This scriptable Java-based utility takes as input the ADATA from the COBOL compiler, and uses it to generate Java helper classes to access the fields in a COBOL record structure. The ADATA provides additional program data that can be used to extract information about the program for symbolic debugging or cross-reference tools.
For programmers who have grown up with Python, Github has a COBOL Copybook parser in Python. The code allows users to:
- Parse the Copybook into a usable format to use in Python
- Clean up the Copybook by processing REDEFINES statements and remove unused definitions
- Denormalize the Copybook
- Write the cleaned Copybook in COBOL
- Strip prefixes of field names and ensure that the Copybook contains only unique names
- Use it from the command-line or include it in other Python projects.
In fact, Github also has opensource COBOL 4j, which is a COBOL compiler that translates COBOL programs to Java programs. And there’s opensource COBOL, which translates COBOL program to C code and compiles it using GCC or CL
Looking forward to including COBOL programs in an AIOps environment allows any incidents to be detected earlier, and then fixed, minimizing their impact on customers. This is particularly important in hybrid cloud environments, where some applications have moved to the cloud and new ones are being developed. AIOps provides a central point for monitoring what's going on.
Conclusion
While COBOL has been around since 1959 and is heavily used by enterprises today, there are so many advances in the way it can be used and integrated with other technologies, that it won’t be disappearing any time soon.