Submitting jobs

Submit agent for z/OS jobs just as you submit all other HCL Workload Automation jobs.

When you submit a job of type JCL through a production plan, or more specifically from a conman command line or the Submit windows of the Dynamic Workload Console, the job is processed by dynamic workload broker and dispatched to the agent for z/OS specified in the job definition.

The agent receives the job submission requests. The job submission requests include either the body of the JCL to be passed on to JESn for execution, or a reference to a member of a partitioned data set that includes the JCL. If the reference names only the member, but not the data set, the agent will search the member name in the data set concatenation library declared for the agent at installation time (which defaults to EELJBLIB).

If variable substitution is requested in the JCL, the variable tables that include the variables featured in the JCL (and the respective values) are sent with the submission request to the agent.

Upon receiving a job submission request, the HT task briefly stores the job in the HTREF service database, that is part of the agent for z/OS. When the request involves a JCL by reference or variable substitution, the referenced JCL is fetched or the variables are resolved inside of HTREF. A failover mechanism on the agent keeps track of the jobs that are not processed if for some reason the agent should become unlinked or fail, and picks up the submission thread as soon as the communication between HCL Workload Automation and the agent has restarted. See Understanding resynchronization messages for details on this process.

Figure 1 tracks the route followed by a job as it arrives to the agent for z/OS and is passed on to JES for processing.

Figure 1. The route followed by a job within the agent for z/OS.

When the JCL arrives at the submit task, the job is submitted to JES via the EELBRDS data set. The EELBRDS data set is used to allocate a JES internal reader.

Note that the JCLs coming from HCL Workload Automation are stored on disk (HTDS). This guarantees that, if the agent is interrupted, the jobs are not lost, but sent to JES when the agent resumes.

After the JCL is added to the EELBRDS data set, the event data set (EVDS) is updated with the new job state and an update is also sent to dynamic workload broker through the z/OS® subsystem interface (SSI).

After a job is processed, its status is sent back to HCL Workload Automation as an event.

Figure 2 tracks the route followed by the events related to the statuses of submitted jobs as they are returned by JES, processed by the agent for z/OS, and sent back to HCL Workload Automation.

Figure 2. The route followed by a status event within the agent for z/OS as it is returned by JES on its way to HCL Workload Automation.

The agent uses the normal tracking mechanism based on SMF and JES exits to track the status of all the jobs in the system and to send them back to the dynamic workload broker.

Note that the events are stored in the event writer queue in CSA and also in the event data set (EVDS) on disk. This guarantees that, if the agent is interrupted, they are not lost, but sent to HCL Workload Automation when the agent resumes.

Back in HCL Workload Automation, the events filter component of dynamic workload broker receives all the events coming from the agent for z/OS and matches them against a job table. If there is a match, the event is processed, otherwise it is discarded.

The Output manager handles job log requests from HCL Workload Automation by getting the job output from the JES spool (if still available).

When a job submission request is received by an agent for z/OS in a sysplex environment, the agent executes the job, but the job can be routed by JES to any other node of the sysplex where another agent tracks it and sends the event back to HCL Workload Automation that checks if the event is related to one of the jobs submitted and if this is the case updates its status.

The use of NJE (Network Job Entry) with the agent for z/OS is not supported because it can result in faulty tracking of a job state.