IEBCOMPR Utility JCL: Compare Data Sets and Use SuperC

The IEBCOMPR utility compares two z/OS data sets at the logical-record level. A familiar step starts with //COMPARE EXEC PGM=IEBCOMPR, assigns the inputs to SYSUT1 and SYSUT2, and sends the comparison report to SYSPRINT.

Current IBM guidance: use SuperC instead of IEBCOMPR for new comparison work. IEBCOMPR remains useful when reading or maintaining established JCL and when a simple copy-verification step is already part of an operating procedure.

IEBCOMPR reads two inputs and reports record-level differences through SYSPRINT.

What IEBCOMPR compares

IEBCOMPR can compare two sequential data sets, two partitioned data sets (PDS), or two partitioned data sets extended (PDSE). It supports fixed, variable, and undefined record formats, whether blocked or unblocked. The two inputs must have the same logical record length. Their block sizes can differ.

A sequential pair is equal when both inputs contain the same number of records and each corresponding record is equal. If keyed records are involved, their keys must also agree. For a PDS or PDSE pair, corresponding members must have the same records, keys, note-list positions, and directory user data.

Do not use IEBCOMPR for everything: it does not compare VSAM data sets, and IBM specifically says not to use it for load modules. PDS and PDSE comparisons also have a practical limit of about 290,000 members.

For the wider utility family, see the JCL utility overview. IEBCOMPR is for comparison; IEBCOPY copies and maintains partitioned data sets, while IEBPTPCH prints or punches sequential and partitioned data.

IEBCOMPR DD statements

Statement	Purpose	Important point
EXEC PGM=IEBCOMPR	Runs the comparison program.	Give the step a clear name so later JCL can test its condition code.
SYSPRINT	Receives messages and the difference report.	Required. Review it even when automation tests the step result.
SYSUT1	Defines the first input data set.	Input can also be passed from an earlier step.
SYSUT2	Defines the second input data set.	Its LRECL must match SYSUT1; BLKSIZE may differ.
SYSIN	Supplies IEBCOMPR control statements.	Use DD DUMMY for a basic sequential comparison.

The JCL EXEC statement selects the program, and the JCL DD statement connects the program to each data set.

Sequential data set comparison JCL

This example compares a source data set with its backup. No user exit, label processing, or organization override is required, so SYSIN DD DUMMY is sufficient.

//COMPARE EXEC PGM=IEBCOMPR //SYSPRINT DD SYSOUT=* //SYSUT1 DD DSN=USER1.SOURCE.DATA,DISP=SHR //SYSUT2 DD DSN=USER1.BACKUP.DATA,DISP=SHR //SYSIN DD DUMMY

IEBCOMPR treats sequential organization as the default. If records differ, the report identifies the record and block numbers, the associated DD names, and the unequal record contents. After ten successive unequal comparisons, IEBCOMPR stops the step unless a user exit takes control.

Operational check: inspect both the job-step condition code and SYSPRINT. The report explains where a mismatch occurred; do not replace that evidence with an assumed return-code meaning.

PDS or PDSE comparison JCL

For partitioned organization, the COMPARE statement must be the first control statement and TYPORG=PO identifies PDS or PDSE input.

//COMPARE EXEC PGM=IEBCOMPR //SYSPRINT DD SYSOUT=* //SYSUT1 DD DSN=USER1.PROCLIB,DISP=SHR //SYSUT2 DD DSN=USER1.PROCLIB.BACKUP,DISP=SHR //SYSIN DD * COMPARE TYPORG=PO /*

The alternative TYPORG=PS explicitly selects sequential organization. A COMPARE statement is also required when IEBCOMPR exit routines or label processing are requested.

Compare a data set after a copy step

A verification flow should run the comparison only if the copy completed successfully. The following example copies a sequential data set and then compares source with target. It intentionally keeps allocation details short; production jobs should follow local SMS, retention, and catalog standards.

//COPY EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //SYSUT1 DD DSN=USER1.INPUT.DATA,DISP=SHR //SYSUT2 DD DSN=USER1.OUTPUT.DATA,DISP=OLD //SYSIN DD DUMMY //SYSUT3 DD DUMMY //SYSUT4 DD DUMMY // IF (COPY.RC = 0) THEN //VERIFY EXEC PGM=IEBCOMPR //SYSPRINT DD SYSOUT=* //SYSUT1 DD DSN=USER1.INPUT.DATA,DISP=SHR //SYSUT2 DD DSN=USER1.OUTPUT.DATA,DISP=SHR //SYSIN DD DUMMY // ENDIF

This pattern separates the copy result from the comparison result. A scheduler or later step can react to the named VERIFY step, while SYSPRINT retains the detailed diagnostic report.

Record format and allocation checks

• LRECL: SYSUT1 and SYSUT2 must have the same logical record length or IEBCOMPR considers them unequal.
• BLKSIZE: block sizes may differ. For fixed blocked records, each block size must be a multiple of LRECL and cannot exceed 32,760 bytes.
• Organization: compare sequential with sequential or partitioned with partitioned; select partitioned processing with TYPORG=PO.
• VSAM: IEBCOMPR is part of the non-VSAM data set utility group and is not a VSAM comparison tool.
• Program objects: use a suitable program-object or library tool rather than IEBCOMPR to validate load modules.

IEBCOMPR versus SuperC

