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.
---------------
This week we’ll look at the Liberty z/OS Modify command that allows you a peek at what is going on inside the server. This is a command we ‘copied’ from WebSphere traditional where users seemed to find it useful. The command is just “Display,Work” (after the Modify command syntax to direct it to the right server).
For the command to work, the server must have the requestTiming feature enabled. That’s because that feature enables code where the hooks are that let us count requests.
So what does it show you? Well, the first two counters tell you how many requests have been processed by this server since it started and how many are being processed in the server right now. That total-ever count might be a large number for a server that has been up for a long time and regularly does a lot. But if somebody asked you to create a server and you notice it has been up for 3 weeks and processed exactly two requests, you might want to ask a few questions.
The right-now count is also interesting because it gives you a snapshot of how heavily loaded the server is. Remember, of course, that if the server is running a lot of short transactions (like HTTP requests can be) the work count displayed for you is probably representing work that has already finished by the time you are reading the results.
The other two counts represent the number of requests that are in progress that have been deemed ‘slow’ or ‘hung’. This judgement is based on server configuration that defines what you mean by ‘slow’ or ‘hung’ based on time values specified for different work. If you’ve got those defined to values that really represent your expectations for the work (no small task) then these display values can give you a sense of whether your server might be getting in trouble or not. (I’m not going to talk about the slow/hung definitions because that’s common across all platforms and not a z/OS specific thing. The following link might provide more information, if you are interested and the link still works: https://www.ibm.com/docs/en/was-liberty/base?topic=liberty-slow-hung-request-detection)
One last cool thing about the display-work command. It also shows you ‘delta’ values. These are changes in the displayed values since the last time somebody issued the command. The idea was that automation might issue the command on some regular basis and try to process the results. As we thought about what such automation might do, we realized it would be helpful to have in-hand what the values were last time so you could easily determine if it had changed.
For example, if you look at the total work value every 5 minutes, you might expect it to change by some minimal value indicating the server is doing something. If it doesn’t change, or changes very little, perhaps something is wrong somewhere. Rather than have automation remember the value from the previous display command and do math, the output of the command will show you the difference from the prior value. Automation can just compare that value to whatever threshold is appropriate for you and take action if necessary.
Be careful though. If some operator comes along and just issues the command, that sets new ‘previous’ values and can lower the calculated ‘delta’ next time automation issues it.