Submitting jobs
All agent for z/OS jobs
can be either part of a job stream and be submitted in a plan, or
be submitted at any time using the conman submit commands
or proper Dynamic Workload Console panels.
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.
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.
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.