S337: End of data set reached with no EODAD

What it means

When a program reads a sequential data set with QSAM or BSAM, the system needs to know what to do when the data runs out. The program tells it with the EODAD parameter in its DCB or DCBE. EODAD names a routine that gets control at end of data, so the program can close the file and finish its work.

If the end of the data set is reached and no EODAD routine was given, the system has nowhere to send control. It issues message IEC024I and ends the step with system completion code 337. Return code 04 is the one you'll see for this case. Return code 08 is the same problem on a DD DUMMY data set, which reaches end of data on the first read. IEC024I in IBM's MVS System Messages lists the codes for your release.

High-level languages normally handle end of file themselves. A COBOL READ with AT END, for example, ends with file status 10 rather than an abend. So S337 mostly comes from assembler code, or from a product that reads files with its own DCBs. It can also appear when a program reads a short or empty file and reaches the end before it has set up its EODAD.

Common causes

• An assembler program issues GET or READ without coding EODAD in its DCB or DCBE.
• The program fills in EODAD at run time, but reads a record before it does so. An empty or damaged input file then reaches the end before the routine is in place. IBM fixed this exact problem in the z/OS SMTP server.
• The DCB is built or changed dynamically, and the EODAD address was cleared or overwritten.
• An input file is empty or shorter than the program assumes, for example the output of a failed earlier step, and the program was never written to reach the end (337-04). If the DD was changed to DUMMY, the same mistake gives 337-08.

How to find the problem

1. Find IEC024I in the job log. It has the form IEC024I 337-rc,mod,jobname,stepname,ddname,dev,volser,dsname. The DD name tells you which file ran out.
2. Check how many records that file holds. An empty or short file, or a DD DUMMY (337-08), is often what exposed the missing EODAD.
3. In the program, find the DCB or DCBE for that DD. Check that EODAD is coded, and if it's set at run time, that this happens before the first read.
4. If a product did the read, search its support site for the abend and the program or function that failed.

How to fix it

• Add an EODAD routine to the DCB or DCBE, and have it close the file and end the processing normally.
• Set EODAD before the first GET or READ when the program fills it in at run time.
• If a file arrived empty or truncated by mistake, fix the input and rerun the step.
• If the abend comes from a product, apply the vendor's or IBM's fix.

Technical reviewer: Albert Joseph, WND Software.

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