MainframeMaster

JCL Tutorial

JCL Job Dependencies

Progress0 of 0 lessons

What are Job Dependencies?

Job dependencies are relationships between separate JCL jobs where the execution of one job depends on the status or output of another job. Unlike step dependencies that occur within a single job, job dependencies manage relationships between independent jobs that may run at different times or even on different systems.

Job dependencies are essential for creating reliable batch processing systems, where complex business processes require multiple jobs to be executed in a specific sequence, often with conditions determining whether dependent jobs should run.

Types of Job Dependencies

Dependency TypeDescriptionCommon Use Cases
Successful CompletionJob B runs only if Job A completes successfully (RC = 0)Sequential processing steps like extract → transform → load
Completion (Any Status)Job B runs after Job A completes, regardless of its success or failureCleanup or notification jobs that must run regardless of main job outcome
ConditionalJob B runs only if Job A completes with a specific return code or rangeError recovery jobs that run only when the main job fails with specific errors
Multiple PredecessorsJob C runs only after Jobs A and B have both completed successfullyConsolidation jobs that merge outputs from multiple source jobs
Time-BasedJob B runs at a specific time, but only if Job A has completedEnd-of-day processing that waits for daily transaction jobs
Resource-BasedJob B runs only when a specific dataset or resource is availableJobs that process files received from external systems

Implementing Job Dependencies

There are several ways to implement job dependencies in a mainframe environment. The method you choose depends on your available tools, your organization's standards, and the complexity of your dependency requirements.

1. Using a Job Scheduler

Enterprise job schedulers like CA-7, Control-M, TWS (IBM Workload Scheduler), or Zeke provide robust facilities for defining and managing job dependencies.

CA-7 Example

CA-7 uses a database to define job dependencies. Here's a simplified definition:

text
1
2
3
4
5
JOBDEF JOB=DAILY01,DAYS=(ALL),LEAD=0 REQ JOB=DAILY01,DAYS=(ALL),LEAD=0 REQ JOB=DAILY02,PRED=(DAILY01(0)),DAYS=(ALL),LEAD=0 REQ JOB=DAILY03,PRED=(DAILY01(0),DAILY02(0)),DAYS=(ALL),LEAD=0 REQ JOB=DAILYFAIL,PRED=(DAILY02(>0)),DAYS=(ALL),LEAD=0

This defines DAILY01 as the first job, DAILY02 runs when DAILY01 completes with RC=0, DAILY03 runs when both DAILY01 and DAILY02 complete with RC=0, and DAILYFAIL runs when DAILY02 has a non-zero return code.

2. Using Dataset Dispositions

Jobs can be made dependent on the successful creation and availability of datasets. This approach leverages the operating system's dataset protection mechanisms.

Job A creates a dataset that Job B needs:

jcl
1
2
3
4
5
6
7
//JOBA JOB (ACCT),'CREATE DATASET',CLASS=A //STEP1 EXEC PGM=PROGRAM1 //OUTPUT DD DSN=MY.CRITICAL.DATA,DISP=(NEW,CATLG,DELETE) ... //JOBB JOB (ACCT),'USE DATASET',CLASS=A //STEP1 EXEC PGM=PROGRAM2 //INPUT DD DSN=MY.CRITICAL.DATA,DISP=SHR

If JOBA fails to create MY.CRITICAL.DATA, JOBB will fail when it tries to access it. This creates an implicit dependency.

3. Using Trigger Datasets

A trigger dataset is a special file created by one job to signal completion, which another job checks for before starting.

Job A creates a trigger dataset:

jcl
1
2
3
4
//JOBA JOB (ACCT),'CREATE TRIGGER',CLASS=A //STEP1 EXEC PGM=IEFBR14 //TRIGGER DD DSN=TRIGGER.JOBA.COMPLETE,DISP=(NEW,CATLG), // SPACE=(TRK,1)

Job B checks for the trigger dataset:

jcl
1
2
3
4
5
6
7
8
9
10
11
12
13
//JOBB JOB (ACCT),'CHECK TRIGGER',CLASS=A //CHKTRG EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * IF LISTCAT ENT('TRIGGER.JOBA.COMPLETE') THEN DO SET MAXCC=0 END ELSE DO SET MAXCC=8 /* Trigger not found, signal error */ END /* //STEP1 EXEC PGM=PROGRAM2,COND=(0,NE,CHKTRG) //... DD statements ...

