if-statementjcl

JCL SETTING PARM VALUE WITHIN AN IF

I have a parm defined at the top of the proc. 'CONDSET'. Depending on the outcome of the step ARSSS030, I want to alter the parm. I attempted the following. But the end result is that CONDSET is always set to '103'. I guess you can't do a parm set within an if??? I even added an iefbr14 following each set statement, so that I could verify the executed steps in the jes msg log. For my testing ARSSS030 RC is 4, but the parm is always set to the last if. In this case '103'. If I comment out the last if/set, then the parm is set to '102'. The OS just uses the 'last' set statement.

//  IF ARSSS030.RC = 4 THEN
//      SET CONDSET=101
// ENDIF
//*
// IF ARSSS030.RC = 8 THEN
//     SET CONDSET= 102
// ENDIF
//*
// IF ARSSS030.RC = 12 THEN
//     SET CONDSET= 103
// ENDIF

I was hoping that the jcl/if statement would control the parm.

Solution

  • Short answer

    No, you can't. SET statements are processed before the job is started in the JES Conversion Phase (see below).

    Detailed answer

    A job on z/OS is processed in six phases:

    Input Phase

    This is when the job's JCL is handed over to the Job Entry Subsystem (JES), i.e. when the job is submitted. (Note, there are two different packages: JES2, and JES3. The differences are minor today, and don't matter for this discussion.)

    The JCL is written to the JES Spool, an intermediate storage on disk. At the same time, a hanlde for the job is put on the Conversion Queue. This ends the submit.

    Conversion Phase

    The JES Conversion/Interpreter routine picks a job from the conversion queue, and reads the associated JCL from the JES Spool.

    The JCL is verified for correct syntax, "missing" parts are amended, i.e. copied into the JCL stream. "Missing parts" are predefined JCL statements, which reside in separate JCL Libraries. The EXEC PROC=, and the INCLUDE statements denote such parts to be copied in.

    Variables - called JCL Symbols, and System Symbols - are also dereferenced in this phase. Some statements such as the // SET statement are resoved at this stage.

    The final JCL is then written back to the JES spool, and if there was no error, the JCL is converted into an internal "executable" format, which is also written to the spool.

    This end conversion/interpretation for the current job. The process picks the next job from the queue, if any.

    Execution Phase

    Jobs on z/OS are executed by a z/OS component known as Initiator. There usually are many initiators running on a single z/OS instance.

    An initiator picks one job from the Execution Queue, and runs the job step by step. Note: The JCL has been finalised in the conversion phase; the initiator only reads the fixed, internal representation.

    Jobs in execution, more precisely programs run in the different job steps may use system resources, especially read and write to peripheral devices, such as disks, and tapes. They may also read data records that were submitted with the JCL stream, aka SYSIN data, and the may write output to the JES spool, aka SYSOUT data.

    After the last step of the job has finished execution, the initiator hands over the job to JES, again. The job's handle is placed on the Output Queue. The initiator picks the next job from the execution queue, if any.

    Output Phase

    JES processes jobs on the Output Quene, i.e. jobs that have ended. This phase prepares the various output items which may reside on the JES Spool, and marks then either to be kept waiting for further action, or for hard copy processing, or for deletion. The job's handle is the placed on the Hard Copy Queue, if at least one output has been marked so, else the handle is directly placed onto the Purge Queue.

    Hard Copy Phase

    Another type of JES processors (i.e. programs) work on a job's output marked for hardcopy processing. Output might have to be printed, either locally or on a remote print destination. An output might have to be archived. It may have to be transferred to another location for further processing. Probably no longer today, but in the past, it might have to be punched.

    The job resides on this queue until all parts have been procesed accordingly. Then the job's handle is placed on the final queue, the Purge Queue.

    Purge Phase

    JES purges, i.e. deletes, all fragments of this job from the JES spool. The job no longer exists in the system.