Java - Group home

Background

Phoenix Software International is (primarily) a mainframe software development shop. Among other things, we develop products with Java components that can run standalone in a JVM under TSO/E or in batch, along with more complex products that run under the Apache Tomcat® and/or Open Liberty™ open source “pure Java” HTTP web servers. We also install and maintain our own on-premises z/OS systems, which include z/OSMF and other IBM-developed software products that use Java.

The Semeru Mid-Term Upgrade “Scare”

For reasons of practicality, Semeru’s lifecycle dates are aligned with the Red Hat OpenJDK rather than with z/OS. Furthermore, Semeru adheres to IBM’s “standard” 3+2 software support lifecycle policy  rather than the “enhanced” 5+3 policy to which most z/OS sysadmins are accustomed. Semeru 11 was the de-facto Java release paired with z/OS 3.1. Many z/OS 3.1 products and components don’t work with Java 8, making production deployment of Semeru 11 a necessity. Semeru 11 was first released in 2021 and its end of service date was announced to be November 2024. This unfortunate combination of events was forcing z/OS 3.1 clients to perform mid-term upgrades to Semeru 17 just over a year into the z/OS 3.1 lifecycle. Yikes!

Naturally, we would have upgraded our Java-based product suite to work with Semeru 17 no matter what, but it’s likely we would have left well enough alone with IBM’s z/OS products had it not been for this end of support issue with Semeru 11. As a result – you guessed it – we upgraded everything running in our z/OS 3.1 environments to use Semeru 17. No more Java 8, no more Semeru 11. But how difficult was that journey?

Before we answer that question, let’s talk about some late-breaking news. The pressure is off! IBM recognized the difficult position these lifecycle conflicts were creating for their clients and announced a support extension for Semeru 11 through the end of November 2025. IBM’s z/OS clients can breathe a collective sigh of relief. Whew!

Our Transition from Java 8 to Semeru 11

When we installed z/OS 3.1, we discovered that some of IBM’s products (e.g., z/OSMF, SMP/E) continued to operate just fine with Java 8 while others (PFA, DFSMShsm, etc.) failed unless they ran with Semeru 11. For the most part, it was trivial to ensure IBM products ran with Semeru 11. Most of our JAVA_HOME references are /usr/lpp/java/current or /usr/lpp/java/current_64, so we didn’t have to do anything beyond ensuring those symbolic links pointed to /usr/lpp/java/J11.0_64. IBM service maintains those links for you, so if you’re not using them today, now might be a good time to consider doing so. It could make upgrading easier next time.

Things were more challenging for products that dug a bit deeper into the Java directory tree. For example, PFA’s INI file contained these environment variables:

PATH= /usr/lpp/java/J8.0_64/lib/s390/classic:/usr/lpp/java/J8.0_64/lib/s390
LIBPATH=/usr/lpp/java/J8.0_64/lib/s390:/usr/lpp/java/J8.0_64/lib/s390/classic:/lib:/usr/lib:

which, after reading the updated configuration instructions, we changed to this:

PATH=/usr/lpp/java/J11.0_64/lib/j9vm:/usr/lpp/java/J11.0_64/lib
LIBPATH=/usr/lpp/java/J11.0_64/lib:/usr/lpp/java/J11.0_64/lib/j9vm

We installed Semeru 11 for our developers back in the summer of 2022. As expected, there were a few minor configuration updates they had to make. One that significantly impacted our product deployment scripts was a seemingly-arbitrary change in the URL format used to specify the SAF key ring name to the keystore utility. In Java 8 this URL began with safkeyring: and in Semeru 11 it was changed to begin with safkeyringjce: instead. This change meant we had to update those scripts to provide different URLs depending on the client’s target Java environment. We used IBM’s Ideas Portal to request the original format be accepted by Semeru 11 and higher. Too late for us, but hopefully not for you, IBM delivered this idea in December 2023, so that’s one less thing you will have to worry about.

The only challenge that actually impacted our code was a class that was moved by Oracle out of the Java main distribution and into an external package. We use that class for generating PDF documents and our Java developers had to find a way to deal with that change while still seamlessly supporting both Java 8 and Semeru 11 runtime environments. We didn’t have any 31-bit Java dependencies. All of our JNI code (both C/C++ and HLASM) was already 64-bit, which was extremely helpful since IBM no longer provides 31-bit JVMs after Java 8. If you still have 31-bit dependencies, you have some work to do before you can upgrade that code to use the Semeru runtime. The good news is Java 8 works great under z/OS 3.1 and is supported until the end of September 2026, so you can keep it around just for those few applications you’re having trouble with.

Our Transition from Semeru 11 to 17

With the transition from Java 8 to Semeru 11 still fresh in our minds, the z/OS upgrade to Semeru 17 was a relatively-easy one. We did have a bit of difficulty at first finding Semeru 17 in the ShopZ product catalog but, once that was all ironed out, it downloaded and installed just like any other z/OS product. We far prefer SMP/E product installs (including z/OSMF Portable Software Instances) over web download installs because we automate the service retrieval process with RECEIVE ORDER. IBM established an IBM.TargetSystem-RequiredService.Semeru.17 fix category to make finding the right z/OS PTFs easy. It's probably a good idea to have Semeru 17 installed before you activate any of them on a system. Using this procedure, we had zero problems with anything in the z/OS stack.

Zowe did not work at first, but we got some help from the Zowe developers via their slack channel. Their configuration script updates can be found on GitHub and, with those updates applied, Zowe works fine.  Our Java developers were happy because only minor configuration changes were needed to upgrade our product suite to support Semeru 17. No source code changes were needed, it just worked! 😊

In Summary

We think IBM did a great job making the transition to both Semeru 11 and 17 as painless as possible for their z/OS clients. The “Migrating” chapter, located at the beginning of the Semeru SDK User Guide, has proven to be of immense help to developers and sysadmins alike.

The recent announcement supporting Semeru 11 through November 2025 reveals IBM’s desire to shield its z/OS clients, who religiously upgrade z/OS every two years, from ever having to perform a mid-term Semeru upgrade. That’s hands down the right thing to do for those clients. However, as things stand today in this fast-paced IT world, clients that upgrade their z/OS systems less often must expect and learn to deal with occasional mid-term Java runtime release upgrades.

z/OS 3.1 is expected to be supported through the end of September 2028. The currently-announced EOS dates for the IBM Java runtimes are shown in the table below. We think you’ll agree, the most-reasonable upgrade choice at this time is Semeru 17 and even it will not outlive z/OS 3.1. Keep in mind, it won’t be long before Semeru 25 and the next z/OS release are on our RADAR providing us with additional options and work to do in this ever-evolving space.

Whether mid-term or on a release boundary, a Java runtime upgrade is in your future. Our developers and sysadmins weathered the challenge and tried to make things easier for those that follow in their footsteps. Hopefully this glimpse into our experiences will help you better navigate your next Semeru upgrade.

Contributed by Ed Jaffe, Chief Technology Officer at Phoenix Software International

About Phoenix Software International

Phoenix Software International, Inc., (https://www.phoenixsoftware.com) is a systems software development company providing advanced software applications to enterprises around the globe. The company offers a wide range of solutions to modern business challenges.