Hidden gems in the COND parameter in JCL

Hello,

Welcome! and wish you a happy new year 2019. In this post, I'll be sharing some 'not well-known' facts about the COND parameter in JCL. 

COND parameter is used to test return codes from previous job steps and determine whether to bypass this job step. More details are here.

Heads up: This article is quite long. Conclusion is available at the bottom of this article. 

First gem!💎
Do you know how to bypass the first job step using COND parameter?

We all know that the system evaluates a COND parameter on the first job step as false. The return code from the first job step will be used by the COND parameter coded in the subsequent job steps. But, it is possible to bypass the first job step using COND parameter.

Code COND=ONLY in the first job step to bypass it.

Let's look at an example. I have a JCL as shown in the Picture 8.1

Picture 8.1: COND=ONLY coded in the first job step.

As you see, the JCL has got one step with SORT utility. COND=ONLY is coded in the step. After submitting the job, it ends with RC 0 and the first step is flushed. See Picture 8.2

Picture 8.2: Voila! First step is bypassed.

Second Gem!💎
Atleast one return code is needed for the COND parameter to evaluate and determine whether to run/bypass the subsequent job steps. The return code need not be from the first job step. 

Let's look at an example to understand better. See the JCL in Picture 8.3. It has got 5 steps. 

Picture 8.3: Job with 5 steps. 

Let's say I want to bypass all the 5 steps. Coding COND=(0,LE) in the JOB statement would bypass all the steps except STEP1. Atleast one return code (from STEP1) is needed for the COND parameter coded in the JOB statement to bypass the subsequent job steps. 

A quote from z/OS MVS JCL User's guide says "The JOB statement COND parameter performs the same return code tests for every step in a job. If a JOB statement return code test is satisfied, the job terminates".  

But, what if I code COND=(0,LE) in the job statement and COND=ONLY in STEP1 EXEC statement? See Picture 8.4.

Picture 8.4: JCL with COND=(0,LE) in the JOB statement & COND=ONLY in the first step. 

Results, after submitting the job are quite interesting!

Picture 8.5: System message shows STEP2 CC=0000. 

Picture 8.6: Job log shows STEP1 is flushed and STEP2 alone ran.

Job log is shown in Picture 8.6. STEP1 was not executed because of COND=ONLY coded in the first step. But, STEP2 ran irrespective of the COND parameter coded in the JOB statement. Atleast one return code is needed for the COND parameter to bypass the subsequent steps. The return code need not be from the first step. If the first step is bypassed, system will run the second step for return code. Return code from STEP2 will be evaluated on STEP3 and the job will terminate as COND=(0,LE) satisfies to true. 

So, how can we bypass all the 5 steps? 
If you want to acheive this using COND parameter, code COND=ONLY in all the 5 steps. You can't code COND=EVEN or COND=ONLY in the JOB statement.

Last gem! 💎(hmm, as of now. I might add more gems  in the future).

Check this link for better understanding of COND parameter in JCL. The link shows an example of COND return code testing in a job. The example has got COND parameter coded in both JOB and EXEC statements. 

Conclusion: 

• Code COND=ONLY in the first step to bypass it.
• COND=ONLY & COND=EVEN can't be coded in the JOB statement. 
• Atleast one return code is needed for the COND parameter to evaluate and determine whether to run/bypass the subsequent job steps. The return code need not be from the first job step.
• When COND parameter is coded on JOB and EXEC statements, first evaluation is with COND parameter coded in the JOB statement. If the return code test is satisfied, the JOB terminates. If the JOB statement return code is not satisfied, the system checks the COND parameter on the EXEC statement for the next step. If the EXEC statement return code test is satisifed, system bypasses that step and begins processing of the next step in sequence. 
• Each step's return code are used for subsequent step's return code evaluation. For example, if first step's return code is 2 and second step's return code is 6, then system will evaluate return codes 2 and 6 against the COND parameter coded in the 3rd step to decide whether to bypass/run it.  

Hope this helps!👍

References:  z/OS MVS JCL User's guide. 
Screenshot Courtesy: Mainframe access💻 obtained via Master the Mainframe contest run by IBM.

What happens when you submit a JCL with two JOB statements?

Hello,

In this short article, we'll see what happens when we submit a job with two JOB statements in JCL🤔. Ready?

Let's start with following JCL. 

Image 7.1: JCL with 2 JOB statements

I have defined two JOB statements. The job names are Z31084A and Z31084B. Guess what will happen when I submit this JCL. 

Well, 2 jobs are submitted. See Image 7.2. Hooray!😀 Question answered. But, please spare a minute and read on till the Takeaway section. 

Image 7.2: 2 jobs are submitted. 

Wonder what, both the jobs are failed with JCL error. 

Image 7.3: System message showing that jobs are failed with JCL error. 

But, why the jobs failed? 
Accessing the JESYSMSG (of Z31084A job) in spool shows the following message. 

Image 7.4: Job has no steps. 

JOB HAS NO STEPS. 
So, when you run a job, it MUST contain one or more steps. Otherwise, the job will fail. 

Takeaway: 

The system detects the end of the job when it finds,

• a // or null statement,
• another JOB statement,
• or simply when there are no more records to be read in.

When a JCL with more than one JOB statement is submitted, total no. of jobs submitted will be equivalent to the total no. of JOB statements in the JCL.

When I modify the JCL shown in Image 7.1 by adding a SORT step just below each JOB statement, 2 jobs will be submitted and they would end with RC 00. 

Hope this helps!👍


Screenshot courtesy: Mainframe access 💻 obtained via Master the Mainframe contest run by IBM.