S722: Output limit exceeded

What it means

Output a job writes to SYSOUT goes to the JES spool before anyone prints or views it. Every job on the system shares that spool, so installations cap how much one job can write. JES2 counts the lines each job produces. Your site sets a default, and a job can set its own with the LINES parameter on the JOB statement, given in thousands of lines. When a job passes its limit, JES2 either warns the operator and lets the job carry on, or cancels it, with or without a dump. LINES or the site default decides which. A cancelled job ends with system completion code 722.

A single SYSOUT DD statement can also have its own cap, set with OUTLIM as a number of records. When that DD reaches its limit, the step ends with S722 as well, unless an installation exit allows more.

Before the abend you often see $HASP375 messages telling the operator the job has passed its estimate.

Common causes

• A loop that writes a DISPLAY or a report line every time round.
• Debugging DISPLAY statements or a trace left in a program, which now runs against full production volumes.
• An error path that writes a message for every record. A file with the wrong layout can make a program reject and report every single record.
• A large report written to SYSOUT instead of a data set, and the data has grown past the limit.
• A LINES or OUTLIM value copied from a smaller job, or a lower default for the job class.
• Output from earlier steps. JES2 counts lines for the whole job, so a quiet step can tip a busy job over the limit.

How to find the problem

1. Open the job in SDSF, or the spool viewer your site uses, and list its output data sets. The record counts show which DD produced the bulk of the output.
2. Go to the end of the biggest data set. If the same lines repeat over and over, you have a loop, and the text tells you which part of the program wrote it.
3. Look for $HASP375 messages in the job log or system log. Their times show when the job passed its estimate and how fast the output grew.
4. Check the JOB statement for LINES and the SYSOUT DD statements for OUTLIM. Ask operations what the default is for the job class.
5. Compare the output size with a normal run of the same job.

How to fix it

• Fix the loop, or change the error path to count bad records and print a summary instead of one line each.
• Remove debugging DISPLAY statements, or put them behind a switch that is off in production.
• Write large reports to a data set, or to a SYSOUT class your site sets aside for big output.
• If the output is genuinely needed, raise the limit. LINES=(2000,WARNING) on the JOB statement lets the job write 2 million lines and only warns after that. For a single DD, raise OUTLIM.
• Talk to operations before asking for very large limits. The spool is shared, and a runaway job can fill it for everyone.

What it looks like

$HASP375 RPTGEN01 ESTIMATED  LINES EXCEEDED
$HASP375 RPTGEN01 ESTIMATE EXCEEDED BY 500,000 LINES
$HASP375 RPTGEN01 ESTIMATE EXCEEDED BY 1,000,000 LINES
IEF450I RPTGEN01 STEP040 - ABEND=S722 U0000 REASON=00000000
$HASP395 RPTGEN01 ENDED - ABEND=S722

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