Event and Trigger Support

This section describes the concepts of events and triggers and how you can use them.

This is useful for understanding how to define automation policies for events and triggers using the customization dialog, see Events Entry Type and Service Periods Entry Type in IBM Z® System Automation Defining Automation Policy for more details.

These entry types allow you to specify external conditions when certain applications on certain systems should either be automatically started or stopped.

Events are used to represent processes outside of automation. You can use the INGEVENT command to let SA z/OS know that an event has occurred. One or more events are part of a trigger condition. You can define a condition to be either a startup condition or a shutdown condition.

Events are used to decide whether the desired status goal for a resource should be realized. Even if all dependency relationships and conditions are fulfilled, but a resource's startup condition is not fulfilled, because not all events of the startup condition are set, the resource will not be started.

An event can be in one of two states: set or unset. The state of an event is changed with an INGEVENT command. For more information, see INGEVENT in IBM Z System Automation Operator's Commands. The state of an event is set by the user (or a procedure) and memorized throughout the sysplex. Each time, an event is set, SA z/OS checks all triggers defined in your environment or in your sysplex to find out whether applications need to be started or shut down according to the new conditions.

Triggers can be connected to applications or application groups. They act as inhibitors for the requested action. For an application to be started, its desired status must be AVAILABLE and its startup trigger must be satisfied. For an application to be stopped, its desired status must be UNAVAILABLE and its shutdown trigger must be satisfied.

If a trigger is connected to an application group then, if the trigger startup condition for the application group is not satisfied, none of its members can be started. Also, if the trigger shutdown condition is not satisfied, none of the group members can be stopped. So the trigger is kind of inherited to the members of the application group. This is also valid if the group contains nested groups. Then the trigger is also inherited to the members of the nested group.

In Figure 1 the application connected to Trigger T1 would be started if either EVENT1 and EVENT2 are set or if EVENT3 is set, assuming the desired goal of the application is: available. The application would be stopped, if EVENT4 is set and the desired goal of the application is: unavailable.

Triggers are used to control the starting and stopping of applications in a single system or a sysplex. So the trigger must be linked to one or more applications and has a list of conditions attached to it.

A trigger's condition list consists of up to 10 startup conditions and up to 10 shutdown conditions, each having up to 20 events. Each condition is either a startup or a shutdown condition. All events within a condition must have the status SET to meet the condition. If more than one condition of the same type, STARTUP or SHUTDOWN, is specified, only one of that type has to be met to satisfy the trigger.

Triggers and Traffic Lights

Like a traffic light, a trigger controls whether a running application should stop, or an application with the goal MAKEAVAILABLE should really drive away from a traffic light that switched to green, just like a ready-to start resource may only run if the trigger's startup conditions are satisfied. You see that the goal, or the request to start a resource must be there in order that a trigger with fulfilled startup conditions has an effect, just as a green traffic light is of no importance if there are no cars around the street.

However, a trigger with fulfilled shutdown conditions does not work like a red traffic light. Instead, a shutdown trigger (the red traffic light) stops the application only if the application's goal is MAKEUNAVAILABLE (while a red traffic light stops a running car anyhow). And an application with goal MAKEUNAVAILABLE is only stopped if a connected shutdown trigger is set.

Figure 2 shows another scenario of how triggers, events and conditions work together. For example, if EVENT1 and EVENT2 are set, Startup Condition 1 is true and Trigger T1 starts the application, provided that the application's goal is being available. If EVENT4 is set, Shutdown Condition 1 is true and Trigger T1 stops the application, provided that the application's goal is being unavailable.

A startup condition is satisfied when all events of the condition are set. A shutdown condition is satisfied when all its events are set.

Where no real dependency exists between the applications it is more appropriate to use events and triggers to control the STARTUP and SHUTDOWN.