HCL Workload Automation, Version 9.4

How a z/OS shadow job is bound

If the remote engine is an IBM Workload Scheduler for z/OS controller, the search for the remote instance to bind is done as follows:
  • First, the instance is searched in the Long Term Plan (LTP) in the part of the bind interval that follows the Current Plan (CP) end time and precedes the shadow job scheduled time.
  • If no instance is found, the instance is searched in the CP in the part of the bind interval that precedes the current plan end.
Note: If the remote controller receives a bind request with a client notify URI that is not defined among the HTTP destinations, the bind request is discarded and the message EQQHT62W is logged in the MLOG.
The following sections describe the scenarios that can occur when binding a z/OS shadow job having:
  • Scheduled time: 18:00
  • Remote job information:
    • Application ID: JS2
    • Operation number: OP2
In the figures:
  • The white box indicates the time interval covered by the LTP.
  • The light grey box indicates the time interval covered by the CP.
  • The dark grey box indicates the interval in the remote engine plan during which the job instance to bind must be searched.
  • The JS2 occurrence highlighted in bold is the instance selected for the bind.
Scenario 1: The CP interval contains the shadow job scheduled time and JS2 occurrences exist.
Figure 1. Instance to be bound if the shadow job scheduled time is included in the CP interval
The graphic shows the instance to be bound if the shadow job scheduled time is included in the current plan interval
Figure 1shows, highlighted in bold, the JS2 instance that more closely precedes the shadow job scheduled time. This instance is selected for the bind because the scheduled time is contained in the CP. The shadow job and the remote job instance are associated. If, at a later time, a new instance of JS2 that closest precedes the shadow job scheduled time is submitted ad hoc in the remote engine plan, the match with the JS2 instance selected for the bind is not modified.
At this point, one of the following situations can occur:
The selected JS2 instance contains OP2.
The bind with OP2 belonging to JS2 is established and a notification containing:
  • The remote job information identifying OP2 instance in the remote engine plan
  • The current status of that OP2 instance
is sent back, the shadow job instance is updated with the remote job information, and its status is updated accordingly.
The selected JS2 instance no longer contains OP2 because either it was deleted and a daily plan removed it from the CP, or it was never contained in JS2.
The bind fails. A notification informing that the bind failed is sent back, and the shadow job status is updated according to what you set in the Complete if bind fails field.
The selected JS2 instance contains OP2 that was deleted but not yet removed from the CP.
The bind is established and a notification informing about the successful execution status is sent back. The shadow job instance is marked as SUCC. Its successors can start.
Scenario 2: The current plan interval contains the shadow job scheduled time, the JS2 instance that most closely precedes the shadow job scheduled time exists in the LTP but was canceled from the CP.
Figure 2. Instance to be bound if the instance that most closely precedes the shadow job scheduled time exists in the LTP but was canceled from the CP
The graphic shows the instance to be bound if the instance that most closely precedes the shadow job scheduled time exists in the long-term plan but it was canceled from the current plan
Figure 2 shows, highlighted in bold, the JS2 instance that is selected for the bind, because the occurrence that better matched was deleted.
The bind with OP2 belonging to JS2 is established and a notification containing:
  • The remote job information identifying the OP2 instance in the remote engine plan
  • The current status of that OP2 instance
is sent back, the shadow job instance is updated with the remote job information, and its status is updated accordingly.
Scenario 3: The CP interval contains the shadow job scheduled time but no JS2 occurrence exist.
Figure 3. The scheduled time of the shadow job is included in the CP but no instance to bind exists
The graphic shows when the scheduled time of the shadow job is included in the current plan but no instance to bind exists
Figure 3 shows that a JS2 instance that closely precedes the shadow job scheduled time does not exist.

The bind fails. A notification informing that the bind failed is sent back, and the shadow job status is updated according to what you set in the Complete if bind fails field.

Scenario 4: The LTP interval contains the shadow job scheduled time and the CP does not yet include the closest preceding JS2 instance.
Figure 4. The instance to be bound exists but it is not yet included in the CP
The graphic shows when the instance to be bound exists but it is not yet included in the current plan
Figure 4 shows the JS2 instance that can be associated with the shadow job, even though the job JOB2 is not yet in the CP.

A notification informing that the bind is established is sent back and the status of the shadow job is set to BOUND.

Scenario 5: The LTP interval still does not contain the shadow job scheduled time.
Figure 5. The LTP interval still does not contain the shadow job scheduled time
The graphic shows when the long-term plan interval still does not contain the shadow job scheduled time
Figure 5 shows that no JS2 instance can be associated with the shadow job because, until the LTP includes the shadow job scheduled time, closer preceding JS2 instances can still be added.

In this case, the bind request is put in hold until the LTP is extended to include the shadow job scheduled time. Until then the status of the shadow job remains WAIT.