Using start, stop, and abend validation events

You can define start, stop, and abend validation events for an object. Total Object Manager (TOM) determines that the object has started, stopped, or abnormally ended when any of these events occurs.

TOM automatically defines certain start, stop, and abend validation events depending on the object type, as described in this topic. If these are events are sufficient for your purposes, you don't need to define any events yourself.

If you define multiple start, stop, or abend validation events for an object, TOM determines that it has started, stopped, or abnormally ended when any of these validation events occur.

STM objects

For STM objects, TOM defines the issuing of a IEF403I message as a start validation event. z/OS issues this message when the system has begun to process a job. The IEF403I message is issued only if job name monitoring is enabled.

Important

To check whether z/OS job name monitoring is enabled, issue the DISPLAY OPDATA,MONITOR command and verify that the JOBNAMES value is ON.

To learn how TOM can monitor and enable job name monitoring, see the ENABLE_JOBMON= parameter in BBPARM member MAMINIxx.

TOM also defines an end-of-memory (EOM) event, which runs when the address space terminates. Therefore, you do not need to define the issuing of a stop validation event for a IEF404I message as a stop validation event.

If these events are sufficient for determining when an STM object starts and stops, you do not need to define start or stop validation events.

However, if the object requires additional processing after the IEF403I message is issued before TOM considers the object to be active, then you should define a start validation event. Similarly, if an action occurs before the EOM event and TOM should consider the object to be inactive because of that action (such as a message being issued), then you should define a stop validation event.

UPM objects

For UPM objects, TOM uses a UNIX Systems Services (USS) exit, which runs when a USS process starts, stops, or abends. When this exit runs, TOM performs an object evaluation to determine the true status of the object. Unless you have unique events that must occur to notify TOM that the object status has changed, you do not need to define start or stop validation events.

WRM objects

For WRM objects, TOM defines the issuing of the IWM039I message with the text IN THE ON STATE as a start validation event.

TOM also defines the issuing of a IWM039I message with the text IN THE OFF STATE as a stop validation event.

If these events are sufficient, you do not need to define start or stop validation events.

GSM objects

For GSM objects, TOM does not define any start or stop validation events. Depending on the type of resource being managed, you might need to define start and stop validation events. To detect the status of most GSM objects, you must define an Active Check Program. If that is sufficient, then you don't have to define a start or stop validation event. However, if the object has specific processes, such as messages issued, that are involved in status changes, you might need to define a start or stop validation event.

Abend validation event

In most cases, the events that TOM automatically defines are sufficient to detect whether the object has ended, including abnormally (an abend). However, if unique processes or messages indicate an object has abnormally ended but the address space has not yet ended, then you should define an abend validation event. Also, if you have special actions that you want TOM to take when the object abends, you must define an abend validation event and define one or more Recovery Commands to the object. TOM runs Recovery Commands only if one or more abend validation events are defined. For more information, see Command-Specifications-panel.