Automation Server overview

The Automation Server provides the ability to select data sets if you have data set names that are variable, such as those created by the Usage Monitor, which have low-level qualifiers containing time stamps.

The Automation Server runs as a started task in its own address space.

The user ID for the Automation Server must have an OMVS segment and a UID, or there must be a default UID configured.

The Automation Server issues a system-wide ENQ to ensure that there is only one instance of it in a z/OS® image. A single instance of the Automation Server continuously references all data sets, catalogs, and volumes that are accessible from all systems in a sysplex so it is unnecessary for the Automation Server to run on more than one system.

Usually a single instance of the Automation Server is sufficient to handle the work from multiple systems which share the same DASD. JOB actions can have any necessary system affinities coded in their JCL.

Input control statements define the processing to be performed by the Automation Server. There are two types of control statements, action statements and DSN statements:

action: Action statements name the template member which forms the basic input for the action to be performed when a relevant data set is newly discovered by a catalog search. They have optional operands to specify time-of-day, day-of-week, day-of-month, and month-of-year restrictions.
DSN: DSN statements provide a data set name mask to be associated with the preceding action statement. There can be many DSN statements after each action statement.

There are currently two types of action statement:

FTP

Starts the FTP utility to perform a file transfer.

For the FTP action, the template member is read and, after symbol substitution processing, is written to the file defined by the INPUT DD statement. The INPUT file is allocated to a temporary data set. The FTP program is attached as a subtask and scans the INPUT file to process the FTP requests. The report messages it generates are written to the OUTPUT file.

Upon completion of the FTP subtask, the Automation Server examines the completion code. If the program ends normally with a zero return code, the Automation Server deems the action to have been successful and updates the action status in the HZAACDS file so the action is not repeated for this data set.

If the FTP program abends, the Automation Server deems the action to have failed. A failed transfer is tried again at a later time. A retry is subject to specified scheduling constraints. The OUTPUT FTP report file contains information to track the exact cause of a transfer failure.

JOB

Submits a batch job.

For the JOB action, the template member is read and, after symbol substitution processing, is written to the file defined by the INTRDR DD statement. This file is directed to the internal reader used by the system, and the jobs submitted by the Automation Server become available for JCL conversion as soon as the INTRDR file is closed, or another JOB card image is found by the reader.

The Automation Server deems all JOB submissions successful, so there are no retries. Any failure should be investigated using the appropriate procedures used by your installation.

Note: The job stream in a JOB action template member may define more than one job.

The Automation Server does not check template member records for either FTP or JCL validity.

Before initiating an action for a detected data set, the Automation Server attempts to exclusively allocate the data set. If the data set is in use, the action is not performed and the awaiting retry status is stored in the control data set. The action is performed when the data set is next found to be available for use within any specified scheduling restrictions. Dynamic allocation failures due to other reasons do not inhibit the action.