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

The graphic shows the 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.