Requirement	IEBCOMPR	SuperC
IBM direction for new comparisons	Retained mainly for compatibility with existing jobs.	IBM's recommended choice instead of IEBCOMPR.
Operation	Batch utility called with PGM=IEBCOMPR.	Foreground through ISPF option 3.12 or batch with PGM=ISRSUPC.
Comparison choices	Logical-record comparison with a traditional difference listing.	File, line, word, and byte comparison with reporting options such as DELTA, CHNG, LONG, and OVSUM.
Best reason to keep it	An established, tested job requires the original behavior.	A new or revised process needs clearer reports and more comparison control.

Migration is not only a program-name substitution. Test the SuperC options, sequence-column handling, report format, return-code expectations, and downstream automation before replacing an established IEBCOMPR step.

Troubleshooting an IEBCOMPR step

• If the step reports immediate inequality, compare the two LRECL values and confirm both DD statements identify the intended generation or copy.
• If a PDS or PDSE job is treated incorrectly, confirm that COMPARE TYPORG=PO is the first SYSIN control statement.
• If output is truncated or hard to read, check the SYSPRINT allocation and spool destination before changing the comparison logic.
• If the step stops after repeated differences, remember the ten-successive-mismatch rule and inspect the earliest reported records.
• If the target is VSAM or a program library, choose a tool designed for that data type.

For readers learning the surrounding syntax, the JCL tutorial explains job, EXEC, and DD structure before utility-specific control statements are added.

Official IBM references

• IEBCOMPR: Compare data sets
• IEBCOMPR job control statements
• IEBCOMPR COMPARE statement
• IEBCOMPR examples
• SuperC utility option 3.12
• SuperC reference

Frequently asked questions

What does the IEBCOMPR utility compare?

IEBCOMPR compares two sequential data sets, two partitioned data sets, or two PDSEs at the logical-record level. It is often retained in jobs that verify a backup or copy.

Is SYSIN required for IEBCOMPR?

Yes. Code SYSIN DD DUMMY for a basic sequential comparison without user routines. Supply a COMPARE statement for a PDS or PDSE comparison and when exits or labels are used.

Can IEBCOMPR compare VSAM data sets or load modules?

No. The z/OS data set utilities described for IEBCOMPR do not support VSAM, and IBM says not to use IEBCOMPR to compare load modules.

Should a new job use IEBCOMPR or SuperC?

IBM recommends SuperC instead of IEBCOMPR for new comparison work. SuperC offers foreground and batch operation plus more useful reporting and comparison choices.

Working rule: preserve IEBCOMPR where compatibility matters, but assess SuperC when creating or materially revising a comparison process.

All You Need To Know About JCL Utility, IDCAMS, IEBCOMPR, IEBCOPY, IEBDG etc.

Welcome Back once again Guys! 

In today's tutorial, You’ll learn how to use the z\OS JCL utility programs that make it easy for you to work with data sets and to generate test data. I will precisely introduce you to various JCL utility and important system libraries. So, let's start with the tutorial. 

IBM Utility.

What is a Utility Program?

Technically speaking, JCL Utility programs (or just utilities) are the programs that can be used for common data processing functions like copying or printing a data set. With OS/390, you get an older set of utilities known as the MVS utilities.

The MVS utilities are older utilities that are provided by OS/390. Some of these utilities have been replaced by newer utilities or ISPF options. 

The JCL for running a utility program has to provide a DD statement for each ddname that’s used by the utility. The SYSIN data set is normally an in-stream data set that consists of control statements that provide processing specifications. 

All JCL utilities are normally run as batch jobs. z/OS provide a wide variety of function, but only a small number system provided JCL utility exist. Most of you might be aware of the utility IEFBR14, IEBGENER, and IEBCOPY. For VSAM you would normally use IDCAMS for various operations.

There are large utilities created by 3rd party vendors and are widely available on z/OS. The utilities are broadly categorized into two categories:

Data set utilities: These utilities are used for reorganizing data, compare data in two datasets, etc. All these utility run in batch mode.

System Utilities: These utilities are used to perform a wide-ranging operation that is related to data sets and volumes, such as data set names, catalog entries, and volume labels

IBM Utility Example

IDCAMS IEBCOMPR IEBCOPY IEBDG IEBEDIT IEBGENER IEBIMAGE IEBISAM IEBPTPCH IEBTCRIN IEBUPDAT IEBUPDTE IEFBR14 ICKDSF IEHATLAS IEHDASDR IEHINITT IEHIOSUP IEHLIST IEHMOVE IEHPROGM IFHSTATR

What are system libraries?

z/OS has many standard system libraries. A brief description of several libraries is appropriate here. The traditional libraries include: 

• SYS1.PROCLIB - This is a system library that contains JCL procedures supplied with z/OS. 
• SYS1.PARMLIB - This system library holds control parameters for z/OS supplied program and various other products. 
• SYS1.LINKLIB - This library contains many of the basic execution modules of the system. In practice, it is one of a large number of execution libraries that are concatenated.
• SYS1.LPALIB - This system library holds system execution modules that are loaded into the link  pack area when the system is initialized. 
• SYS1.NUCLEUS - This system library holds the basic "kernel" modules of z/OS.
• SYS1.SVCLIB. This library holds operating system routines known as supervisor calls (SVCs).

These libraries are in standard PDS format and are found on the system disk volumes.

#COBOL #JCL  #CICS #DB2