ICE141A: Spanned record could not be assembled

What it means

A variable spanned data set (RECFM=VS or VBS) can hold logical records longer than its block size. The access method splits each long record into segments. Every segment has a 4-byte segment descriptor word that says whether it is a complete record, the first segment, a middle segment or the last segment. To process the record, DFSORT reads the segments in order and joins them again.

ICE141A means that join failed. DFSORT found a first segment with no last segment, a middle or last segment with no first segment, or a set of segments that didn't make sense together. Because a broken record could produce wrong output, DFSORT ends the run. The message names the ddname of the input it was reading, such as SORTIN, or a system-generated name like SYS00001 when another program called DFSORT with a dynamically allocated input.

IBM changed the ICE141A text in z/OS 2.1 to give more diagnostic detail, so the wording you see depends on your release. The A suffix marks a critical error, and the step normally ends with return code 16.

Common causes

• The input data set is damaged. Segments were lost when a program wrote the file, for example when a buffer filled up and dropped a segment.
• A multi-volume spanned data set is missing a volume, or a volume can't be read, so a record that crosses the volume boundary is incomplete.
• The data set was copied or truncated by a utility or a program that didn't handle spanned records, leaving segments out of order or cut off.
• Records longer than 32752 bytes are in a data set that wasn't defined with LRECL=X. IBM fixed a File Manager problem of this kind, where an IEBCOPY unload produced such records and DFSORT then failed with ICE141A.
• The program that created the file wrote segment descriptor words by hand and set them wrongly.

How to find the problem

1. Note the ddname in ICE141A and check the DCB of that data set in ISPF 3.4 (type I next to the name). Confirm it really is RECFM=VS or VBS, and check its LRECL.
2. If the input is a concatenation or several tape volumes, check that every volume is present and in the right order.
3. Find out which job created the data set and whether it ended cleanly. A job that abended while writing often leaves a partial last record.
4. If DFSORT was called from another product, such as a file editor or a reporting tool, look for that product's own messages and search its APARs for ICE141A.

How to fix it

• Recreate the input from a good source if you can. A broken spanned record usually means the file itself is damaged.
• Fix the program or step that writes the file so that it always writes complete spanned records and closes the file properly.
• For records over 32752 bytes, make sure the data set is defined for them, or use a tool that handles them.
• If another IBM product called DFSORT, check for maintenance. IBM has fixed ICE141A failures caused by how some products handled large spanned records.
• If you must salvage the good records, a small program can read the file and keep only complete records. Treat the result as a partial file and check it with the data owner.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s documentation for your z/OS release.