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.
---------------
I know it is hard to imagine, but try to pretend for a moment that you’ve had some sort of problem with your Liberty z/OS server and opened a case with IBM support. After examining the logs and other ‘must gather’ information you’ve sent in, support indicates they are going to need you to turn on some tracing to help diagnose whatever is happening that apparently shouldn’t be happening. How do you do that?
Well, the usual Liberty way would be to update the server configuration. Liberty, by defaulting monitoring for changes to its configuration, will notice within half a second and change to start capturing whatever trace you’ve enabled. Except that on z/OS you’ve decided to disable active configuration monitoring to save background CPU usage.
You could update the configuration and then use the modify command we discussed earlier to force a rescan of the configuration, or just restart the server. The problem with either of these is that now you’ve got this trace enabled as part of the server configuration. Somebody will have to remember to go remove that or you’ll have it forever. There is also, quite possibly, some serious red tape involved in getting a change made to the server configuration. Wouldn’t it be nice to just be able to change the trace specification for this instance of the server and not harden that anywhere? Then the next recycle would remove the tracing because it isn’t part of the actual configuration.
Fortunately, there’s a z/OS console modify command that allows you to do exactly that. Just direct a modify command at the server whose trace specification you want to change and add on LOGGING= and whatever trace specification support told you enable. You want single quotes around that because the console tends to upper case everything and it is very unlikely your trace specification string is all upper case.
That’s all there is to it. The change is made to the running server, but not hardened anywhere so the next recycle of the server will put you back at whatever tracing is specified in the server configuration. Hopefully you got what support wanted before that happened, of course.
How can you tell if your server is running with the configured tracing or if somebody has modified it dynamically? Well, you can go look in the server’s log and find the messages where it processed the modify command. The most recent one is the trace specification the server is using right now (because, of course, you can issue the command more than once and change the trace specification multiple times in the life of a server instance).
But a display command to show you the current tracing might be handy. A requirement got opened asking for exactly that (TWAS-I-117). I write these posts somewhat in advance of when they go up, so it is possible by the time this gets posted (or by the time you read this) we might have already delivered it. But if not, and you’re interested, you might find it (here: https://cloud-platform.ideas.aha.io/ideas) and vote for it.
And yes, it is a Liberty requirement even though the identifier starts with ‘TWAS’ which is sort of the internal IBM nickname for WebSphere traditional. Some requirements past a certain age are prefixed TWAS even though they are Liberty requirements. Long story.