DB2 Job Failures

DB2 batch jobs fail for a small set of repeat reasons: bad return codes from utilities, abends, missing data sets, and locked resources. This page shows how to read a failure and the fixes that resolve most of them.

Return codes from DSNUTILB

• RC 0 means the utility completed successfully.
• RC 4 is a warning - the utility finished but something needs attention, like rows written to SYSDISC.
• RC 8 means the utility failed - read the SYSPRINT messages to find the DSNU error.
• An abend such as S04E means DB2 itself detected a severe error - check the dump and the messages before it.
• Set COND parameters on later steps so a failed utility stops the job instead of running follow-on steps on bad data.

Reading the failure

• SYSPRINT is the first place to look - every utility writes its progress and error messages there.
• DSNU messages carry the phase and the reason; the message text usually names the exact cause.
• Check the job log for JCL errors, missing data sets (S213, S413) and space abends (SB37, SE37).
• Note the utility phase at failure - restart continues from that phase with the same utility ID.
• Keep the full output; production auditors and DBAs will ask for it.

Common failure reasons

• Sort work data sets (SYSUT1, SORTOUT) running out of space on big LOAD or REORG jobs.
• A missing or misspelled DD name that does not match the control statement.
• A duplicate utility ID colliding with a still-active utility.
• -904 because the table space is in a pending status or held by another job.
• Authorization failures (-551) when the batch ID lacks the needed privilege.
• Input data not matching the field specification, filling SYSDISC and raising RC 4 or 8.

Example of cleaning up a failed utility before rerunning it:-

Issue this DB2 command to terminate a stuck or failed utility. After terminating, you can resubmit the job cleanly with the same utility ID and control statement.