Saturday, 10 August 2013

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 utility comparing SYSUT1 and SYSUT2 data sets with a recommendation to use SuperC for new work
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

StatementPurposeImportant point
EXEC PGM=IEBCOMPRRuns the comparison program.Give the step a clear name so later JCL can test its condition code.
SYSPRINTReceives messages and the difference report.Required. Review it even when automation tests the step result.
SYSUT1Defines the first input data set.Input can also be passed from an earlier step.
SYSUT2Defines the second input data set.Its LRECL must match SYSUT1; BLKSIZE may differ.
SYSINSupplies 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

RequirementIEBCOMPRSuperC
IBM direction for new comparisonsRetained mainly for compatibility with existing jobs.IBM's recommended choice instead of IEBCOMPR.
OperationBatch utility called with PGM=IEBCOMPR.Foreground through ISPF option 3.12 or batch with PGM=ISRSUPC.
Comparison choicesLogical-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 itAn 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

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.

No comments:

Post a Comment