Batch Job Scheduling and the Enterprise Scheduler Layer

Understand how z/OS's JES subsystem manages job execution alongside how enterprise schedulers layer higher-level dependency and calendar control on top.

Two layers control batch. JES manages execution on the system; a scheduler decides what should run and when.

JES is the kitchen's ticket rail and cooking stations — it manages which order gets cooked next based on which station is free and how tickets are prioritized; the enterprise scheduler is the floor manager deciding which tickets even get sent back to the kitchen in the first place, based on whether the customer's earlier course has actually been cleared and it's genuinely time for the next one.

Key Concepts

JES queues, initiates and spools. When a job is submitted — by a person, a scheduler or another job — JES2 or JES3 puts it on a queue, assigns it to an initiator, runs it, and holds its output on the spool.

    submitted -> input queue -> initiator -> execution -> output queue

Job classes and initiators are the throttle. An initiator runs one job at a time. A system with ten initiators runs ten jobs concurrently, whatever is queued behind them.

    class A   short jobs, 6 initiators
    class L   long-running jobs, 2 initiators
    class P   production, reserved initiators

That reservation is how a flood of test jobs is prevented from starving production: they compete for different initiators.

Which explains a common symptom. "My job has not started" usually means every initiator for its class is busy, not that anything is broken. The job is queued and healthy.

SDSF is how you look.

    DA   active jobs
    ST   status of all jobs
    I    input queue -- waiting for an initiator
    O    output queue
    H    held output

Opening a job in SDSF shows its JCL, the messages, and the output of each step — which is where a failed job is diagnosed.

The scheduler sits above all of this. JES runs what it is given. It knows nothing about job B needing job A to finish first, or about month-end, or about holidays.

    JES             queues and runs jobs on this system
    scheduler       decides which jobs, in what order, on what days,
                    and raises an alert when the chain slips

So an investigation has two layers. "The job did not run" is a scheduler question — was it scheduled, were its predecessors complete, was its trigger satisfied. "The job ran and did not finish" is a JES question — is it waiting for an initiator, is it active, did it abend.

Going to SDSF first for a job that was never submitted finds nothing, because there is nothing there to find. That distinction is what the scenario questions are checking.

What the interviewer is probing.1. "What does a scheduler add over submitting JCL?" Probing: the value. Stalls: "Timing." Moves up: dependencies, calendars, resource constraints, automatic restart handling and an audit trail of what ran when.

2. "How do you model a dependency correctly?" Probing: the engineering. Stalls: "A time offset." Moves up: as a predecessor relationship or dataset trigger — a time gap is a guess that fails the day the earlier job runs long.

3. "What is the critical path in a batch schedule?" Probing: the concept. Stalls: "The longest job." Moves up: the chain of dependent jobs that determines the finish time — shortening anything off it changes nothing.

4. "What must exist before a job goes into production?" Probing: the process. Stalls: "The JCL." Moves up: a documented restart procedure, an owner, and an agreed action on failure — otherwise a 3am failure becomes an outage.