Job Scheduling & Batch Windows
Understand job schedulers conceptually (CA-7/Control-M-style tools), how dependencies between jobs are managed, and what the "batch window" means in practice.
Introduction
You have submitted individual JCL jobs by hand throughout this unit using ISPF's SUBMIT command, and that works perfectly well for one job at a time. But a real production shop does not run one batch job a night — it runs hundreds or thousands, many of them depending on each other, all needing to fit within a limited overnight window before the business day resumes. This final lesson looks at how that coordination actually happens: job schedulers, dependencies, and the batch window.
Why Manual Submission Does Not Scale
Imagine trying to manually submit, watch, and time hundreds of interdependent jobs every single night, making sure each one only starts after the right predecessor jobs have finished successfully, at exactly the right time, with someone awake and available at 2 a.m. to react if something goes wrong. It is not merely inconvenient at that scale — it is not realistically sustainable or reliable. Production mainframe shops instead rely on dedicated job scheduling software to manage this automatically, day after day, with a level of consistency manual operation could never match.
What a Job Scheduler Does
A job scheduler is software that automates the submission and coordination of batch jobs according to predefined rules: what time (or triggering event) starts a given job, what other jobs or conditions it depends on, what should happen if it fails, and how to alert operations staff when intervention is needed. Well-known products in this space include CA-7 and Control-M, among others, and while their specific interfaces differ, they solve the same underlying problem conceptually.
Time-Based Triggering
Starting a job automatically at a defined time, such as 22:00 nightly, without anyone submitting it manually.
Event-Based Triggering
Starting a job automatically once a defined condition is met, such as a specific dataset becoming available or a prior job completing successfully.
Dependency Management
Ensuring a job does not start until every job (or condition) it depends on has actually finished successfully.
Monitoring & Alerting
Tracking every scheduled job's status in real time and notifying operations staff immediately if something fails or runs unexpectedly long.
Job Dependencies
A dependency exists whenever one job requires the successful completion of another before it can safely run — most commonly because it needs a dataset that an earlier job creates or updates. Schedulers let shops define these relationships explicitly, so the system itself enforces correct ordering rather than relying on everything simply happening to run at the right time by coincidence.
Running a job out of order against incomplete or stale data is not a minor inconvenience on a mainframe — it can mean posting interest against transaction totals that have not finished updating yet, or generating customer statements from an incomplete day's activity. Dependency management exists specifically to prevent that class of serious, hard-to-detect data error.
A Simple Dependency Chain
Returning to the end-of-day example from the previous lesson, here is how a scheduler would typically express the dependencies between those jobs, rather than relying on time alone.
JOB EXTRACT : triggered at 22:00, no predecessor requiredJOB INTEREST : requires EXTRACT = SUCCESSJOB STATEMENT : requires INTEREST = SUCCESSJOB RECONCILE : requires STATEMENT = SUCCESS AND EXTRACT = SUCCESSJOB FEED-REG : requires RECONCILE = SUCCESSClick Run to see what this code prints.
The Batch Window
The batch window is the block of time available for scheduled batch work to run — typically overnight, between the close of one business day's online activity and the start of the next. Everything the shop needs to accomplish overnight (extracts, calculations, reports, feeds, backups) has to fit inside that window, because online systems like CICS are expected to be available again by a defined time each morning.
| Concept | What It Means |
|---|---|
| Batch window opens | The point at which online activity has settled enough for batch processing to safely begin (often after end-of-day cutoff) |
| Batch window closes | The deadline by which all scheduled batch work must be finished, so online systems can resume full service |
| Window shrinkage | A recurring operational challenge as data volumes grow but the available overnight hours do not |
When the Window Gets Tight
As transaction volumes and data sizes grow year over year, a batch window that was comfortable in the past can become tight, forcing shops to actively manage how their nightly work fits. Common responses include running independent jobs in parallel rather than strictly one after another wherever dependencies allow, tuning individual jobs (and the SORT/utility steps within them) for better performance, moving some work earlier in the evening if it does not actually depend on end-of-day totals, and, increasingly, extending some processing into near-real-time so it is not all crammed into an overnight batch at all. This tension between data growth and a roughly fixed number of overnight hours is one of the most persistent operational challenges in traditional batch-heavy mainframe shops.
Common Mistakes
- Assuming time-based scheduling alone (just running everything at fixed clock times) is a safe substitute for real dependency checks — a delayed predecessor job can otherwise let a dependent job start against incomplete data.
- Underestimating how tightly a shrinking batch window can constrain new work — adding a new nightly job is not free; it has to fit within an already-constrained window.
- Treating scheduler configuration as a one-time setup rather than something that needs ongoing maintenance as jobs, dependencies, and data volumes change over time.
- Forgetting that a single failed job in a dependency chain can silently hold up every job depending on it unless monitoring and alerting are actively watched.
Best Practices
- Define dependencies based on actual completion status, not assumed clock times, wherever a scheduler supports it.
- Look for opportunities to run independent jobs in parallel rather than strictly sequentially, to make better use of a constrained batch window.
- Monitor batch window utilization over time, not just individual job success/failure, to catch a shrinking window before it becomes a crisis.
- Document why each dependency exists, not just that it exists, so future changes to the schedule can be made safely by people who did not originally design it.
Frequently Asked Questions
No. JES2/JES3 is the z/OS subsystem that actually receives, queues, and executes a submitted job. A job scheduler like CA-7 or Control-M sits above that, deciding when and in what order to submit jobs to JES in the first place, based on time triggers and dependency rules.
Properly configured schedulers automatically hold every downstream job that depends on it, preventing them from running against incomplete or stale data, and alert operations staff so the failure can be investigated and the chain resumed once resolved.
Much batch work depends on the day's online activity being complete and needs exclusive or heavy access to shared data that online systems like CICS are also using during business hours; running it during the day risks contention, inconsistent data, or degraded online performance.
As transaction and data volumes grow over time, the amount of batch work that needs to fit into the same fixed overnight hours grows too, while the actual number of available hours generally does not — a persistent operational pressure that shops manage through parallelization, tuning, and rescheduling.
Key Takeaways
- Job schedulers (such as CA-7 or Control-M) automate the submission and coordination of large numbers of batch jobs, far beyond what manual submission could reliably handle.
- Dependencies ensure a job only runs after the jobs (or conditions) it actually relies on have completed successfully, not just after a fixed clock time.
- The batch window is the limited block of time available for overnight batch work, bounded by when online activity settles and when it must resume.
- Growing data volumes put ongoing pressure on batch windows, addressed through parallelization, performance tuning, and rescheduling.
- A single failed job in a dependency chain can hold up every downstream job, making monitoring and alerting essential.
Summary
Job scheduling and batch windows are how mainframe shops turn hundreds of individually simple JCL jobs into a coordinated, reliable, unattended nightly operation — the operational layer built on top of everything you have learned about JCL, COBOL, and batch processing in this unit. That completes this unit on JCL and batch systems. In the next lesson, you will move into real-time territory for the first time in this course, with an introduction to CICS, the transaction processing subsystem that keeps mainframe applications responding instantly, all day, every day.