Scheduled execution of a JCL job
The administrative task scheduler sends the JCL job to the JES reader. The execution sub-thread of the administrative task scheduler can optionally wait for the job to terminate and purge the job from the JES job list.
One execution sub-thread of the administrative task scheduler is used to execute a task that locates a data set containing a JCL job. The sub-thread reads the JCL job from the data set where it is stored, identified by the task parameters JCL-library and JCL-member. The data set can be sequential or partitioned. For a sequential data set, JCL-member is NULL.
- NO
- Specifies asynchronous execution. The sub-thread does not wait until the job completes execution and returns immediately after the job submission. The task execution status is set to the submission status, the result of the job execution itself is unavailable.
- YES
- Specifies synchronous execution. The sub-thread simulates a synchronous execution of the JCL job. It waits until the job execution completes, gets the job status from the JES reader, and fills in the last execution status of the task.
- PURGE
- Specifies that the job status in z/OS is purged. The sub-thread purges the job output from the JES reader after execution. Execution is the same as when job-wait is YES.
JCL job execution status always contains a null value in the SQLCODE, SQLSTATE, SQLERRMC, and SQLERRP fields. If the job can be submitted successfully to the JES reader, the field JOB_ID contains the ID of the job in the JES reader. If the job is executed asynchronously, the MAXRC, COMPLETION_TYPE, SYSTEM_ABENDCD and USER_ABENDCD fields will also be null values, because the sub-thread does not wait for job completion before writing the status. If the job was executed synchronously, those fields contain the values returned by the JES reader.