System abend

S001: I/O error

An S001 abend means a read or write to a sequential data set failed with an I/O error, and the program had no error routine to deal with it. Most often the record length or format the job used doesn't match the data. Less often the disk or tape is damaged.

Also written as 001, S001-4, abend 001, system abend 001, SYSTEM=001, I/O error abend.

What it means

When a program reads or writes a sequential file through QSAM or BSAM, the access method checks every block it moves. If a block isn't the length it expects, or the device reports an error it can't recover from, the access method looks for an error routine (a SYNAD exit) in the program. If there isn't one, or the program asked to abend on errors, z/OS ends the step with system completion code 001.

The message that goes with it is IEC020I. It carries a return code after the dash, such as 001-4, and names the DD statement, the unit, the volume and the data set that failed.

Most S001 abends have nothing to do with hardware. They happen when the program or the JCL expects one record layout and the data set holds another.

Common causes

  • DCB attributes in the JCL or the program override the data set's real ones. For example, the DD statement says RECFM=FB,LRECL=80 for a file that was written with LRECL=100, so every block comes back the wrong length.
  • A variable-length file is read as fixed-length, or the other way round, often after a copybook or FD change that wasn't matched in the file.
  • Several data sets with different record formats or lengths are concatenated under one DD statement, and the program reads all of them with the attributes of the first.
  • An assembler program issues another GET after its end-of-data routine has already run.
  • A damaged tape or a bad track on disk. These failures also leave hardware error messages in the system log.

How to find the problem

  1. Find IEC020I in the job log. Note the return code, the data set name and the DD name, which tells you which file in the program failed.
  2. Compare the data set's real attributes, shown by ISPF 3.4 or LISTDS, with any DCB, RECFM, LRECL or BLKSIZE on the DD statement, and with the program's FD or DCB.
  3. If the DD statement concatenates several data sets, check each one. A different LRECL or RECFM in any of them is a likely culprit.
  4. Note when the step failed. An abend on the first read points to the attributes. An abend later in the file points to the data at that spot, or the media.
  5. Check SYSLOG or OPERLOG at the same time for IOS000I or tape drive error messages. Those point to a hardware problem rather than a program one.

How to fix it

  • Remove DCB overrides from the JCL that don't match the data set, and let OPEN take the attributes from the data set label.
  • Make the program's record description match the file, and recompile every program that uses the copybook after a layout change.
  • Before you concatenate data sets with different formats, copy them into one data set with a single format, or read them in separate steps.
  • If the input is damaged, recreate it by rerunning the job that built it, or restore it from a backup, then rerun from the failed step.
  • For a hardware error, give operations the unit, volume and time from IEC020I. Move the data to another volume or tape before you rerun.
  • In assembler, code a SYNAD routine so an I/O error is reported with detail instead of ending in a bare abend.

What it looks like

IEC020I 001-4,PAYRUN01,STEP020,TRANSIN,0A31,PRD102,PROD.PAYROLL.TRANS
IEC020I DCB EROPT=ABE OR AN INVALID CODE, AND/OR NO SYNAD EXIT SPECIFIED
IEA995I SYMPTOM DUMP OUTPUT
  SYSTEM COMPLETION CODE=001  REASON CODE=00000004
IEF450I PAYRUN01 STEP020 - ABEND=S001 U0000 REASON=00000004

Questions

Is S001 a hardware problem?

Usually not. Most S001 abends come from record attributes that don't match the data, such as a wrong LRECL override in the JCL. Check the system log for hardware error messages before you decide the disk or tape is bad.

Why does S001 happen on the first record?

Because every block is wrong. When the record length or format the job uses doesn't match the data set, the very first read fails. A failure deep into the file points more to bad data or damaged media at that spot.