How the shadow job status changes after the bind is established
When a bind is established, the remote engine sends back an HTTP
notification containing the status of the bind and, if the bind was
successful, the information to identify the remote job instance bound.
This information is shown in the shadow job instance details.
Depending on the type of a remote engine, the following information
about the remote job instance is shown in the shadow job properties:
The remote engine type is distributed
Job stream name
Scheduled time
Job stream workstation
Job name
The remote engine type is z/OS
Application ID
Scheduled time
Operation number
Workstation
Job name, if it was defined on the remote engine.
When the shadow job instance is mapped to an existing remote job
instance, notifications about job status changes are sent asynchronously
from the remote engine. These notifications are used to map remote
job status transition to shadow job status transition. The store and
forward mechanism ensures the delivery of the messages and the recovery
in case of failures. Shadow job
status transition chain after the bind was established shows
how the status of a distributed shadow job changes, from when a bind
is established until the shadow job status becomes SUCC or ERROR.
Only status SUCC and ERROR are considered as the final status for
a shadow job.Figure 1. Shadow job
status transition chain after the bind was established
If the remote job instance is already completed when the match
is done, the shadow job status becomes SUCC immediately.
When the shadow job status satisfies the dependency rule, the dependency
of the local job on the shadow job is resolved, and the cross dependency
for the local job on the remote job is also resolved.