Mainframes continue to be viable for enterprise computing due to their inherent capabilities for supporting the most critical business functions. When it comes to supporting large volumes of data, high-speed transaction processing, and secure computing the mainframe continues to excel. The Fortune 1000 relies upon mainframes to run their business, and of course, much of those business applications are written in COBOL.
Indeed, a large number of mainframe applications are written in COBOL and new COBOL code is being written all the time. Various sources claim that there are between 100 billion to 800 billion lines of COBOL code in use today with over a billion new lines of COBOL being programmed each year.
Although it is wise to doubt the precise accuracy of such hyperbolic, large numbers, it is undoubtedly true that there is a lot of COBOL code running on mainframe systems. And that code powers important enterprise applications. In other words, COBOL is everywhere, so it should be a significant target for improvement.
Any pervasively implemented technology that has been in use for a long time, such as COBOL, should be reviewed over time for ways to improve and modernize it. One such option is to convert the COBOL code to a more modern language, such as Java. There are three primary reasons why you should consider converting some of your COBOL workload to Java.
• Optimization
• Cost Reduction
• On-going Support
Optimization
The first COBOL programs can be traced back to 1960, which is a long time ago in the realm of computers and technology. By 1970, COBOL had become the most widely used programming language in the world. (source: Beyer, Kurt. Grace Hopper and the Invention of the Information Age. MIT Press. 2009. ISBN 978-0262013109.)
The current portfolio of existing COBOL programs spans a 60-year period. Technology changes rapidly, especially computer hardware and software, as well as development techniques and requirements. So, it stands to reason that a lot of COBOL code “out there” could benefit from a more modern approach.
For example, procedural, structured programming using waterfall design was the primary development paradigm for at least the first half of COBOL’s life. In the 1990s, object-oriented (OO) programming became the dominant form of development, along with the agile development methodology.
COBOL is a procedural programming language, whereas Java is object-oriented. More programmers today know and use OO techniques instead of structured techniques. So, it is not just that more programmers know and understand Java, it is that they know and understand a completely different form of application programming than is used with COBOL.
Optimizing ancient procedural COBOL code into the new OO, Java paradigm can make a lot of sense. Furthermore, consider the types of applications that are well-suited for COBOL. The term COBOL is an acronym for Common Business Oriented Language. The language was designed to support business functions like reporting, number crunching, and processing data. This does not mean that COBOL cannot perform other types of processing; it can. Just that some types of programs may be better developed using another language.
Java is an object-oriented programming language that is suitable for multi-purpose computing, with the added benefit of being portable across multiple hardware platforms. The ability 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.
So, optimization of your aging COBOL code into a more modern paradigm is one reason to consider converting some of your programs to Java.
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, IBM monthly license charge (MLC) costs, which are already greater than 30 percent of a typical company’s overall mainframe budget, are increasing annually by 5 percent to 11 percent.
Converting COBOL to Java can have a significant impact on your MLC cost. Java programs can run on the IBM zIIP specialty processor, whereas COBOL program code cannot. And work that runs on a zIIP instead of a general-purpose CP is not included in the 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
The third reason it can make sense to convert COBOL programs to Java is to provide better on-going support for your application code. Support includes things like problem assessment, troubleshooting, code maintenance, code control, application integration, and other code-related duties.
It can be difficult to find skilled COBOL programmers. Most universities no longer teach COBOL and procedural coding. So many organizations hire programmers with other skills and train them on COBOL (if they can convince a prospect to accept a COBOL job offer).
On the other hand, it is easier to find programmers with Java skills. And there are more Java coders being trained every day in universities and trade schools everywhere.
Another consideration is the aging COBOL workforce. According to a study by zippia, most COBOL programmers are over 40 years old. As these programmers age and retire, COBOL will age with them, and unless something changes dramatically it will become even more difficult to hire skilled COBOL programmers.
On the other hand, Java is a newer, thriving language. It is object-oriented, taught in most college computer science programs, and one of the world’s most popular current programming languages.
The Bottom Line
By now you should be convinced that there is some merit in converting some of your COBOL applications to Java. Of course, no organization is going to immediately convert all their COBOL code even if there are significant potential gains to be had. The risk involved in converting all your mission-critical COBOL applications would likely be too large to undertake in one big step.
Nevertheless, strategically identifying and converting COBOL to Java is a tactic that can reap substantial benefits. Optimizing your development environment, reducing cost, and improving support are compelling reasons. Still manually converting from COBOL to Java can be tedious and time-consuming. Fortunately, CloudFrame provides several options for automating the conversion of COBOL to Java that can reduce the time, effort, and human error involved in conversions.
Have you considered the potential benefits of converting some of your older COBOL applications?
Find Out More
To learn more, check out our ebook,
The COBOL Modernization Opportunity.