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’re going to look at some Liberty configuration to control how messages are handled that is unique to z/OS. Last week we talked about the MSGLOG DD, but now we’ll move on to WTOs.
First of all, remember that on z/OS you can start a Liberty server either from the USS shell or as a started task with a console Start command. We kind of assumed that if you started the server as a started task, you might want to have some automation that sees the server start and maybe restarts it if it ends. So those sorts of messages are written as WTOs for automation to see. But if you start if from the shell, that’s probably (not necessarily though) just somebody hand-starting a server to do some development or testing or whatever. You probably don’t want to confuse your automation with messages from these servers.
And so, if we were started from the shell, the server won’t issue WTOs, but if we’re started as a started task, we will. If that’s not what you want, you can use the zosLogging enableLogToMVS Boolean attribute to tell us otherwise. I don’t remember why we included ‘MVS’ in the name. z/OS hasn’t been called MVS since, well, long enough ago to make me feel pretty old (“I was there. I was there 3000 years ago…” – google it)
While we are talking about odd naming choices, we have two more sets of configuration attributes to discuss. They deal with ‘hardcopy’ and ‘WTO’ messages. By a ‘hardcopy’ message we mean messages that are written to SYSLOG and generally don’t show up on any actual consoles. The use of ‘WTO’ to mean messages that go to a console (or ‘glass’ as some of us call it) is really incorrect. Anything that went to SYSLOG is a WTO and not all WTOs make it to the console. But there it is. For our purposes here a ‘WTO’ is a message that goes to the console and a hardcopy message is one that ends up in SYSLOG.
Ok, so we’ve got two attributes: disableHardcopyMessages and disableWtoMessages. These two will prevent any messages written by Liberty itself from going to SYSOUT or to a console. Perhaps you’re trying to keep servers you don’t care about much from cluttering up the logs/console and maybe confusing your automation. I don’t know.
The other two attributes of interest are hardCopyMessage and wtoMessage. These attributes allow you to list message IDs of messages you would like to go SYSOUT or a console that normally don’t. Perhaps there is some message that ends up in the message log that you’d like to have automation react to. This is how you get the message to someplace automation can see.
By the way, you can specify a list of messages to re-route separated by commas. Do not put a space after the comma. At least as I’m writing this, the space becomes part of the message ID that follows it and so it won’t match the actual message ID you’re trying to reroute.