Our last post looked at the five significant benefits of Java and zIIPs, detailing how the combination can reduce cost, simplify support and maintenance, deliver the performance you need, and improve portability. But most enterprise mainframe applications are written in COBOL.
Now, most organizations are not likely to embark on a full-fledged campaign to convert all of their COBOL to Java. But converting some programs to Java can make sense if you use the proper approach.
COBOL is Still Prevalent in Large Enterprises
Unless you work in a mainframe environment, it might surprise you that COBOL is still being used. But it is. And its usage is significant!
COBOL was designed for business data processing, and it is exceptionally well-suited for that purpose. It provides features for manipulating data and printing reports that are standard requirements for business. COBOL was purposely designed for applications that perform transaction processing like payroll, banking, airline booking, etc. These are programs where you put data in, process that data, and send a result out.
COBOL was invented in 1959, so its history stretches back over 60 years; a lot of time for organizations to build complex applications to support their business. Over the years, IBM has delivered new capabilities and features that enable organizations to stay updated as they maintain their application portfolio. The current situation is that COBOL is in wide use across many industries.
Most global financial transactions are processed using COBOL, including 85 percent of the world’s ATM swipes. According to Reuters, almost 3 trillion dollars in DAILY commerce flows through COBOL systems! The reality is that more than 30 billion COBOL transactions run every day. And there are more than 220 billion lines of COBOL in use today.
But COBOL applications face many challenges as experts in the field retire and new developers are not trained in procedural languages like COBOL. Instead, colleges teach object-oriented languages, like Java. So new applications are commonly written in Java, even as legions of older applications remain in COBOL.
Even if converting everything at once from COBOL to Java will be too monumental of a task for most organizations, converting some COBOL to Java can make a lot of sense. It all boils down to your mindset and needs. I guess the question I would ask is, “What type of fool are you?”
An old adage states: There are two different types of fools. One naively embraces and extolls everything old; the other credulously praises everything new. Do you embrace COBOL or praise Java? You can and probably should avoid being either type of fool by doing both! Yes, COBOL and Java can co-exist, perhaps for a long time, as you migrate your way to Java.
The Challenges of Maintaining COBOL
As you put your plan together, you might consider converting some of your COBOL applications to Java. An upcoming event (such as the end of support for a COBOL compiler or a wave of retirees hitting your development staff) may offer a ripe opportunity for converting.
Or you may want to take advantage of the benefits discussed in the last blog post, such as lower cost of running your applications, better portability, and improved application support. Nevertheless, converting to Java is a viable option, and many organizations are considering doing so, at least for some of their programs.
Keeping in mind the concerns about “all-or-nothing” conversions, most organizations will be working toward a mix of COBOL migrations and Java conversions, resulting in a mixture of COBOL and Java for their application portfolio.
As you plan for this, analyze and select appropriate candidate programs and applications for conversion to Java. Some tools can analyze program functionality to assist you in choosing the best candidates. For example, you will probably want to avoid converting programs that call other COBOL programs and programs that use pre-relational DBMS technologies, at least initially.
Converting COBOL to Java: Transpile and Cross-Compile
At this point, you may be thinking, “Sure, I can see the merit in converting some of my programs to Java, but how can I do that? I don’t have the time for my developers to re-create COBOL programs in Java going line-by-line!” But manual conversion is only one option, and it is by far the least desirable.
Using an expert toolset to automate code conversion makes a lot more sense. Using CloudFrame technology, you can perform two different types of automated coded conversion: transpile and cross-compile.
With transpile, COBOL source code is automatically refactored into Java without changing data, schedulers, or other infrastructure components. It is fully automated and seamlessly integrates with the change management systems you use on the mainframe.
The Java code generated by CloudFrame will operate the same as your COBOL and produce the same output. You can even use options to maintain the COBOL 4.2 treatment of data, thereby avoiding the invalid data issues that can occur when you migrate to COBOL 6. This can help to reduce project testing and remediation time.
Perhaps even more importantly, the Java source code generated is Java, not a Frankenstein monster Java/COBOL combination that some folks refer to as JOBOL. The goal is to create Java code that is Java developers will recognize as Java and be able to support without knowing any other legacy programming languages. Java code generated by CloudFrame regularly earns an “A” rating when processed by SonarCube code quality scoring (such as reported in this customer case study).
So, using CloudFrame to transpile your COBOL code to Java is a viable automated route for migrating to code that can be supported and maintained by Java programmers. Another option may be more palatable to long-time COBOL shops is the CloudFrame cross-compile option.
With cross-compile, you can use CloudFrame to refactor the COBOL to Java but keep maintaining the code in COBOL. So the source code is COBOL, but it is cross-compiled to run in a JVM, thereby making the workload zIIP-eligible. This approach is more fully described in this blog post (Consider Cross-Compiling COBOL to Java to Reduce Costs). It is also an excellent capability for shops with a lot of COBOL who are not comfortable transpiling everything to Java. You keep your COBOL until you are ready to shift to Java. At any time, you can quickly fall back to your COBOL load module with no data changes. The Java data is identical to the COBOL data except for date and timestamp.
Simply stated, CloudFrame offers automated software for transpiling COBOL code to Java and running completely using only Java. Or, if you are comfortable with your ability to support and code your applications in COBOL but are looking for the cost-savings that zIIPs can provide, then CloudFrame’s cross-compile capabilities may be just what you are looking for.
Craig Mullins, Copyright Craig Mullins Consulting, Inc