What it means
Before a program reads or writes a sequential file or a library member, it opens it. During the open, z/OS combines the file's attributes from three places. They come from the program's own file definition, from the DD statement in the JCL, and from the data set's label on disk. It then checks that the result makes sense. If something conflicts, or a member that was asked for isn't there, the open fails. z/OS writes IEC141I and ends the step with abend 013.
The message packs a lot into one line. In order, it gives the code and reason (such as 013-18), the z/OS 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 failing data set isn't the first one in a concatenation, a hyphen and its position follow the DD name. The device, volume and data set name are left out for SYSIN and SYSOUT data sets and for z/OS UNIX files.
The I at the end of the message number stands for informational, but the step has already abended. IEF450I follows with ABEND=S013 and the same reason in its REASON field.
Common causes
- 013-18 means the member named in the DD statement isn't in the library. This is the most common one. JCL allocation doesn't check that a member exists, so the job starts and then fails at the open.
- 013-20 means the record format, record length and block size don't fit together for a sequential data set. For fixed-length blocked records, the block size isn't a whole multiple of the record length, so
LRECL=80withBLKSIZE=27999fails this way. For variable-length records, the block size must be at least 4 bytes more than LRECL. - A DCB value hard-coded in the JCL (RECFM, LRECL or BLKSIZE) no longer matches the data set after someone changed its layout.
- The program's file definition expects a different record format or length than the data set has.
- Data sets with different attributes are concatenated under one DD name, and a later one doesn't fit the first.
- Other reason codes cover other conflicts and failures. Look up the exact number under system completion code 013 in IBM's z/OS MVS System Codes for your release.
How to find the problem
- Read the reason code, the DD name and the data set name in IEC141I. Together they tell you which file failed and why.
- For 013-18, list the library's members with ISPF option 3.4 or
LISTDS 'PROD.PAYROLL.CNTL' MEMBERS. Check the spelling and that the step points at the right library. - For 013-20 and other attribute problems, look at the data set's real attributes in ISPF 3.4 (the I line command) or with LISTDS. Compare them with any DCB values on the DD statement.
- Check the program's file definition, such as the COBOL FD, for the record length and format it expects.
- If the DD name has several data sets concatenated under it, check the data set named in the message, which may not be the first one. A number after a hyphen in the DD name field means a later data set in the concatenation failed, not the first.
How to fix it
- For 013-18, correct the member name or create the member, then rerun the step.
- For 013-20 on a new data set, remove BLKSIZE from the DD statement and let z/OS choose an efficient block size, or code a value that is an exact multiple of LRECL.
- Don't hard-code DCB values on DD statements for existing data sets unless you must. z/OS reads them from the data set label.
- If an existing data set was created with bad attributes, copy it to a new data set with correct ones and rename it.
What it looks like
IEC141I 013-18,IGG0191B,PAYRUN01,STEP010,SYSIN,0A82,PRD001,PROD.PAYROLL.CNTL(PAYPARMX) IEA995I SYMPTOM DUMP OUTPUT SYSTEM COMPLETION CODE=013 REASON CODE=00000018 IEF450I PAYRUN01 STEP010 - ABEND=S013 U0000 REASON=00000018