Overview of Automation Logic

In SA z/OS, the automation function is split up, as follows:

  • The observing, reacting, and doing parts are located in the NetView address space and are known as the automation agents. The automation agents are responsible for:
    • Recovery processing
    • Message processing
    • Active monitoring: they propagate status changes to the automation manager
  • Within each sysplex, the coordination, decision making, and controlling functions are gathered into a single address space outside of NetView. This address space is called the automation manager.

You define the resources that you want to automate with SA z/OS using the customization dialog. The automation manager contains a model of all of the automated resources within the sysplex. The automation agents are the automation manager eyes and arms. They feed the automation manager with status information and perform the actions that the automation manager tells them to. The automation manager is the brain of automation. It does all of the decision making that involves interaction between one or more resources.

The automation manager provides sysplexwide automation. Its main purpose is to provide one central point of book-keeping of all resources within a sysplex, that is, the automation manager knows about the following:

  • Grouping of resources
  • Dependencies between resources
  • Statuses of resources
  • Goals for resources

The automation manager knows several different statuses for each resource:

  • The observed status
  • The desired status
  • The automation status
  • The startability status
  • The compound status
  • The health status

More detail about these statuses is provided in Statuses Supplied by the Automation Manager.

According to the available information, the automation manager makes decisions and instructs the corresponding automation agent where the resource is located to put the resource into the desired state that satisfies its goal.

The decisions are made by the automation manager with the help of goals. Goals can be defined either permanently by the automation administrator who creates an automation policy using the customization dialog (see IBM Z System Automation Defining Automation Policy), or interactively by operators who issue commands. In either case, the automation manager is informed about the goals of a certain application or resource and tries to reach the goal of a resource with its decisions.

Automation performed by SA z/OS is thus also called goal driven automation.

The automation manager transforms a goal (for example, the request that a certain resource or application should be up) into an order to the corresponding automation agent where the application should run.

The automation agents therefore execute orders that come from the automation manager. While carrying out the automation, the automation agents also take information from the policy that is defined for the resources. This information is available in the automation control file on each automation agent. For example, for an order to start a resource that comes from the automation manager, the automation agents retrieve information about the appropriate startup command from the automation control file.

For enterprise monitoring, the automation manager has the task of gathering and controlling information about what resources are available, what the status of the resources is, and what status updates occur during automation.

The main commands you can use to retrieve information from the automation manager are:
  • INGLIST displays detail information about one or more resources (subsystem, application group, and so on).
  • INGINFO displays lots of details for an individual resource or application group.
  • INGVOTE displays the requests that have been issued and are currently pending for a specified resource.
  • INGSCHED displays information about the current UP and DOWN service periods for resources.
  • INGGROUP displays the members of a group and their settings.
  • INGRELS displays the relationships that are defined for a resource.
SA z/OS supports two different types of goals:
Desired status goals
Those goals define whether a resource should be up or down. So the resource should either be available or unavailable.
Suspend goals
Those goals define whether a resource should be automated or not. So the resource should either be suspended or resumed.

Both types of goals also take into account the dependencies of resources as defined via relations in the customization dialog. Additionally, the desired status goals also check whether a trigger is defined for a resource that determines whether the availability of a resource depends upon some external events outside SA z/OS automation.

You can issue a request or goal to the automation manager with the INGREQ or INGSUSPD command, such as a goal that the specified resource should now be available, unavailable, suspended, or resumed.

Requests that are sent to the automation manager with the INGREQ or INGSUSPD command are persistent. That is, if the automation manager terminates and is restarted later, it then remembers all requests (goals) that were valid when it terminated. The automation manager will then continue to pursue all these goals for the resources. This means that if a resource should run on a certain system, and this system fails and is restarted later, the automation manager will continue to pursue the specified goals across IPL times unless they conflict with the IPL schedule times.