Backup or recovery step reports success but data is stale

When Backup or recovery step reports success but data is stale, 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

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 Backup or recovery step reports success but data is stale?
• 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.