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. Figure 1 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.
For more information on the reason why the shadow job status is FAIL , see How to see why the shadow job status is FAIL.
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.