How TOM starts and stops objects


TOM uses object evaluation to determine when to start or stop an object. The object evaluation process is triggered when an object's status changes or the object definition changes.

For each object, the evaluation process inspects:

  • If any defined calendar or schedule criteria has been met for the object
  • If any defined object dependencies has been met for the object

To determine an object’s state in the system, TOM monitors the Started Task, USS processes, or WLM resources that the object represents by using events. The object evaluation process also has access to the all of the properties that are defined for the object (its schedule, dependencies, and so on). When the evaluation process determines that the status of an object needs to be changed, TOM takes the appropriate action to reconcile the actual state with the object's desired state.

For example, when an object is not active but is supposed to be active, TOM issues the object START command (or EXEC) that is defined with this object.

The evaluation process passes the start request to the initiation controller, which starts a task to process this request. Each task acts on behalf of a specific object. The initiation controller can start as many tasks as the evaluation process determines is needed to handle the work that needs to be done. These tasks run simultaneously in the TOM PAS.

When a task begins, it determines whether a Start verification message was specified as part of the object definition. If the Start verification message is specified, the task waits until you reply YES to the outstanding write-to-operator-with-response (WTOR) message. Activity for other objects is not impacted during this time.

After you respond to the Start verification message, TOM compares the object’s START command count value on the target system to the maximum value allowed. If the limit has not been exceeded, processing continues.

TOM checks the object definition for any pre-start commands (or pre-stop commands). You can specify many commands as part of an object’s startup or shutdown process.

Because certain objects might need to start in different conditions, you can also specify that a pre-start (or pre-stop) commands has a calendar dependency, where the command is only scheduled when the time requirements in the calendar dependency are met (see Entering-calendar-dependencies). When a schedule that is associated with an command indicates that the command should not be scheduled, TOM evaluates the next command (if applicable).

When an commands does not have a schedule defined for it (or the schedule indicates that it is time to process the command), the task waits for each (command as it is scheduled and processed by the MainView AutoOPERATOR PAS. TOM checks the return codes from the commands. A return code of zero means that TOM can schedule the next pre-start (or pre-stop) command. When all return codes are zero (indicating that the command has completed successfully), TOM schedules the next command and continues until all commands are complete.

Note

If an command returns a nonzero return code, the object is not started (or stopped), and TOM sets the object’s status to FAILURE-PRESTART (or FAILURE-PRESTOP).

At this point, TOM prepares to intercept the start, stop, and abnormal termination events (messages) that are defined for the object. In the case of Started Task objects, USS processes, or WLM resources TOM passes event information to the associated MainView AutoOPERATOR PAS, and MainView AutoOPERATOR Rules are dynamically defined in the MainView AutoOPERATOR Rules Processor.

Each Rule can have a message ID, message text, job or Started Task name, and a step name defined, so when the message for an object is detected by the Rule, TOM knows that the start, stop or abend message has been issued for a particular object.

By default, each STM object has an initiation event and an end-of-memory event. The initiation event is the message event that occurs when TOM processing detects the text-id of the IEF403I message. The default stop validation event is an end-of-memory (EOM) Rule that fires when an EOM event occurs for this address space.

If you planned to define an STM object to start with the IEF403I message and stop with the IEF404I message, you do not have to specify these events in the object's definition because of TOM's default processing of STM objects.

Note

The MainView AutoOPERATOR Rules working inside TOM processing cannot be seen from the MainView AutoOPERATOR Automation Control panel and cannot be disabled. These Rules do not affect the performance of the Rules Processor in MainView AutoOPERATOR.

After this, TOM issues the object’s START (or STOP) command and if you use variables in the object’s START or STOP command, the variables are resolved now. After issuing the command, the task waits for the amount of time that is specified in the timeout value. When the object starts (or stops) and it generates an event that matches the one defined, the Rules Processor notifies TOM. When TOM receives the notification, it interrupts the waiting task and cancels the wait. The object is placed in an ACTIVE status (or STOPPED/LOCKED/BLOCKED status when TOM stops an object).

If TOM does not receive notification that the object has completed initialization (or termination) before the timeout value is exceeded, the wait period ends and TOM issues any retry commands that are part of the object’s definition. If the notification still does not occur after TOM issues all the commands, TOM places the object in a FAILURE-REC-INIT (or a FAILURE-REC-TERM) status.

START, STOP, and ABEND validation events can be defined to use messages that originate from the USS syslogd daemon. See Routing-USS-program-messages-to-the-MVS-console for an example of routing messages to the MVS Console.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*