ICE027A: End of field beyond maximum record length
ICE027A means a field in a DFSORT control statement ends past the maximum record length, or a reformatted record would be longer than 32767 bytes. When the message names a ddname, the problem is in the OUTFIL statement for that output.
Other names for this code
Also written as ICE027A END OF FIELD BEYOND MAXIMUM RECORD LENGTH, DFSORT ICE027A, ICE027A OUTFIL, ICE027A ICETOOL, sort ICE027A.
What it means
Every field in a DFSORT statement is given as a starting position and a length. DFSORT adds them up and checks that the field ends inside the record. If a field would end past the maximum record length, DFSORT can't trust it and stops with ICE027A. The same message covers an INREC or OUTREC that builds a record longer than 32767 bytes.
The message comes in two forms. Without a ddname, the bad field is in SORT, MERGE, SUM, INCLUDE, OMIT, INREC or OUTREC. With INREC present, the SORT, MERGE, OUTREC and SUM fields are checked against the reformatted INREC length, not the input length. With a ddname, the named data set is the first OUTFIL output where an OUTFIL field runs past its input length, or where the OUTFIL record would exceed 32767 bytes.
The A suffix marks a critical error. DFSORT stops before writing output, and the step normally ends with return code 16.
Common causes
- A field on a variable-length file was positioned without counting the 4-byte record descriptor word (RDW). On a VB file, data starts at position 5, so a layout copied from a fixed file is 4 bytes short.
- A field position or length was typed wrongly, for example
(75,10,CH,A)on an 80-byte record. - INREC shortened the record, but SORT or OUTREC still refers to positions in the original layout.
- An OUTFIL BUILD refers to positions past the end of its input, or builds a record over 32767 bytes.
- The input data set has a smaller LRECL than the program or copybook assumed.
- In ICETOOL, an ON field runs past the record, or a DISPLAY, OCCUR, RANGE, STATS, UNIQUE or VERIFY operator reads a FROM data set with an LRECL under 4.
How to find the problem
- Check the ICE027A line in the sort step's SYSOUT. Note whether it names a ddname. If it does, look at that OUTFIL statement first.
- Find the record length DFSORT used. The data set's LRECL is shown in ISPF 3.4 (type I next to the name) or in LISTCAT. For VB data, remember the LRECL includes the 4-byte RDW.
- For each field, add the start position and length and subtract 1. The result must not exceed the record length DFSORT is checking against.
- If INREC is coded, work out the length of the INREC output and check the later statements against that, not against the input length.
- For ICETOOL jobs, read the DFSMSG output for the operator that failed.
How to fix it
- Correct the position or length of the field DFSORT complained about.
- For variable-length input, add 4 to every position taken from a record layout that doesn't include the RDW.
- After INREC, write SORT, OUTREC and SUM positions in terms of the reformatted record.
- Keep reformatted records within 32767 bytes, or split the output across OUTFIL statements.
- If the input really is shorter than expected, find out why before changing the sort. A file with the wrong LRECL often points to a problem in the job that created it.
IBM documentation
IBM documentation: ICE027A. Use the documentation for your installed release.
Related codes
Questions
Why does ICE027A happen only on the VB version of a file?
On variable-length records DFSORT counts the 4-byte RDW as positions 1 to 4. A field that starts at position 77 on the fixed file starts at position 81 on the VB file.
What does the ddname in ICE027A mean?
It names the first OUTFIL output whose statement has the bad field or would build a record over 32767 bytes. Without a ddname, the problem is in the main SORT, INCLUDE, INREC, OUTREC or SUM statements.
Does ICE027A mean the data is bad?
No. It is raised when DFSORT checks the control statements against the record length, before it processes records.