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.
---------------
As mentioned in an earlier post, there are several different kinds of dumps and what sort you need will depend on the problem you’re having and which support group is helping you. At an operating-system level there are SVCDUMPs, at the JVM level there are javacore and heap dumps, and at the server level there is the ‘server dump’ results.
On z/OS you generally get an SVCDUMP when something abends and somebody’s recovery gets control and decides to capture a dump. That doesn’t happen a lot with Liberty because there simply isn’t a lot of native code (non-Java) that can do that sort of thing. It isn’t impossible, but it isn’t common. Of course, you can have code in Liberty calling some other thing that can abend and dump (DB2, for example).
Still, there can be cases (native storage leaks for example) where it is handy to have a traditional z/OS dump of the whole address space (or maybe Liberty and some other address spaces all together, depending on the problem). For those situations you can either use the console DUMP command to capture whatever you need, or, if you just need the Liberty address space, you can use the console Modify command against the server to request an SVCDUMP (note that this is an authorized operation and requires Angel support – more on that in a later post too).
But since so much of the server (and probably application) code is in Java, the classic Java dumps (javacore, heapdump) are probably more useful. Heapdumps can get pretty big running in 64 bit, so plan your disk space accordingly. There are a few different ways to trigger these. The MVS console Modify for Liberty command might be the most comfortable to z/OS operations.
The server itself can also capture its own information. On non-z/OS platforms this is done using the ‘server dump’ command. On z/OS this will work also. It will capture logs and FFDCs and server configuration stuff. If you’ve allowed the server command port to remain open it can also trigger processing within the server to capture internal information about what is going on.
For various reasons some shops will choose to prevent the command port from opening, but you can still collect this information with the DUMP option on the Liberty Modify command.
So once again we’ve got a few different things you can do and different places where things go. And here again you should probably experiment with this stuff before it becomes really important. As part of standing up your first Liberty server in a production environment you might want to try out collecting the various dumps and make sure everything works the way you expect and you know where the output ends up. A nice written procedure might save you waking up to a phone call with an urgent question. The last thing you want to do when you’re debugging a production problem is side-step to figure out a separate problem with doc collection. And yes, I know you know that, but there are a lot of things I know I should do that never quite get done (when DID I last clean out my gutters?).