How a z/OS shadow job is bound with a remote job instance

If the remote engine is an HCL Workload Automation for Z 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 input arrival.
  • 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 EQQHT62E is logged in the MLOG.
The following sections describe the scenarios that can occur when binding a z/OS shadow job having:
  • Input arrival (IA): 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 input arrival of the shadow job and JS2 occurrences exist.
Figure 1. Instance to be bound if the shadow job input arrival is included in the CP interval

The graphic shows the instance to be bound if the shadow job input arrival is included in the current plan interval

Instance to be bound if the shadow job input arrival is included in the CP interval shows, highlighted in bold, the JS2 instance that more closely precedes the shadow job input arrival. This instance is selected for the bind because the input arrival 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 input arrival 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 information necessary to identify the OP2 instance in the remote engine plan
  • The current status of that OP2 instance
is sent back to the HCL Workload Automation for Z controller, 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 to the HCL Workload Automation for Z controller, 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 to the HCL Workload Automation for Z controller. The shadow job instance is marked as completed. Its successors can start.
Scenario 2: The current plan interval contains the shadow job input arrival, the JS2 instance that most closely precedes the shadow job input arrival exist in the LTP but it was canceled from the CP.
Figure 2. Instance to be bound if the instance that most closely precedes the shadow job input arrival exist in the LTP but it was canceled from the CP

The graphic shows the instance to be bound if the instance that most closely precedes the shadow job input arrival exist in the long-term plan but it was canceled from the current plan

Instance to be bound if the instance that most closely precedes the shadow job input arrival exist in the LTP but it was canceled from the CP 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 is established and a notification containing:
  • The information necessary to identify the OP2 instance in the remote engine plan
  • The current status of that OP2 instance
is sent back to the HCL Workload Automation for Z controller, the shadow job instance is updated with the remote job information, and its status is updated accordingly.
Scenario 3: The CP interval contains the input arrival of the shadow job but no JS2 instance exists
Figure 3. The input arrival of the shadow job is included in the CP but no instance to bind exists

The graphic shows when the input arrival of the shadow job is included in the current plan but no instance to bind exists

The input arrival of the shadow job is included in the CP but no instance to bind exists shows that a JS2 instance that closely precedes the shadow job input arrival does not exist.

The bind fails. A notification informing that the bind failed is sent back to the HCL Workload Automation for Z controller, 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 input arrival of the shadow job 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

The instance to be bound exists but it is not yet included in the production plan 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 to the HCL Workload Automation for Z controller and the status of the shadow job is set to READY-The bind was established.

Scenario 5: The LTP interval still does not contain the input arrival of the shadow job.
Figure 5. The LTP interval still does not contain the input arrival of the shadow job

The graphic shows when the long-term plan interval still does not contain the input arrival of the shadow job

The LTP interval still does not contain the input arrival of the shadow job shows that no JS2 instance can be associated with the shadow job because, until the LTP includes the shadow job input arrival, closer preceding JS2 instances can still be added.

In this case, the bind request is put on hold on the remote engine until the LTP is extended to include the shadow job input arrival. Until then the status of the shadow job remains "READY-Waiting for bind result".