Modernizing COBOL for Maintainability, Automation, and Quality

The debate as to whether you should or shouldn’t modernize any portion of your application portfolio is a separate question to the ways to do it correctly. While many people discuss “COBOL modernization,” there is much more involved than simply translating the syntax of COBOL to the syntax of another language. The keys to effectively modernizing COBOL applications must include considerations for maintainability, code quality, and computational precision.

Transforming the syntax of COBOL to that of another procedural language is readily automated. The problem is more complex when an architectural change to an object-oriented language needs to occur. COBOL programs are often tightly coupled to the platforms upon which they run, particularly the IBM mainframe, and have dependencies on the underlying architecture.

As such, converting a COBOL program involves more than simply transforming the language – it also requires a shift away from the dependencies on the underlying runtime software. These dependencies include data typing, data and file structures, runtime APIs, and pre-relational DBMS navigation. The changes that must be made to support these differences must be done in a way that ensures the code can be maintained in the future.

To be successful, the new code must be as close a match to, say, Java coding standards and techniques as possible, rather than simply a direct syntactical translation of the code. Coding styles and strategies are very different between traditional procedural languages like COBOL and a modern object-oriented style program. If you preserve the COBOL approach, albeit in Java, maintainability will suffer.

Some of the measures of maintainability have to do with coding styles and practices, which are often different by language and are CERTAINLY different between COBOL programs and Java programs. Other measures are a function of the QUALITY of the code that is created. Code quality has an impact on software quality. Good quality software does what it’s supposed to do in a well-documented and easy-to-understand way. Ideally, code should follow a consistent style in its construction, as this style is often a part of the programmer’s fundamental understanding of development.

When the fundamental architecture of the program needs to change from “process first” to “object first,” then more steps are required to generate high-quality, maintainable code. For example, the Data Division is the section of a COBOL program that defines the objects that are being manipulated by the paragraphs in the Procedure Division. In the most straightforward description of this approach to transformation, objects are sourced from the Data Division, and the Methods used to manipulate the attributes of the object are sourced from the paragraphs of that Procedure Division. The process is generally much more complicated than this, but at the highest level, this is how it works.

Complications are also introduced because of the difference between the mainframe character set used to represent data (EBCDIC) and that associated with almost every other computing platform (ASCII). In addition, mainframes have data types, such as packed decimal, that don’t always exist in other computing architectures. These differences represent the underlying and often less understood changes that must be addressed when migrating COBOL code to Java.

The mathematical precision of Java code that is a DIRECT translation from Java may yield different values than what was generated by the original COBOL program. Here’s an example of a compound interest calculation using both COBOL and Java:

COBOL :

WS-AMT WS-PRINCIPAL PIC S9(13)V9(5) COMP-3,

WS-INTEREST PIC S9(5)V9(8) COMP-3,

WS-YEARS PIC S9(5) COMP-3

COMPUTE WS-AMT = WS-PRINCIPAL * (1 + (WS-INTEREST-RATE / 100)) ** WSYEARS

Java :

double principal = 1053427090.98, interestRate = 11.3698, years = 5

double amount = principal * Math.pow ( ( 1 + ( interestRate / 100) ) , years);

COBOL Answer:           1804852352.10823

Java Answer:               1804852359.9381807

So, which is the correct calculation? History says the value from the COBOL program is the correct one. In some cases, differences may be so small that it doesn’t matter. In others, it will be significant. Recognizing these differences and managing customer expectations are as important as getting to the EXACT SAME NUMBER!

Using strong grammar-based parsers, abstract syntax tree representational techniques, and a rules-based migration technology represent the cost of entry to a COBOL modernization strategy. These elements provide the basis for an effective, performant, repeatable, and tailorable approach to mainframe modernization.

An IT modernization strategy, such as code transformation, is one of the best ways to future-proof your legacy applications. Doing so removes dependencies from legacy computing architectures and structures and makes these applications truly cloud-advantaged!