Submitting jobs

This is how HCL Workload Automation for Z submits operations on computer workstations:
  • The current plan is locked to prevent other tasks or users from updating the operations.
  • The best candidate for submission is chosen as described in Identifying the order of submission.
  • If the operation has been marked with a NOP, HCL Workload Automation for Z immediately sets the operation to complete.
  • HCL Workload Automation for Z attempts to find the job in the JS file. The job is found here only if a dialog user has updated the job statements, or if this operation occurrence has been previously submitted.
    Note: To prevent the JS file from becoming full, HCL Workload Automation for Z maintains the JCL records on the JS data set until the next occurrence of the same application is set to Complete. For details, see the Diagnosis Guide and Reference.
  • If the job is not found on the JS file, HCL Workload Automation for Z attempts to find it (the member name must be the operation name) in the EQQJBLIB partitioned data set concatenation, first calling the EQQUX002 exit if it is loaded.
  • If no job can be found, the operation is given an extended status E to indicate the error, and a message is written to the HCL Workload Automation for Z message log.
  • If the job is found, either in the JS file or in EQQJBLIB or returned by the EQQUX002 exit, variable substitution is performed, if required, and the job submit user exit (EQQUX001) is called.
  • A copy of the job is written to the JS file. The job and workstation destination are queued to the data router. The operation status is set to S and extended status U is assigned to indicate that submission is in progress.
  • If there are more operations eligible to start, HCL Workload Automation for Z will move on to the next best candidate. Up to 5 operations can be started.
  • The current plan lock is released.
  • The destination is resolved. It can be a submit/release data set, an XCF link, an NCF link, a TCP/IP link, or blank. If the destination is blank, the job is directed to the system the controller is started on.
  • (z/OS® only.) When the JCL arrives at the destination, the job is submitted to JES via the EQQBRDS ddname. The EQQBRDS ddname is used to allocate a JES internal reader.
  • The extended status of the operation is set to blank.
  • (z/OS® only.) When HCL Workload Automation for Z learns from JES that the job has been successfully loaded onto the internal reader, the extended status is set to Q.
  • Once the job actually starts to execute, the extended status is set to S. For z/OS® jobs, this happens when the initiator is available.
  • If a job is routed to another NJE node for execution and in this process the related JES reader time changes by more than one minute, the job is not tracked correctly. In fact, if a job has a ROUTE EXEC statement to a specific NJE node, it is sent to the JES PLEX and can be run on any member of the JES MAS complex. To allow HCL Workload Automation for Z to track the job, define a tracker on every member of the JES multi-access spool complex at the destination NJE node. Instead of using ROUTE EXEC, define a CPU workstation whose destination is one of the trackers on the destination NJE node, and schedule the work on that workstation. In this way, HCL Workload Automation for Z, not NJE, sends the job directly to the node where it is to be run. The results is that the job goes through JES input/conversion processing only once, and the JES reader timestamp does not change.

If the JTOPTS keyword QUEUELEN is specified, HCL Workload Automation for Z starts up to the number of operations defined by QUEUELEN. For information about the QUEUELEN parameter, see the JTOPTS statement.