z/OS and Job Processing
The z/OS Agent handles the communication between an AE system and a z/OS system. Among many other things, you can use it to handle and improve the processing of Jobs.
This page includes the following:
z/OS Jobs
In the AE, Jobs are defined and maintained in the form of objects that include various pages. Use Automation Engine scripting language to include complex logic on the Process page of the Job.
More Information:
You can include commands in the Job Control Language (JCL) of your z/OS target system on the Process page of the Job. For more information, see Job Control Language Script Reference.
In your AE system, you can start Jobs either manually or via control mechanisms such as Workflow objects or Schedule objects. Regardless of how you start the Job, the AE generates an executable Job and sends it to the Agent for z/OS with a file transfer. For more information, see Executing and Restarting Objects and Tasks
When the file transfer is complete, the z/OS target system reads the Job and puts it to the internal reader facility. The internal reader starts the Job, monitoring takes place through the Event Monitor's SMF Exit. When the Job starts or ends, it notifies the Agent, and the Agent passes this information on to the AE system.
The Agent monitors the Job status at regular intervals. This ensures that an abnormal end such as ABEND or CANCEL will be detected. The corresponding return code is provided in the AE. See Return Codes of z/OS Jobs
The Job report (MSGCLASS) which includes the JES statistics and the complete Job output, can be stored to a dataset on the target system (Agent) and/or to the AE database. If you define that the Job report should be stored in the database, the Agent transfers the report to the AE which stores it in the AE database. See also: Job Reports
Best Practices to Improve Job Handling
Duplicate Job Name Check
Scenario:
To save JES resource consumption, you may want to avoid that multiple z/OS Jobs start in the AE that have the same z/OS Job name. These Jobs would be queued in z/OS although they start in the AE.
What you can do:
In the Agent z/OS INI file, set the DuplicateJobCheck parameter to YES.
As a result, the Agent for z/OS starts only one Job of the same name at a time. Jobs that do not yet start are shown with the status Waiting for remote resource.
Adjust the Number of Jobs (Available WLM Initiators)
Scenario:
You may want to make sure that the z/OS Agent does not start additional Jobs if all z/OS initiators are busy.
The workload management (WLM) capability in z/OS can adjust the number of available initiators. For this purpose, the Agent needs to check the number of available initiators to determine the maximum number of jobs that are allowed to start at a certain point in time.
What you can do:
Use the InitiatorCheck parameter in the Agent z/OS INI file. For more information on how to use this parameter, see the [WLM] section.
Check Availability of Scheduling Environment
Scenario:
You do not want that a Job is submitted to the JES (z/OS) if the scheduling environment that is defined for this Job is not available on any of the suitable systems.
What you can do:
Set the SCHENVCheck parameter in the Agent z/OS INI file to YES. For more information on how to use this parameter, see the [WLM] section
See also: