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.
---------------
All I ask is a stable server and some messages to automate her by…
Last week we talked about how you can cause messages that aren’t normally issued as WTOs to become WTOs and thus visible to automation. That might have left you wondering what messages already come out as WTOs that you should probably be watching for.
Before we get into that, I wanted to be just a bit more specific about what we mean by WTO messages vs. hardcopy messages since both are really issued via a WTO. A WTO or console message uses Route Code 2 and Descriptor Code 4. A hardcopy or syslog WTO is issued with Route Code 11 and sets MCSFLAG to HRDCPY.
When a server first gets started you’ll see CWWKE0001I, followed by CWWKZ0001I for each application in the server as it starts. To know when initialization is all complete you should look for CWWKF0011I.
What about shutdown of the server? If you stop the server via the console stop command, which is probably the case for a server running as a started task, you’ll get CWWKB0001I to acknowledge the command was received. You’ll also get an instance of CWWKZ0009I for each application as it stops. The last message you’re likely to see from the server itself (not counting JES messages like $HASP395) is CWWKB0251I.
Of course it is possible to get the messages about applications (CWWKZ0001I and CWWKZ0009I) if an application is stopped and restarted because of an update to the application. Similarly, you might make dynamic updates to the server configuration and that will result in CWWKG0016I and CWWKG0017I indicating the start and completion of the configuration update. Why would automation care about any of this? There might be other things you need to do that are tied to these actions. Maybe you’ve done something to route work away from the server while you update the application and you’ll need to know the update is complete before routing work back again.
What about the Angel? When the Angel starts it issues message CWWKB0079I, but that doesn’t help very much because it doesn’t tell you the name of the Angel that is starting (because it is issued so early we don’t know yet). But the Angel starts very fast and it is probably easiest just to watch for the initialization complete message (CWWKB0056I or CWWKB0069I depending on whether your Angel is unnamed (56) or named (69)).
When an Angel ends, it can end normally (due to a stop command) or abnormally (because of some error). There are different messages for normal vs abnormal ends and different flavors of those messages depending on whether the server is unnamed or named. An unnamed (default) Angel issues CWWKB0057I for a normal end and CWWKB0058E for an abnormal end. A named Angel issues CWWKB0073I and CWWKB0074E for those situations, respectively.
The named-Angel flavor of these messages all include the name of the Angel, which is, of course, pretty important to know.