SORT field format does not match input data

Troubleshooting guide for SORT field format does not match input data. DFSORT failures are almost always control-card problems: the sort runs fine, but INCLUDE/OUTREC describe a different record than the input really is.

What it means

• DFSORT reads the input exactly as described by FIELDS/OUTREC positions — 1-based, byte positions, not field numbers.
• INCLUDE/OMIT conditions filter before sorting; an impossible condition yields zero records with RC=0, which looks like success.
• Wrong field format (CH vs BI vs PD vs ZD) compares garbage, producing silently wrong order.

Common causes

• Zero records out: INCLUDE COND references wrong positions, so every record is filtered — e.g. testing position 10 for "A" when the flag is at position 12.
• INCLUDE filters everything because the comparison value length does not match the field length (trailing blanks matter in CH comparisons).
• OUTREC positions wrong: 1-based positions miscounted, so fields land shifted in the output.
• Field format mismatch: input is packed-decimal (PD) but the card says ZD — the sort key is garbage.
• Duplicates remain: SUM FIELDS=NONE not coded, or the duplicates differ in trailing blanks so they are not really duplicates.
• ICETOOL count wrong: COUNT was run on the wrong DD, or BEFORE/AFTER subparameters counted different record sets.
• SORTIN DCB wrong: LRECL on the DD does not match the real file, so positions shift for every record.

How to diagnose

• Run with a tiny test file (5 records) and DISPLAY the output — eyeball whether positions and filtering behave.
• Hex-dump one input record and hand-map each FIELDS position against the dump.
• For zero-record output: comment out the INCLUDE and rerun — if records appear, the condition is wrong, not the data.
• Check the DFSORT messages (ICE031I etc.) for the record counts at each phase: IN, OUT, and filtered counts.
• Verify SORTIN LRECL/RECFM against the real dataset before touching the control cards.

How to fix it

• Correct the INCLUDE positions after hex-mapping one real record.
• Use the right format: PD for packed, ZD for zoned, BI for binary, CH for character.
• Add SUM FIELDS=NONE to drop true duplicates, or sort on the full key that defines uniqueness.
• Fix OUTREC with 1-based positions counted from the hex dump, not from the copybook alone.
• Point ICETOOL COUNT at the intended input DD and recheck BEFORE/AFTER logic.

Example: DFSORT with INCLUDE and OUTREC

Positions are 1-based bytes; INCLUDE filters before SORT; SUM FIELDS=NONE removes exact duplicates.

Interview tip

• Q: A DFSORT step ends RC=0 but SORTOUT is empty. SORT field format does not match input data — what is the most likely cause?
• A: The INCLUDE condition is filtering out every record — usually a wrong position or a length mismatch in the comparison. I comment out INCLUDE and rerun: if records appear, the condition is wrong, not the input file.

Prevention checklist

• Hex-map one real record before writing FIELDS positions.
• Test control cards on a 5-record file first.
• Match SORTIN DCB to the real dataset attributes.
• Check ICE message record counts (in vs out) on every run.