JCL ABDISPCC in practice on z/OS

ABDISPCC is a recent addition to JCL because it solves a real operational problem: a step can end normally, but with a return code that is high enough that you do not trust its output. In older JCL, that usually meant extra cleanup logic in later steps or procedural work outside the job.

This article is deliberately practical. It uses small IDCAMS jobs that end with controlled return codes and shows exactly how ABDISPCC changes the disposition outcome of a newly allocated data set.

1. Lab goals

By the end of this lab you should be able to:

• Explain what ABDISPCC does on the EXEC statement
• Distinguish disposition control from step-flow control
• Prove the baseline behavior without ABDISPCC
• Use ABDISPCC=(8,GE) to prevent suspect output from being cataloged
• Understand the difference between GT and GE

2. Required environment

For this lab, use:

• z/OS 2.5 or later
• JES2
• TSO/ISPF access with permission to submit batch jobs
• A user ID that can allocate cataloged test data sets with the &SYSUID prefix

Important note:

• IBM documents ABDISPCC as a newer EXEC keyword and also notes that it is not supported in JES3 environments
• The function was delivered by APAR OA63081 for HBB77C0 and above
• Minimum practical level:
• z/OS 2.5 with PTF UJ93787
• z/OS 3.1 with PTF UJ93788
• z/OS 3.2 with PTF UJ93785

If your system does not recognize the ABDISPCC keyword, the most likely cause is that the required maintenance is not installed.

3. What ABDISPCC changes

Without ABDISPCC, a normally ending step always uses the normal-end disposition from DISP or PATHDISP, even if the return code is undesirable.

With ABDISPCC, you can say:

//STEP1 EXEC PGM=program-name,ABDISPCC=(code,operator)

The system compares the current step completion code with the condition:

When the condition matches, z/OS applies the abnormal-end disposition logic to the DD statements in that step, even though the step itself ended normally.

That is the whole value of ABDISPCC: it lets you say, in JCL, “an RC 8 or above is bad enough that the output should be handled like failed output.”

4. Important distinction: disposition control is not flow control

ABDISPCC does not control whether the next step runs. It only affects disposition processing for DDs in the current step.

Use the following mechanisms for different purposes:

5. How the lab works

We will submit four small jobs:

All four jobs allocate a new sequential data set with:

DISP=(NEW,CATLG,DELETE)

The step then runs IDCAMS and sets a controlled return code through SET MAXCC=8 or SET MAXCC=12.

That makes the result easy to observe:

• if the normal disposition applies, the data set is cataloged
• if the abnormal disposition applies, the data set is deleted

6. Job 1: baseline behavior without ABDISPCC

Create a JCL member such as ABDNOCC with the following content:

//ABDNOCC  JOB ,'ABDISPCC LAB',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//STEP1    EXEC PGM=IDCAMS
//TESTOUT  DD  DSN=&SYSUID..ABDISPCC.NOCC,
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(TRK,(1,1)),
//             DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
  SET MAXCC=8
/*

Submit the job and inspect the output:

• the step should end normally
• the step completion code should be 8

Now, use ISPF 3.4 to verify whether the data set exists. You will be able to find the Data Set.

Why:

• The step ended normally
• There was no ABDISPCC
• So z/OS used the normal disposition, which is CATLG

This is what often surprises people: a job can return RC 8 and still catalog its output.

7. Job 2: use ABDISPCC=(8,GE)

Create a second member such as ABDGE8:

//ABDGE8   JOB ,'ABDISPCC LAB',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//STEP1    EXEC PGM=IDCAMS,ABDISPCC=(8,GE)
//TESTOUT  DD  DSN=&SYSUID..ABDISPCC.GE8,
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(TRK,(1,1)),
//             DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
  SET MAXCC=8
/*

Submit it and check the result:

• the step should again end normally with completion code 8

Now, try to locate again the dataset using ISPF 3.4. The data set should not be found.

Why?

• The step ended normally with RC 8
• ABDISPCC=(8,GE) matched
• z/OS therefore applied the abnormal-end disposition
• The third DISP sub-parameter is DELETE

This is an useful production pattern:

DISP=(NEW,CATLG,DELETE)

combined with:

ABDISPCC=(8,GE)

It says: “catalog the output only if the step really completed well enough.”

8. Job 3: GT is different from GE

Now create ABDGT8:

//ABDGT8   JOB ,'ABDISPCC LAB',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//STEP1    EXEC PGM=IDCAMS,ABDISPCC=(8,GT)
//TESTOUT  DD  DSN=&SYSUID..ABDISPCC.GT8,
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(TRK,(1,1)),
//             DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
  SET MAXCC=8
/*

Submit the job and verify. This time the data set exists.

Why?

• RC 8 is not greater than 8
• ABDISPCC=(8,GT) does not match
• z/OS keeps using the normal disposition

This is the exact difference:

9. Job 4: ABDISPCC=(8,GT) with a higher return code

Create one final member, ABDGT12:

//ABDGT12  JOB ,'ABDISPCC LAB',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//STEP1    EXEC PGM=IDCAMS,ABDISPCC=(8,GT)
//TESTOUT  DD  DSN=&SYSUID..ABDISPCC.GT12,
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(TRK,(1,1)),
//             DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
  SET MAXCC=12
/*

Verify it. The data set is not found.

Why?

• RC 12 is greater than 8
• ABDISPCC=(8,GT) matches
• z/OS applies the abnormal disposition and deletes the data set

10. Where ABDISPCC is most useful

The most practical use cases are:

• Batch steps that allocate a new output data set and should catalog it only for acceptable return codes
• Report-generation steps where RC 4 may be acceptable but RC 8 should discard output
• Unload, extract, or transform steps that can finish normally but still produce unusable results
• z/OS UNIX file processing with PATHDISP, because the same logic also applies there

In design terms, ABDISPCC lets you keep the return-code policy close to the step that creates the output.

11. Common mistake to avoid

Do not treat ABDISPCC as a replacement for COND or IF/THEN/ELSE.

This is wrong thinking:

• “I used ABDISPCC, so later steps will not run.”

This is the correct thinking:

• “I used ABDISPCC, so the output of this step will be deleted instead of cataloged when the return code is too high.”

If you also need to stop or bypass later steps, add normal JCL flow-control logic separately.

12. Cleanup

If you want to remove any data sets created during the lab, submit:

//ABDCLN   JOB ,'ABDISPCC LAB',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//STEP1    EXEC PGM=IDCAMS
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
  DELETE '&SYSUID..ABDISPCC.NOCC'
  IF LASTCC = 8 THEN SET MAXCC = 0
  DELETE '&SYSUID..ABDISPCC.GE8'
  IF LASTCC = 8 THEN SET MAXCC = 0
  DELETE '&SYSUID..ABDISPCC.GT8'
  IF LASTCC = 8 THEN SET MAXCC = 0
  DELETE '&SYSUID..ABDISPCC.GT12'
  IF LASTCC = 8 THEN SET MAXCC = 0
/*

Summary

ABDISPCC is small, but operationally very useful. It lets you turn a normal completion code threshold into a disposition decision without extra cleanup steps.

The key practical pattern is:

//STEP1   EXEC PGM=program-name,ABDISPCC=(8,GE)
//OUTDD   DD   DSN=...,DISP=(NEW,CATLG,DELETE)

That means:

• Catalog the output only when the step completes well enough
• Otherwise delete it, even if the step ended normally

Useful IBM documentation

• ABDISPCC parameter
• EXEC statement
• Summary of changes for z/OS 3.1
• Summary of disposition processing
• IDCAMS SET command
• LISTCAT command
• APAR OA63081 - new function for ABDISPCC