Mainframes excel in supporting large volumes of data, high-speed transaction processing, and secure computing. The Fortune 1000 relies upon mainframes to run their business, and of course, many of those business applications are written in Common Business Oriented Language (COBOL). Various sources claim that there are between 100 billion to 800 billion lines of COBOL code in use today^[1], with over a billion new lines of COBOL being programmed each year. Any pervasively implemented technology that has been in use for a long time, such as COBOL, should be reviewed periodically for ways to improve and modernize it.

One modernization option is to convert the COBOL code to a more modern language, such as Java. When considering whether to convert any COBOL workload to Java, optimization, cost reduction, on-going support, and portability should be top considerations.

Optimization

The first COBOL programs can be traced back to 1960, and by 1970, COBOL had become the most widely used programming language in the world^[2]. Computer hardware, software, and development techniques and requirements change rapidly, which is why modernizing COBOL programs may be necessary.

COBOL programs were initially developed through procedural, structured programming using waterfall design, but many more programmers today are familiar with and use object-oriented programming as a form of development, along with agile development methodology. Today’s programmers understand Java best because it is an object-oriented programming language.

As such, Java is suitable for multi-purpose computing, and it also is portable across multiple hardware platforms. The ability to run the same program on different computers (as long as a Java Virtual Machine is available for the platform) is one of the reasons that Java is one of the most popular languages for new development today.

Cost Reduction

Reducing the cost of their mainframe environment is a continual struggle for most large organizations. According to a recent BMC survey and white paper^[3], IBM monthly license charge (MLC) costs, which are already greater than 30% of a typical company’s overall mainframe budget, are increasing annually by 5% to 11%.

Converting COBOL to Java can have a significant impact on your MLC costs. Java programs can run on the IBM zIIP specialty processor, whereas COBOL program code cannot. And work that is run on a zIIP, instead of a general-purpose central processor (CP), is not included in the million service units (MSU) metrics used to calculate your monthly MLC software charges.

By converting existing COBOL programs to Java, much of that Java workload can be redirected to run on a zIIP. And that means it is not contributing to your rolling four-hour average (R4HA) or your monthly software bill. Therefore, converting at least some of your COBOL programs to Java can contribute to cost savings.

On-going Support

In addition to optimization and cost savings, converting some COBOL programs to Java can provide more continuous support for application code. Support can include problem assessment, troubleshooting, code maintenance, code control, and application integration.

Because most universities no longer teach COBOL and procedural coding, and Java is an object-oriented programming language taught in most college computer science programs, converting some COBOL programs to Java will save time and money on retraining programmers in COBOL. Additionally, a study from zippia^[4] found that most COBOL programmers are over 40 years old. As these programmers age and retire, COBOL will age with them, and it will become even more difficult to hire skilled COBOL programmers.

Portability

The final benefit of Java is its portability. A Java program can be easily transported from one environment to another because the Java source is compiled into bytecodes. The bytecodes generated can be run on any machine with a Java Virtual Machine (JVM)^[5]. 

Converting COBOL to Java

No organization will want to immediately convert all their COBOL code to Java because converting mission-critical COBOL applications is a risky and time-consuming process. Enterprises need to think strategically about which programs would benefit the most from conversion.

The following areas describe some of the difficulties you may encounter when attempting to perform this conversion:

• COBOL and Java are build on different programming paradigms. COBOL is a procedural language, while Java is object-oriented.
• COBOL and Java have significantly different syntax and grammar. Rewriting COBOL code to adhere to Java's syntax can be time-consuming and error prone.
• Some COBOL constructs, such as file handling and certain data structures, do not have direct equivalents in Java.
• COBOL has unique data types and handling for fixed-length records and packed decimal numbers, which are not present in Java.
• COBOL is often used for business-critical applications with complex business rules. Ensuring the accuracy and correctness of the converted Java code can be challenging.
• Migrating COBOL applications to Java requires extensive testing and validation to ensure that the converted code behaves the same way as the original COBOL code.
• If the COBOL application interacts with other systems or databases, you'll need to ensure that the Java code can seamlessly integrate with these systems, which may involve rewriting or adapting communication mechanisms.
• Java and COBOL have different performance characteristics. The Java Virtual Machine (JVM) introduces an additional layer of abstraction, which may impact the performance of the converted code.
• Developers who are proficient in COBOL may not have the necessary expertise in Java, and vice versa. Finding or training developers with the required skills can be a challenge.
• The complexity and size of the COBOL application can significantly impact the difficulty of the conversion process. Larger and more complex applications will require more effort and resources.

Conversion processes can involve a combination of automated conversion tools and manual intervention to ensure the successful migration of COBOL programs to Java. Thorough testing and validation are crucial in maintaining the functionality and reliability of the application after the conversion.

Staying with COBOL

Even with the zIIP-eligibility of Java programs, most organizations will continue to have COBOL programs for a long time. When using zIIPs, programmers need to understand that COBOL code is not zIIP-eligible. Their focus must be on the zIIP-eligible software interfacing with COBOL applications.

Db2’s distributed DRDA workload, parallel SQL queries, SQL Data Insights AI functions^[6], XML processing, and certain aspects of Db2 utilities, for exampled, are zIIP-eligible.^[7] Additionally, certain aspects of Broadcom’s IDMS database system, IBM’s IMS database system, and IBM’s CICS transaction processing system may be zIIP-eligible for certain COBOL workloads.

Sorting is another frequent requirement of COBOL programs. Utilizing zIIP-enabled sort products (such as Syncsort) can also reduce the cost of your COBOL applications through zIIP redirection.

Optimizing Code Requires Strategy

Whether converting COBOL to Java to reduce costs, ensure on-going support, or improve performance or improving COBOL programs with the help of zIIPs, enterprises need to review their workloads to determine which course of action makes the most sense for their mainframe and business needs. Optimizing workloads and mainframe efficiency are key to reducing costs and increasing reliability into the future.

NOTE:

This article was adapted from Craig Mullins’ latest book, IBM Mainframe Specialty Processors: Understanding zIIPs, Licensing, and Cost Savings on the IBM System z, which is now available for purchase on amazon.com