Goal Driven Automation
SA z/OS implements goal driven automation in four flavors:
| Flavor | Fit for what goal? |
| Operator requests, which can only be used during runtime: Operators can define goals for resources with INGREQ or INGSUSPD command. The goals should be active immediately after the command is issued. |
|
| Events, triggers (see Event and Trigger Support), and service periods (see Automatic Calculation of Schedules (Service Periods)): This allows you to define desired status goals for resources (applications, application groups, or monitor resources), and to specify external events that need to be satisfied before the resources can be actually started or stopped. |
|
| Automation administrators define the default behavior or desired state of resources using the customization dialog: SA z/OS tries to keep the resource in the specified state during specified schedules under specified prerequisites. |
|
| Automation administrators can predefine suspend requests (see Using the Suspend File) in a suspend file, that is processed during automation manager COLD and WARM start and configuration refresh: In this way, it is possible to suspend resources right from the beginning of the manager initialization which might be useful e.g. if administrators want to define resources in the customization dialog, but those resource can not be used productively yet. |
|
If operators want to change the goal of a resource, they may issue or remove a request to start, stop or suspend it using the INGREQ, INGSET and INGSUSPD commands with appropriate parameters. A request is executed by SA z/OS only if it does not conflict with requests of higher priority. Otherwise, because requests are persistent, they only take effect when conflicting requests of higher priority are resolved. Operators must remove obsolete requests from SA z/OS.
Note: INGREQ and INGSUSPD requests are persistent. They are remembered across session
boundaries until they are explicitly revoked.