Mainframe JCL and CA-7 Scheduler

Jobs that cannot run simultaneously are related through negative dependency (mutual exclusion). Both terms describe this constraint - negative dependency is the technical CA7 term, while mutually exclusive describes the logical relationship where one job running prevents the other from starting.

Negative dependency means jobs CANNOT run simultaneously - if one is running, the other must wait. It does NOT mean one must complete before the other starts. In fact, negative dependency prevents the sequential execution implied by the statement.

LEADTM (lead time) specifies how far back a job can look to check if its requirement job has completed. If B requires A with LEADTM=2 hours, B will look back 2 hours from its trigger time to verify A's completion within that window.

QTM (queue time) specifies how long a job can remain in a CA7 queue (REQ, RDY, or ACT) before being considered late. Unlike LEADTM which looks backward, QTM looks forward to set a deadline for queue processing.

In the dependency chain: A triggers B and C. C requires BOTH D and E. If only E completes (D still incomplete), C's requirements are not satisfied, so C is not triggered. Neither B nor C are affected - only their requirements state changes.

When A completes: B has no requirements, so B becomes active immediately. C requires D and E - D is active, E is active, but C's requirement is for D and E to COMPLETE, not be active. Since D and E are not complete, C moves to REQ queue.

If B requires A with 2-hour lead time and B triggers at 8:00 AM, B looks back 2 hours to check A's completion. A must have completed BY 6:00 AM, but could have completed at any earlier time (5:00 AM, 4:00 AM, etc.). A's runtime is unknown - only completion time matters for LEADTM.

If B triggers at 8:00 AM with 2-hour lead time on A, A must have COMPLETED by 6:00 AM. Since A's runtime is unspecified (could be 1 minute, 1 hour, etc.), A could have started at any time before completion. The EARLIEST A could have started is just before 6:00 AM (e.g., 6:01 AM would be too late since A must complete BY 6:00 AM, meaning A could start at 5:59 AM if runtime is 1 minute).

When A completes successfully, B becomes active since all its requirements are met. C requires both D and E; with D complete but E abended, C cannot execute and enters the requirements queue awaiting E's resolution. This is standard workflow dependency resolution.

In JCL, symbolic parameters are placeholders that can be substituted with actual values at runtime. These parameters are always preceded by an ampersand (&) to distinguish them from literal values. For example, &REGION or &SPACE are common symbolic parameters used in JCL statements.

The PRTY parameter in JCL is used to modify the execution priority of a job. A higher priority value indicates that the job should be scheduled before jobs with lower priority values. PRIQTY relates to data set allocation, JOBCLASS defines job categories, and RUNTIME sets time limits - none of these directly modify execution priority.

The REGION keyword in JCL specifies the amount of virtual memory (region) required for execution. It can be specified at both the step level (using REGION in the EXEC statement) and the job level (using REGION in the JOB statement), making option C the correct choice that encompasses both uses.

In JCL, the RESTART parameter is used to restart a stopped job from a specific step. When a job abnormally terminates, RESTART allows you to specify which step should be re-executed, avoiding repetition of completed work. The CHECKPNT keyword relates to checkpoint functionality but RESTART is the actual restart mechanism.

The PARM keyword in the EXEC statement passes values from the JCL job stream to the executable program. This allows runtime parameters to be supplied to programs without modifying the program itself. PGM specifies the program name, and VALUE is not a standard JCL keyword for this purpose.

The PROC statement marks the beginning of a procedure in JCL and allows you to assign default values to symbolic parameters defined within that procedure. Procedures can be in-stream (defined inline) or cataloged (stored in a library), and PROC serves as the entry point for both cases.