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

If the remote engine is a Z controller, the search for the remote job instance to bind depends on the matching criteria that you specified:
Closest preceding
The matching predecessor is the one with the nearest preceding input arrival time. This is the default.
Same scheduled date
The matching predecessor is the one with the nearest input arrival time within the same day (starting at 00.00 and ending at 23.59) of the operation (occurrence) under consideration.

A matching predecessor is first searched before the IA time of the operation. Then, if not found, it is searched after the IA time of the operation.

Within a relative interval
The matching predecessor is the one with the closest input arrival time within the interval specified. The interval boundaries are calculated using an offset expressed in hours and minutes before or after the IA time of the successor operation. The interval can be timed entirely before, entirely after, or across the IA time of the successor operation.

When the interval is across the IA time, a matching predecessor is first searched before the IA time of the successor operation. Then, if not found, it is searched after the IA time of the successor operation.

Within an absolute interval
The matching predecessor is the one with the closest input arrival time within the specified interval. The interval boundaries are specified by a time and a number of days before or after the IA time of the successor operation. The interval can be timed entirely before, entirely after, or across the IA time of the successor operation.

When the interval is across the IA time, a matching predecessor is first searched before the IA time. Then, if not found, it is searched after the IA time of the operation.

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.

Examples of bind process for a z/OS shadow job with resolution criteria Closest preceding

The following examples describe the scenarios that can occur when binding a z/OS shadow job that is defined as follows:
  • Input arrival (IA): 18:00
  • Remote job information:
    • Application ID: JS2
    • Operation number: OP2
    • Resolution criteria: C
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 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 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 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 instance 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.

Examples of bind process for a z/OS shadow job with resolution criteria Within a relative interval

The following examples describe some possible scenarios when binding a z/OS shadow job that is defined with resolution criteria Within a relative interval.

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 occurrence highlighted in bold is the instance selected for the bind.
Scenario 1: The bind interval is entirely timed after the IA time of the shadow job
In the following scenario the z/OS shadow job is defined as follows:
  • Input arrival (IA): 9:00
  • Remote job information:
    • Application ID: JS4
    • Operation number: OP4
    • Resolution criteria: R
    • FROM hours: 001, minutes: 00, After IA time
    • TO hours: 004, minutes: 00, After IA time
Figure 6. 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 CP shows the JS4 instance that can be associated with the shadow job, even though the instance is not yet in the CP.

A notification informing that the bind is established is sent back to the Z controller and the status of the shadow job is set to READY-The bind was established.

At this point, one of the following situations can occur:
The selected JS4 instance contains OP4
The bind with OP4 belonging to JS4 is established and a notification containing:
  • The information necessary to identify the OP4 instance in the remote engine plan
  • The current status of that OP4 instance
is sent back to the Z controller, the shadow job instance is updated with the remote job information, and its status is updated accordingly.
The selected JS4 instance no longer contains OP4 because either it was deleted and a daily plan removed it from the CP, or it was never contained in JS4.
The bind fails. A notification informing that the bind failed is sent back to the Z controller, and the shadow job status is updated according to what you set in the Complete if bind fails field.
The selected JS4 instance contains OP4 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 Z controller. The shadow job instance is marked as completed. Its successors can start.
Scenario 2: The bind interval is included in the LTP and the IA time of the shadow job is across the bind interval
In the following scenario the z/OS shadow job is defined as follows:
  • Input arrival (IA): 14:00
  • Remote job information:
    • Application ID: JS10
    • Operation number: OP10
    • Resolution criteria: R
    • FROM hours: 005, minutes: 00, Before IA time
    • TO hours: 002, minutes: 00, After IA time
Figure 7. The instance to be bound is included in the CP


The instance to be bound is included in the CP shows the JS10 instance that can be associated with the shadow job, because the bind process starts searching the occurrence before the IA time of the shadow job.
Scenario 3: The bind interval is not entirely included in the LTP and the IA time of the shadow job is across the bind interval
In the following scenario the z/OS shadow job is defined as follows:
  • Input arrival (IA): 14:00
  • Remote job information:
    • Application ID: JS12
    • Operation number: OP12
    • Resolution criteria: R
    • FROM hours: 005, minutes: 00, Before IA time
    • TO hours: 006, minutes: 00, After IA time
Figure 8. The instance to be bound is not yet included in the LTP


The instance to be bound is not yet included in the LTP shows that the bind process starts searching the occurrence before the IA time of the shadow job, without finding any matching successor. Then it searches after the IA time until 18:00, when the LTP ends. Because no match is found either, the bind process tries again after you extend the long-term plan, as described in The instance to be bound is included in the LTP after it was extended.
Figure 9. The instance to be bound is included in the LTP after it was extended


After the LTP is extended, the bind process continues to search for a matching predecessor starting from 18:00, where he had previously stopped. Hence, even if a JS12 instance with IA time 12:00 was dynamically added to the current plan, the bind process associates with the shadow job the JS12 with IA time 19:00.