As you might have seen, we have another z/OS Semeru level on the scene - Semeru 25! And as you might have expected, that means the z/OS functional dependency on Semeru has moved up!
This functional dependency applies to both z/OS 3.1 and 3.2. Meaning, we have moved up our dependency for z/OS functions on z/OS 3.1 and 3.2 from Semeru 21, to Semeru 25. There are expected fixes which provide this Semeru 25 support, and you can find them with the FIXCAT IBM.TargetSystem-RequiredService.Semeru.25.
Of course, I always recommend using a wildcard for the Semeru level so that you have all the prior dependent fixes installed. Meaning, I recommend using IBM.TargetSystem-RequiredService.Semeru.*.
While the end of support for Semeru 21 hasn't been announced yet, it is expected to be in support for 3 years after its GA in November 2024, which would mean it might be around November 2027. You should be planning on moving from Semeru 21 to Semeru 25 before Semeru 21 is end of support.
Because our z/OS functional dependencies on Semeru change frequently and because the Semeru change also affects two releases of z/OS we've decided to keep the z/OS-Semeru requirement in a single location to make it easier to find on the IBM Support website. If you favorite this location, https://www.ibm.com/support/pages/node/7240923, you can know what the current z/OS Semeru requirement is, what z/OS elements have Semeru dependencies, what the default Semeru installation path is (for your java_home location), and pointers to some handy links.
Of course, the z/OS Planning for Installation book is the official publication for all the z/OS dependency information. This book has been updated to point to this IBM Support location. Do keep in mind, that this Semeru dependency change is associated with z/OS functions. As long as your own applications are using a supported IBM Java or IBM Semeru level, you can continue to run that level on z/OS. z/OS 3.1 and 3.2 run every supported level of IBM Java and IBM Semeru.
A word, now, about how to accommodate these changing Semeru levels. Because these Semeru levels change more often that z/OS releases change, it might make sense to keep them in a separate set of SMP/E zones. Of course, the decision is yours, but when you keep z/OS in one set of zones, and Semeru levels in another set of zone (sharing GLOBAL zones is perfectly fine!), you may find it easier to switch out one level for another. I did write an earlier blog about this if you wanted to read more about ordering and separation considerations.
If you do decide to keep IBM Semeru 25 in a separate set of SMP/E zones (even in the same GLOBAL zone as your z/OS system), I'd strongly recommend ordering it from Shopz as a z/OSMF Portable Software Instance. In that way, you can deploy it in the z/OS GLOBAL zones directly and keep your Semeru zones separate, you can take advantage of your existing automation on service acquisition (RECEIVE ORDER), and you can even employ automatic cross-zone requisite checking so that any service dependencies are continually being verified. Of course with a z/OSMF Portable Software instance your data sets will be sized with approximately 25% free space (no running out of space) and arrive pre-serviced with the latest Recommended Service, HIPERs and any PE correcting fixes.
Then, when the time comes to move up to the next IBM Semeru level, you can install that new level in the same fashion and even "drop" the old Semeru level zones.
Enjoy your new fresh cup of coffee!
Comments
Post a Comment