Monday, July 6, 2026

What happens when one job creates a GDG (+1) while another job tries to use the current generation (0)?

 When a job starts, the initiator places locks on all datasets referenced by the job:

->Exclusive lock is taken if any step references the dataset with DISP=NEW, MOD, or OLD.
->Shared lock is taken if all references use DISP=SHR.

The lock remains in place until the last step that references the dataset completes.

For GDGs, locking is applied at the GDG base level:

->If any step creates a new generation +1 +2, + 3 etc, the GDG base receives an exclusive lock.
->If all referenced generations use DISP=SHR, the GDG base receives a shared lock.

This lock is released only after the last step referencing that GDG completes, ensuring data integrity.

Example

Consider TESTJOBA with 20 steps:

->Step 5 creates GDG(+1).
->Step 10 reads GDG(0).

Because the job creates a new generation, TESTJOBA acquires an exclusive lock on the GDG base before execution begins. The lock remains until Step 10 completes (the last step referencing that GDG).


If TESTJOBB is submitted while TESTJOBA is running and its first step tries to read GDG(0) from the same GDG, it cannot obtain a share lock on the Base GDG. As a result, TESTJOBB waits in dataset contention and starts only after TESTJOBA releases the GDG lock at the end of Step 10.

 

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.