The conditional job control (CJC) function only allows the user to carry out actions under certain conditions. It can issue ’conditional’ statements to the operating system which are only executed if or when the specified conditions are met.
The conditional job control function is based on job variables which are linked via operators to a condition. The condition may be ’met’ or ’not met’ depending on the values of the specified job variables. The action defined by a conditional statement is executed when the condition is fulfilled, e.g. when the value of a job variable has changed accordingly. The following actions can be defined as conditional statements:
Initial evaluation of the condition and immediate branching to ’condition met’. If ’condition not met’ applies, job processing continues with the next command (SKIP-COMMANDS)
Transition to a wait state until the specified condition is met or a predefined period of time has elapsed, if the condition was not already fulfilled on the initial evaluation (WAIT-EVENT)
Interruption of a job/program to execute previously specified actions when the specified condition is fulfilled (frequency can be defined) or a predefined interval of time has elapsed (ADD-CJC-ACTION).
These functions can be used locally on a single processor and are also available in the MSCF network. In particular, events on one processor can cause the execution of correspondingly defined actions on the same processor and/or on other processors in the network.
This provides a network-wide communication and control function applicable to all jobs that is based on job variables. The job variables act as shared accessible information carriers to the processors on which the jobs concerned are running.
See the "Job Variables" manual [9 (Related publications)].
Application example
Figure 11: Job checking (see next page for key to figure)
The figure 11 illustrates job dependencies defined on processors PROCESSOR1 and PROCESSOR2 as applicable to all the processors. PROCESSOR1 and PROCESSOR2 are linked via an MSCF connection.
Key
(1) | The job on PROCESSOR1 waits until the job on PROCESSOR2 has set job variable :A:JV1 to the same value as job variable :B:JV2. |
(2) | The job on PROCESSOR2 now indicates to the system that it wants to be informed of the event up to 10 times at intervals of 600 seconds (= 10 minutes) Job variable :C:JV3 has the value C’READY’and interrupted from starting the ENTER file JOB on the SPVS. |
(3) | The job on PROCESSOR1 delivers these events in a loop which will keep rotating until the job on PROCESSOR2 has delivered the information: Job variable :C:JV3 does not have a value corresponding to C’READY’ |
(4) | Job variable :C:JV3 is set to C'END'. |
| (2) + (3) | The condition Job variable :C:JV3 has the value C’READY’ |
Behavior on reconfiguration
If statements of the conditional job control refer to catalogs imported to job variables, the statements still remain effective when such a catalog is identified as ’temporarily not accessible’ while waiting for events. If the specified time has not elapsed and the event has not occurred when the catalog is available again, the statements are processed normally.
If an awaited event occurs while a connection is down, the waiting processor cannot be informed. Therefore the message CJC0004 is issued at the shared pubset master and the event is deactivated entirely. The processor will not be informed, even after the connection is reestablished and the event has occurred again. After the waiting time has lapsed processing continues on the waiting processor as though the event had never occurred.
If a job variable is not available while it is waiting for an event, the processing of such statements is terminated with a message and the system branches to the next SET-JOB-STEP command or to the end.