Previous Topic: Example of Action SelectionNext Topic: The PROCESS Action Clause


Process Events

The process event facility lets users influence resource processing when state transitions occur. This facility lets users enhance the decision-making process in the SSM engine. For example, a process event can execute a user-supplied action that determines whether a prerequisite resource is available on a remote system. There are eight events at critical points in SSM where an event can occur.

The PROCESS action clause gives users control over process action invocation on a per event and per resource basis. The PROCESS action command is discussed in the next section.

The following list shows the process events and their descriptions. SSM!PROCESS sets to the event name when the action gets control.

MATCH

Occurs once when the current state equals the desired state for the first time. Typically, a MATCH action can be used to start a dependent resource. In this case, dependent refers to a resource that lists the current resource as a subrequisite. For example, if the desired state of VTAM is UP, then the MATCH exit might start CICS.

SELECT

Occurs for each resource every time the SSM engine finds a reason to process the state of a resource. SELECT occurs if the current state does not match the desired state, if the missing prerequisite column or previous state column is not null, or when the ACTMODE column has changed for the resource. A SELECT action should be used to issue a PROCESS command that enables or disables subsequent process events as needed to implement your automation strategy.

MPREREQ

Occurs once if any missing prerequisites remain after usual prerequisite processing. This event allows a user-supplied action to apply its own criteria to the missing prerequisites. The event action must be a synchronous action (EVRULE or RULE) that updates the MISSING_PREREQ column to remove a prerequisite that is UP or possibly adds a prerequisite that is DOWN.

Notes:

XPREREQ

Occurs once for every prerequisite name that includes a system name such as SYST01.OPSW.TABLE.NAME. If the action determines that a prerequisite is missing, then the action must return to SSM with a non-zero return code. This action causes SSM to add the prerequisite to the missing prerequisite list.

Note: The action for this event should be a synchronous action (EVRULE or RULE) so the user code can return a non-zero return code if the prerequisite is missing. If you execute an asynchronous action such as REXX, then the return code passed back to SSM is zero and the prerequisite is not added to the missing prerequisite list, even if your asynchronous REXX code determines that the prerequisite is missing.

MSUBREQ

Occurs once for any number of missing subrequisites if any missing subrequisites are found by SSM standard processing. An MSUBREQ action must be an asynchronous action (EVRULE or RULE) that can use its own logic to determine subrequisite status and may override the SSM subrequisite decision by updating the MISSING_PREREQ column.

Note: XUSBREQ events execute before the MSUBREQ event.

XSUBREQ

Occurs once for the resource being evaluated after SSM processing, even if multiple subrequisites are missing. Action code must be a synchronous action (EVRULE or RULE) that must discover subrequisite dependence on other systems, and update the MISSING_PREREQ column for the current resource if any missing subrequisite is found, or if a missing subrequisite is satisfied.