Having your Java and drinking it too

 

Updated on Jan 11, 2024 with End of Marketing for Java 8, in picture.

Updated on Dec 5, 2023 with End of Marketing for Semeru 11 of April 1, 2024,  in picture. 

Updated on Dec 7, 2023 with End of Service for Semeru 11 of  November 30, 2024, in pictures.

Originally published on August 31, 2023.

Before you even start running z/OS 3.1, there's an important dependency you need to completely understand.  It's the Java dependency for z/OS 3.1.  

In the prior releases of z/OS, we had the luxury of selecting a Java level and keeping on that level for the lifetime of that specific z/OS release.  Not so much anymore.  In the lifetime of z/OS 3.1 we are anticipating relying upon one level of Java, and then having to move to another.  And to make it even more complicated, depending on what timeframe you are looking at, you might have three (or four) levels of Javas in your enterprise at the same time! 

Firstly, let's distinguish between z/OS 3.1's functional dependency on Java vs. your own applications' dependency on Java.  They are different.  There are over a dozen functions in z/OS which have a dependency on a specific Java level.  At z/OS 3.1 GA (September 2023), that dependent level is the IBM Semeru Runtime Certified Edition for z/OS, Version 11 - except for three functions:  XML System Services, Capacity Provisioning Manager, and Infoprint Server.  (Those three functions, immediately at GA, still will require the IBM Java SDK 31-bit V8 level.  Fear not, that is only a planned temporary situation until their Semeru 11 support is released. Use the new SMP/E FIXCAT IBM.TargetSystem-RequiredService.Semeru.11 to verify that you've got all the necessary z/OS 3.1 PTFs installed for Semeru 11 support.)  Your own applications which need Java may or may not rely upon Semeru 11, but do take note:  Java 8, both 31-bit and 64-bit, has announced End of Support for September 30, 2026. Everybody - z/OS and applications - should be off Java 8 by that date.

Now, advance a couple of months.  I'm being vague about a date, as I actually don't have it myself yet.  At this point in time, we'll move our z/OS 3.1 dependency to the next level of Semeru, which will be IBM Sermeru Runtime Certified Edition for z/OS, Version 17.  By the way, Semeru 17 did just recently GA, so it will be available to order with z/OS 3.1 when Shopz moves it to the z/OSMF portable software instance (ServerPac) checklist.  As you can well guess, use the new SMP/E FIXCAT IBM.TargetSystem-RequiredService.Semeru.17 to verify that you've got all the necessary z/OS 3.1 PTFs installed for Semeru 17 support.  However to make it easier and to ensure you had all the Semeru 11 PTFs installed, I'd wildcard with IBM.TargetSystem-RequiredService.Semeru.*.

Why is all this important?  Well, it is important as we've got so many functions that rely upon Java now, and making sure that their dependency is met during the entire lifecycle of z/OS 3.1 could mean the difference between having a function to use, and not having a function to use.  

I've put together a chart to show the z/OS release schedule, and how the Java dependency changes over time.  Notice how the large shaded box covers Semeru 11 to Semeru 17 in the time span of z/OS 3.1.  Also notice how Java 8 is still supported to run on z/OS 3.1, however, just not for the z/OS dependent functions themselves when the complete Semeru 11 support is there.  (All z/OS Java dependent functions can be found in the z/OS Planning for Installation, Appendix B:  Software Requirements for running z/OS.)

Now, let's move into a more complicated situation.  You can see in the chart above, that Java products come and go during the lifetime of z/OS 3.1.  What should you order on Shopz when you order z/OS 3.1?

There is no one easy answer to this if you look out far enough.  Consider this:

• When you order z/OS 3.1, there may be "more" Java's available for ordering than z/OS 3.1 needs.  Specifically, if you order z/OS 3.1 close to GA, you'll have the ability to order Semeru 17, even though z/OS 3.1 might not have moved its functional dependency to it yet.
• When you receive your z/OSMF portable software instance, you will receive all your products together, in a single SMP/E zone.  
• You really should not be deploying products in a software instance that are at their end of service. 
• Today, z/OSMF doesn't have the support to remove an FMID from a Software Instance itself.  However, as any SMP/E user knows, you can do that in a batch job yourself using a process called "dummy function delete".  

Let's put all the information together into more pictures, to help illustrate.  

First scenario:

Let's imagine that you were able to have the most extreme case, which would be that you ordered your z/OS 3.1 portable software instance with four Java's. (Java 8 31-bit, Java 8 64-bit, Semeru 11, and Semeru 17).   Then a year or two later, let's say that three of those four Java's (Java 8 31-bit, Java 8 64-bit, and Semeru 11) had gone out of support.  

There is a major PRO and CON to understand in this scenario.

• PRO:  You can easily install, service, and deploy a single Software Instance.  All dependencies you need for both your z/OS functions and applications are in a nice single unit.  
• CON:  Eventually, pieces of that Software Instance have gone end of service, and you should take a manual action to remove them (SMP/E dummy function delete, with data set and file system removal).  

Second scenario:

Let's imagine that opposite most extreme case, which would be that you ordered your z/OS 3.1 portable software instance with no Java levels, and ordered  all the Java's in separate portable software instances.  This could result in four portables software instances:  z/OS 3.1, Java 8 31-bit and Java 8 64-bit, Semeru 11, and Semeru 17.   Then a year or two later, let's say that three of those four Java's (Java 8 31-bit, Java 8 64-bit, and Semeru 11) had gone out of support.  

There is the opposite PRO and CON to understand in this scenario.

• PRO:  You can easily stop deploying Software Instances which are end of service.  No SMP/E dummy function delete necessary.
• CON:  Multiple software instances means separate installation, servicing, and deployment tasks.  

Other scenarios:

I've show you two extremes above, but there are scenarios which are in between which might be attractive to you. Let's imagine a scenario with a software instance of z/OS 3.1, Semeru 11, and Semeru 17, and another software instance with the older Java 8 for applications that would run on z/OS 3.1.  Here's what that would look like:

Which is right for you?  The answer is that is depends.  Are you comfortable doing an SMP/E dummy function delete to remove an unsupported Java from a Software Instance with a batch job?  Or, would you prefer to keep the Java in separate SMP/E zones and deploy and then stop using, when they are end of service?  

One final reminder:  

This situation that we find ourselves in is the result of a lifecycle direction occurring in Java.  How you order z/OS 3.1 and any Java needs to take that into consideration, as that is how your initial SMP/E infrastructure will deliver to you.