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 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
Instance to be bound
if the shadow job scheduled time is included in the CP intervalshows, 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
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
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.