4. Using GDG (Generation Data Group) Datasets

GDGs can be used to manage dependencies based on dataset generations.

Job A creates a new generation:

jcl
1
2
3
4
//JOBA JOB (ACCT),'CREATE GDG',CLASS=A //STEP1 EXEC PGM=PROGRAM1 //OUTPUT DD DSN=MY.GDG.DATASET(+1),DISP=(NEW,CATLG,DELETE) ...

Job B uses the latest generation:

jcl
1
2
3
4
//JOBB JOB (ACCT),'USE GDG',CLASS=A //STEP1 EXEC PGM=PROGRAM2 //INPUT DD DSN=MY.GDG.DATASET(0),DISP=SHR ...

5. Using TYPRUN=HOLD and Operator Release

Jobs can be submitted but held until an operator releases them, often based on the completion of other jobs.

jcl
1
2
3
//JOBB JOB (ACCT),'HELD JOB',CLASS=A,TYPRUN=HOLD //STEP1 EXEC PGM=PROGRAM2 //... DD statements ...

Job B is submitted but remains in HOLD status. After Job A completes, an operator can issue a command to release Job B:

text
1
$A JOBB

Best Practices for Job Dependencies

  • Use a job scheduler: For complex dependencies, a dedicated job scheduler provides better management, visibility, and reporting.
  • Document your dependencies: Create and maintain flow diagrams showing job dependencies to help with troubleshooting and knowledge transfer.
  • Consider restart implications: When designing job dependencies, consider how the system will handle job restarts and recovery scenarios.
  • Keep dependency logic separate: Try to separate business logic from dependency control logic where possible.
  • Implement consistent notifications: Ensure that dependency failures generate appropriate notifications to operations staff.
  • Validate return codes: Don't assume that a zero return code always means success. Validate that jobs produced the expected outputs.
  • Plan for failures: Implement explicit error handling jobs for critical dependency chains.

Complex Dependency Example

This example shows a complex batch processing flow with multiple dependencies:

End-of-Day Processing Flow

EXTRACTPROCESSREPORTARCHIVE
↓ FAILNOTIFY

Dependencies in a job scheduler

text
1
2
3
4
5
JOBDEF JOB=EXTRACT,TIME=20:00,DAYS=(MO-FR) REQ JOB=PROCESS,PRED=(EXTRACT(0)),DAYS=(MO-FR) REQ JOB=REPORT,PRED=(PROCESS(0)),DAYS=(MO-FR) REQ JOB=ARCHIVE,PRED=(REPORT(0)),DAYS=(MO-FR) REQ JOB=NOTIFY,PRED=(PROCESS(>0)),DAYS=(MO-FR)

Job Dependencies Exercises

Exercise 1: Basic Job Dependency

Design a job dependency solution where JOBB should run only if JOBA completes successfully. Implement this using dataset disposition.

Exercise 2: Trigger Dataset

Create JCL for two jobs where the second job uses IDCAMS to check for the existence of a trigger dataset before proceeding.

Exercise 3: Complex Dependencies

Design a job scheduler dependency setup for a scenario where Job D depends on both Job A and Job B completing successfully, while Job C depends only on Job A. Job E runs if either Job C or Job D fails.

Frequently Asked Questions

Test Your Knowledge

1. Which of the following is NOT a common method for implementing job dependencies?

  • Using a job scheduler like CA-7 or Control-M
  • Using datasets with specific dispositions
  • Using GDG generations
  • Using JOBLIB statements

2. What is a trigger dataset?

  • A dataset that contains JCL code
  • A dataset that, when created, signals that a job has completed a specific task
  • A dataset that is passed between job steps
  • A dataset that contains job scheduler settings

3. Which statement about job dependencies is FALSE?

  • Job dependencies can be implemented across different LPARs
  • Job dependencies always require a job scheduler
  • Job dependencies can be time-based
  • Job dependencies can use cataloged datasets for signaling

4. What is the purpose of TYPRUN=HOLD in job dependencies?

  • To automatically delete a job after execution
  • To submit a job but keep it in hold status until manually released
  • To retry a job automatically if it fails
  • To increase the execution priority of a job

5. Which of these is a benefit of using a job scheduler for dependencies?

  • Simplifies the JCL by removing dependency logic
  • Guarantees faster job execution
  • Eliminates the need for restart procedures
  • Requires less disk space for execution