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.
---------------
It is when you start to look at available diagnostics that the multiple nature of Liberty on z/OS really becomes apparent. Liberty is, at once, a z/OS server, a Java application, and a server that can be run on non-z/OS platforms. Each of these natures yields different diagnostic flavors.
As a z/OS server you would expect to have WTOs written to the job log or to the system log. You would expect to get SVCDumps taken when problems occur. You would expect to be able to enable tracing (ah, but where does it go?). You might even hope for some SMF records that provide details about what is going on in the server. And looking at Liberty on z/OS you’ll find all these things.
As a Java application you would expect capabilities like -Xtrace to work. You would expect the Java Health Center to be able to be used. You would expect to get javacore and heapdumps that can be analyzed in a normal fashion. You would expect to get verbose GC tracing that standard GC analysis tools can process. And looking at Liberty on z/OS you’ll find all these things too.
Finally, as a server that can, stripped of its z/OS extensions, run just fine on a multitude of other platforms, you would expect it to have logs and traces and maybe some way to dump what it is up to in some platform neutral way. And looking at Liberty on z/OS you’ll find all these things too.
In its platform neutral aspect it writes a console.log and a messages.log file. These files can wrap to new files when they get too big (configurable), and a new file is started with a fresh start of the server. In a bit of z/OS integration the messages in these files can become WTOs or end up in a DD accessible with the job output (well, if you configure it to SYSOUT=*).
The console.log and messages.log files will end up where the server output goes (a separate topic for next time). Traces will end up in the same place.
On non-z/OS platforms the server is (mostly) always started using the ‘server’ script and can be stopped the same way. As we’ve discussed previously, you might want to let developers start their servers that way, but production servers are probably started tasks. Eventually we’ll get to z/OS console Modify commands and dump options within that. But for other platforms there is a ‘dump’ operation you can perform on the server using the server script. And, of course, that same operation will work with a server on z/OS started as a started task. This dump will collect up information about the server (config, logs, traces) but can also reach into the running server itself to extract information about what is going on inside it.
As you interact with different groups within your company, as well as different support groups within IBM, try to bear in mind that different people view a Liberty on z/OS server as different things and will think about it in different ways, which will affect the sorts of diagnostics they expect to solve a problem.