Batch Operations Troubleshooting
Daily batch misses its SLA
Daily batch misses its SLA - batch has a contract: finish the right work, in the right order, before the SLA. Anything else is an incident.
What it means
- An SLA miss is a business event first and a technical event second - finance and operations feel it before you do.
- Month-end and year-end are different workloads, not just bigger ones: more data, more contention, tighter windows.
- Restart design decides whether a failure costs you minutes or a full re-run.
Common causes
- Input volume growth with no matching increase in the batch window or resources.
- A new step added to the critical path, or a dependency starting late.
- Lock contention or dataset enqueue waits serializing steps that used to run in parallel.
- Sort or I/O-bound step spilling to disk after a volume or key-distribution change.
- Runtime or utility upgrade changing performance characteristics.
- Data conversion or migration changing record sizes, sort order, or collating sequence.
How to diagnose
- Compare this run step by step against the last good run - elapsed time per step pinpoints the slowdown.
- Check SDSF for actual start and end times and return codes to find which step moved.
- Look for enqueue waits from dataset contention and lock waits in the step that slowed.
- Review SMF data for CPU, I/O, and paging on the slowed step versus its baseline.
- Confirm no unplanned change landed: deployments, data growth, or schedule shifts.
How to fix it
- Move the slow step off the critical path, or parallelize it if dependencies allow.
- Tune the I/O-bound step: larger sort work datasets, correct BLOCKSIZE, key order matching the access pattern.
- Resolve the contention: stagger the competing job or change DISP or SHAREOPTIONS.
- Restart from the last checkpoint instead of re-running from the top.
- If a migration changed sort order or dropped leading zeros, fix the conversion and re-validate outputs.
Example: Find the slow step fast
/* In SDSF (ST panel), line up two runs step by step: */
/* 1. Note start/end times per step for the slow run */
/* 2. Note start/end times per step for a good run */
/* 3. The step with the biggest delta is the suspect */
//SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,(50,20))
Elapsed-time-per-step comparison finds the culprit in minutes; guessing takes hours.
Interview tip
- Q: Month-end batch missed its SLA for the first time in a year. Daily batch misses its SLA - how do you start?
- A: I compare elapsed time per step against the last good month-end to find exactly which step slowed down, then check what changed around it: data volume, a new deployment, or contention from another job. Month-end is its own workload, so I never compare it against a daily run.
Prevention checklist
- Track per-step elapsed times every run so slowdowns show up as trends, not surprises.
- Rehearse month-end and year-end on production-like volumes before the real date.
- Design every long job with checkpoint and restart so a failure costs minutes, not a re-run.
- Review the batch schedule quarterly; windows shrink as the business grows.
