JES holds a job unexpectedly

Troubleshooting guide for JES holds a job unexpectedly. JES and batch operations problems are about the environment around the job: queues, initiators, spool, and schedulers — not the program code.

What it means

• JES2/JES3 manage the job lifecycle: input queue, execution (initiators), output queue (spool). A job can wait at any stage.
• Initiators are the slots that run jobs per class; when all are busy, jobs wait even though the system looks idle.
• Spool holds all SYSOUT; a "missing" output is usually in the wrong class, held, or purged — not lost.

Common causes

• Job runs longer as volume grows: no code change, just more records — often a missing index or a sort spilling to disk.
• Abends only with month-end data: boundary values (more generations, bigger amounts, extra regions) that daily data never hits.
• Output missing from spool: wrong SYSOUT class, output held (HOLD=YES), or the job was purged before viewing.
• Job held unexpectedly: TYPRUN=HOLD, scheduler hold, or operator hold after a problem.
• Initiator shortage: too few initiators for the class, or long jobs hogging them while short jobs wait.
• Scheduler dependency: predecessor job delayed or failed, so this job never gets submitted.
• Return code differs between environments: different data, different load modules, or different scheduler variables.

How to diagnose

• SDSF ST panel: check the job status — INPUT, ACTIVE, OUTPUT, or HELD tells you which stage is stuck.
• SDSF DA: see initiators and what is running in each class; a full class explains the wait.
• For long runs: compare elapsed time and EXCP counts with the last good run — I/O growth points at data, CPU growth at code paths.
• For month-end-only abends: diff the month-end input profile (record counts, value ranges) against daily.
• For missing output: check ? in SDSF ST with the right prefix, and verify the SYSOUT class and HOLD status.

How to fix it

• Add initiators or rebalance classes so short jobs are not stuck behind long ones.
• Release the hold (SDSF A against the job) once the underlying issue is fixed.
• Point SYSOUT to the correct class and remove accidental HOLD=YES.
• For volume-driven slowdowns: tune the sort, add the missing index, or split the job — do not just raise the TIME parameter.
• Align scheduler calendars and dependencies across environments; test month-end volumes before month-end.

Example: JCL that behaves in every environment

Explicit CLASS, MSGCLASS, and HOLD keep output findable; TIME caps runaway loops instead of letting them burn CPU all night.

Interview tip

• Q: Users say the nightly batch "takes longer every month" but nothing changed. JES holds a job unexpectedly — your approach?
• A: Nothing changed in code, so something changed in data or environment. I compare EXCP and CPU against older runs in SMF, check whether sorts are spilling or a table lost its index as it grew, and look at initiator contention — then fix the bottleneck instead of raising TIME limits.

Prevention checklist

• Track batch elapsed times and alert on trend growth, not just failures.
• Test with month-end data volumes before month-end.
• Keep SYSOUT classes and HOLD usage standardized.
• Document scheduler dependencies so a delayed predecessor is visible, not mysterious.