IEC143I: 213 abend, open failed on a disk data set

What it means

When a program opens a data set on disk, z/OS reads the data set's entry in the volume's table of contents (the VTOC). That entry is called the format-1 DSCB. It holds the data set's attributes and where its extents are. If the open can't use that entry, or finds that the request breaks a rule for this type of data set, it writes IEC143I and ends the step with abend 213.

The message gives the abend and return code, the module that found the problem, the job name, step name and DD name, the device number, the volume serial, and the data set name with any member. If the data set name shows as PATH=.SPECIFIED, the problem is with a z/OS UNIX file.

Return code 04 is the one most people meet. It means the data set's DSCB couldn't be read or wasn't on the first volume. The usual reason is that the catalog, or a VOL=SER on the DD statement, points at a volume that doesn't hold the data set. It also covers a JFCB that a program changed wrongly, and a volume another job was using in a conflicting way.

The list of return codes is long and grows with each release, because many newer data set types have their own rules. A few that come up are 30 (a PDS opened for output with DISP=SHR while it was already open for output, often by another job, with IEC813I naming the holder), E9 (a sequential data set in a concatenation of libraries) and FC (a UNIX file that doesn't exist). FD (a sequential data set opened for output with DISP=SHR while already open for output, with enhanced data integrity enforced) is another. For any other code, look it up under IEC143I in z/OS MVS System Messages for your release.

Common causes

• The catalog says the data set is on a volume where it isn't. This happens after a volume was restored, or when the data set was deleted or moved by a tool that didn't update the catalog.
• The DD statement codes VOL=SER and UNIT for an existing data set, and the data set isn't on that volume.
• Two jobs, or two tasks, opened the same PDS for output with DISP=SHR at the same time (return code 30).
• A sequential data set was put in a concatenation of libraries, such as a STEPLIB or SYSLIB (return code E9).
• A UNIX path in the JCL names a file that doesn't exist (return code FC).
• The program changed the JFCB before opening with OPEN TYPE=J and got it wrong.

How to find the problem

1. In SDSF, open JESYSMSG and find IEC143I. Note the return code, the DD name, the volume serial and the data set name.
2. For 213-04, check where the catalog thinks the data set is with LISTCAT ENTRIES('PROD.PAYROLL.MASTER') VOLUME. Then list that volume's data sets in ISPF option 3.4 by entering the volume serial and leaving the data set name blank, or run IEHLIST LISTVTOC.
3. Check the DD statement for VOL=SER or UNIT. On an existing cataloged data set they override the catalog.
4. For return code 30, find IEC813I in the same job log. It names the job holding the library.
5. For a concatenation, check every data set under that DD name. The hyphen and number after the DD name tell you which one failed.

How to fix it

• If the catalog is wrong, fix it. Uncatalog the entry if the data set is gone, or recatalog it to the volume where it really is.
• Remove VOL=SER and UNIT from DD statements for cataloged data sets, so z/OS uses the catalog.
• Use DISP=OLD when a step writes to a PDS, so two jobs can't update it at once.
• Take the sequential data set out of the library concatenation.
• Create the missing UNIX file or correct the path.

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.