z/OS Troubleshooting
Dump is not produced after abend
When Dump is not produced after abend, the job log shows every message in time order — but only the FIRST error is the cause. Everything after it is usually fallout.
What it means
- The first non-zero return code or the first IEF450I message marks where the real failure happened; later abends are often consequences.
- A missing SYSOUT, a held job, or confusing SYSLOG timestamps can hide that first failure completely.
- Multiple abends in one job almost always trace back to a single root event recorded in the earliest dump or LOGREC entry.
Common causes
- A COND parameter skipped the failing step, so the visible abend appears in a later step.
- SYSOUT went to a held output class or was purged before anyone looked at it.
- The job is still sitting held in the JES queue, so its output is not released yet.
- SYSLOG timestamps from different LPARs make the timeline look out of order.
- No dump was produced because the step had no SYSUDUMP or SYSABEND DD statement.
- An earlier step ended with RC=12 on bad input, and a later step abended on the bad data it received.
How to diagnose
- In SDSF, use ST to find the job, then ? (question mark) next to it to open JESMSGLG, JESJCL and JESYSMSG.
- Search JESMSGLG for IEF450I (step abend) and read upward — the first one is the starting point.
- Check every step return code in JESYSMSG; the first non-zero RC is where diagnosis begins.
- Open the SDSF LOG panel around the failure time and match system messages to the job log timestamps.
- If no dump exists, note it: the fix starts with adding a SYSUDUMP DD so the next failure leaves evidence.
- For recurring abends, check LOGREC (via EREP) — it records the hardware and software event history.
How to fix it
- Restart diagnosis from the FIRST failing step, not from the last abend message.
- Add //SYSUDUMP DD SYSOUT=* to the failing step so the next failure produces a dump.
- Release held output first (SDSF O panel, then S next to the job) before declaring SYSOUT missing.
- Normalize timestamps to one timezone before building the incident timeline.
Example: Hunting the first failure in SDSF
SDSF primary commands:
ST - job status panel
PREFIX jobname* - filter to your jobs
? - list JESMSGLG / JESJCL / JESYSMSG
S - browse the data set
LOG - system log around the failure time
Work backward from the first IEF450I or non-zero return code, never forward from the last message.
Interview tip
- Q: A job abends with S0C7 in step 5, but you suspect the real problem is earlier. How do you prove it for Dump is not produced after abend?
- A: I open JESMSGLG in SDSF and find the first step with a non-zero return code or the first IEF450I message. If step 2 ended RC=12 on a file error, the S0C7 in step 5 is just fallout from bad input data — so I fix step 2 input, not the step 5 program.
Prevention checklist
- Give every batch step a //SYSUDUMP DD SYSOUT=* so failures always leave evidence.
- Use explicit COND or IF/THEN/ELSE logic so a failing step stops the job instead of cascading.
- Document which step is the canary for input-data problems in the runbook.
