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.

The next post in the series is here.

To start at the beginning, follow this link to the first post.

---------------

If you have a production WAS z/OS traditional environment and you’re moving some or all of that workload to Liberty on z/OS, you might be concerned about how your SMF processing might be different in this new environment.

Whether you have any changes to worry about depends a lot on what record types you were monitoring with traditional WebSphere.  If you were looking at the address space level records (type 30) then instead of looking at controllers and servers you now just have server address spaces.  If you looked at enclave CPU time in traditional, it was always kind of weird because that showed up in the controller’s type 30 records even though all the CPU was actually consumed in the servant region (because the controller created the enclaves).  That weirdness goes away with Liberty because everything happens in the single address space.

You might also have looked at the SMF Type 72 records showing how the WLM classified work did, reported by service and report class.  This may or may not change depending on how you’ve chosen to classify the work running in Liberty.  If it is the same applications (more or less) then you might have decided it has the same goals and just put it in the same exact same service and report classes in which case nothing will change at all (maybe it will run a bit faster…).  If you did change service/report classes for work in Liberty (or it is new/different applications) then you’ll have to look for that new stuff, but there’s nothing complicated here.

The real differences come in the records written by WebSphere itself.  We’ve discussed these in the previous weeks, so I won’t go into the details again here.  Essentially the 120-11 record should be used as a substitute for the 120-9 written by traditional.  It is a smaller record because it doesn’t need to report a lot of information about both the controller and servant regions.  The removal of the queue between controller and servant made some timestamps unnecessary.  But you should be able to find essentially similar information in both records, it is just simpler in Liberty because there are fewer parts to consider.  Of course the field names are all different so you’ll have to adjust however you process the records to find the same/similar data in new fields.

Unfortunately, the WOLA outbound 120-10 record doesn’t have an equivalent in Liberty.  And if you’re moving from Compute Grid Java batch in traditional (which just used the 120-9 async work record plus some user data) to Jakarta Batch in Liberty then you’ll move to the batch-specific 120-12.  Hopefully it provides all the information you need.

So, as you might have suspected, it all depends on in how much detail you were observing things.  If you stayed at a pretty high level, then you may have few to no concerns at all.  But if you were extracting detailed information about of the WebSphere records then you’ll have at least some adjusting to do, perhaps quite a bit depending on what you were monitoring.