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’re having a problem and are working with support, at some point they are probably going to ask you to turn on some tracing. They’ll give you this cryptic trace specification that turns on whatever tracing they think they need to figure out what is going on. But what are you supposed to do with that string? You’ve got options..
The simplest thing to do is to update the server configuration (server.xml, for example) to include the logging element and specify the trace string. Ah, but when does that take effect? Well, it depends on whether the server is actively monitoring the configuration or not. If it is, then it just takes effect essentially as soon as you save the file (unless you’ve changed the monitoring interval from the default of every half-second). But you might have turned that off because all that monitoring uses CPU.
In that case, you could just recycle the server. But be careful with that. Depending on the tracing you’ve been asked to turn on, it might generate a whole mountain of output as part of startup processing and (unless you’re looking into a startup problem) you probably don’t need all of that. If that’s the case, then you could use the console Modify command that can trigger a scan of the server config to pick up changes (more on that in a later post).
That’s great, but you should also think about what will happen if the server restarts. Because the trace specification is part of the server configuration, if the problem you’re investigating can cause the server to crash and some automation restarts it, then you’ll get all that startup tracing again. That’s not necessarily bad, but just something to think about.
Well, if you don’t put the trace specification in the server config, how are you supposed to turn it on? Another method is to just use another console Modify command to dynamically enable the trace. This can get tricky if the string is long, but if I remember correctly SDSF will let you enter long commands if you just type a slash and hit enter. Also remember that trace specifications are usually lower case (or mostly lower case) and you’ll need to enclose it in single quotes to keep the console from upper-casing it on you.
As you gain experience with Liberty and (hopefully not) encounter some problems, you might build up a set of ‘common’ traces you’ve been asked to turn on. Again, I hope this doesn’t happen to you, but if it does you might consider setting up a set of ‘common’ trace specifications in .xml files that are ready to be included in your configuration as needed. You could even have server.xml include an empty trace-specification XML file that you replace by copying over it with the pre-set one you need. Then you can just copy an empty one back over the top of it when you want to turn it back off (triggering a config refresh if necessary).
Working out what your procedure will be to enable tracing when requested by support probably isn’t the top thing on your list of things to do getting ready to use Liberty on z/OS, but it should probably be on there somewhere. That way when support sends you a trace to turn on, you won’t have to have the ‘well how do we want to do this?’ discussion at 2 AM.