This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
To start at the beginning, follow this link to the first post.
The next post in the series is here.
---------------
We’ve talked already about how Liberty on z/OS is delivered as part of the WAS on z/OS product. But there’s also a copy of Liberty included with z/OS itself. You can find it down in the /usr/lpp directory as you might expect. But what it is doing there?
Over the first few years after Liberty became available, quite a few IBM software products for z/OS wanted to run at least some part of their application in Liberty. There are, of course, IBM products on other platforms that do the same thing. In those situations the IBM products pick up a copy of Liberty and embed it in their product (well, at least until Open Liberty turned up). Thus IBM products on z/OS did the same thing.
Unfortunately, this resulted in customers who might be running half-a-dozen different IBM products then having half-a-dozen different copies of Liberty. Why is that bad? Well, consider what happens if a security/integrity exposure is found and Liberty delivers a fix. Customers that have WAS z/OS as a product get that fix and install it and they are done.
But customers running IBM products that include a copy of Liberty need to fix those copies also. For that to happen, all the different IBM products need to get the fix from Liberty and package it as a fix on their product (since Liberty is “inside” their product their customers can’t just install the Liberty fix directly..usually). All this takes time, and makes everybody’s life complicated.
To try to make this easier, a decision was reached to deliver a copy of Liberty for z/OS as part of z/OS itself. IBM software products on z/OS could then just exploit this single copy of Liberty and fixes could be packaged and delivered for that and we’d be done. Sounds great!
Well, maybe. How do we apply regular maintenance? Liberty delivers a new maintenance level approximately every four weeks. Would we just update that built-in copy with that new level every time one comes out? Well, most stack products don’t generally need the very latest level, and don’t really have the time/resources to test against every new Liberty level that comes along (customers don’t usually upgrade that fast either for servers hosting their own applications). The generally recommended approach is to stick with the divisible-by-3 levels (the .3, .6, .9, and .12 levels that come out roughly in March/June/September/December).
That too was thought to be maybe a little fast, plus there was another problem. What if a customer has two different IBM products using the built-in Liberty and some new maintenance breaks one of the products. Then the customer can’t update the built-in Liberty (maybe needed by the other product) until the problem product gets fixed. Add a few more IBM products in and it becomes a big mess…again.
So it was decided to keep two levels, one slightly older than the other. After some fussing about we settled on keeping the .3 and .9 levels. So roughly in April and again in October you’ll see updates, but we’ll keep two levels around. For example, at one point in time z/OS included Liberty levels 21.0.0.3 and 21.0.0.9 and then around April of 2022 we removed 21.0.0.3 and replaced it with 22.0.0.3. Any IBM product that had a problem with 22.0.0.3 could stay on 21.0.0.9 for six months until it too was replaced in October, 2022.
Oh, and I should mention that the z/OS license allows you to use this copy of Liberty for your own “non-production purposes”. Such use is unsupported, of course. See the official z/OS terms and conditions for the paragraph-long definition of “non-production”.