Java and the zIIP: The 5 Major Benefits

In this series of blog posts on the zIIP, we have looked at the various types of specialty processors and the zIIPs place among them, honed in on zIIP usage and eligibility issues and terms and examined the types of processing that can utilize zIIPs. Having digested all of that information, we will turn our attention to Java and take a look at the five most significant benefits it can bring to your environment.

Before we delve into the benefits of Java, let’s face it, the predominant language used by most mainframe applications is COBOL. According to Reuters, there are over 220 billion lines of COBOL code running production workload. That’s a lot! But there are issues with COBOL as it is not taught in university computer science curricula, is a procedural language that is no longer in vogue, and is quite verbose. That said, lots of  COBOL code exists and continues to work well.

Nevertheless, not much new work is being done using COBOL. Many new mainframe applications are written in Java, perhaps due to the following benefits.

1 – Reduced Cost

The first, and most important benefit, is that using Java can help you reduce your monthly IBM software bill. Java workload is zIIP eligible, and any Java workload that gets redirected to run on the zIIP will not be chargeable against your monthly bill.

As discussed in my previous blog entry, 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. These metrics are calculated as a rolling four-hour average (R4HA) of LPAR MSU usage. The monthly LPAR peak of the R4HA, by product, determines your software bill. That means you are paying for capacity on a rolling four-hour average, not on the maximum capacity of your system or the maximum capacity utilized at any given point in time.

So easy enough, if you are adding Java workload (or converting existing workload to run on a JVM) and that work is redirected to and runs on a zIIP, it is not contributing to your R4HA or your monthly software bill. And the cost of the zIIP hardware itself is much less than the CPU the workload would run on if it were not zIIP eligible, meaning the cost savings are accumulated for multiple reasons.

Therefore, running Java instead of other types of work can significantly contribute to cost savings.

2 – Easier to Support

The next benefit of Java is that it can be easier to support than COBOL for various reasons. As we alluded to earlier in this post, COBOL is aging, as are the programmers capable of coding and maintaining it properly. Of course, COBOL’s age is not the problem; plenty of older things remain viable and thrive. And COBOL has not stayed static, stuck in the 1950’s when it was developed. Nevertheless, skilled COBOL developers are not easy to find.

On the other hand, Java is a newer, thriving language. First released in 1995, I wouldn’t call Java shiny and new. Still, it is modern in that it is object-oriented, is taught in most college computer science programs, and is one of the world’s most popular current programming languages. Java regularly ranks in the top three languages of the Tiobe Index, which tracks the popularity of computer programming languages.

3 – Code Maintenance

Having an easy-to-understand and -maintain code base is important to ensure effective application development and support. From the perspective of converting COBOL code to Java, though, this may be easier said than done. You agree that there is merit in converting some of your COBOL programs to Java, but how? Nobody has the time to sit down a recode their applications line by line!

Converting from any programming language to another is a complex task that takes a long time and results in less-than-satisfying results. Without care and expertise, the converted code will not be efficient and is unlikely to take advantage of all the features of the target programming language. Even a derisive term, JOBOL, has been created to describe COBOL code that was not effectively converted to Java. In other words, it may be Java, but it looks and feels like COBOL still.

The key is to use conversion services built to understand how to convert from a procedural language like COBOL to an object-oriented language like Java. This is where an automated tool comes in handy. The CloudFrame Renovate and Relocate products provide code conversion tools, automation, and DevOps integration to deliver very maintainable, object-oriented Java that can integrate with modern technology available within your open architecture.  It can be used to refactor COBOL source code to Java without changing data, schedulers, and other infrastructure components. It is fully automated and seamlessly integrates with the change management systems you use on the mainframe.

CloudFrame improves the business value of modernization by driving down the risk and effort required.  Using CloudFrame services, you can convert COBOL to refactored Java that a Java programmer can work with effectively. In other words, it’s not JOBOL. The Java code generated by CloudFrame will operate the same as your COBOL and produce the same output.

You can even use CloudFrame to refactor your COBOL to Java but keep maintaining the code in COBOL. Such an approach can allow you to keep using your COBOL programmers for maintenance and gain the zIIP eligibility of Java when you run the code.

4 – Speed?

Everybody knows that Java is slow, right? That is one of those common knowledge items passed around from mainframer to mainframer for so long that few question it any longer. This may have been true a decade ago, but today, sometimes Java can run as fast as, or even faster than COBOL.

Some CloudFrame customers have found that the refactored Java was running faster than the COBOL that they were converted from. Of course, this is not to say that Java will consistently outperform COBOL, just like it is not fair to say that COBOL will consistently outperform Java.

Another consideration: if the Java code runs on a zIIP, and your main CPU is a knee-capped model, then the higher speed of the zIIP, which is never knee-capped, may cause your Java code to run faster than the equivalent COBOL.

5 – 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 JVM. 

Summary

There are numerous benefits to modernizing your mainframe workload to run on Java. Among these benefits are reduced cost, easier support and maintenance, similar or better performance, and expanded portability.

Craig Mullins, Copyright Craig Mullins Consulting, Inc

Find Out More

Learn more about Relocate.

FIND OUT MORE

Download cloudFrame Relocate Product Fact Sheet

Related Articles

Next Event

Recent Events