How the shadow job status changes until the bind is established

Shadow job status transition chain while establishing the bind summarizes how the shadow job status changes until the bind is established. The bind status of the shadow job is represented as STATUS - Extended status. You can see the extended status of a job shown in the SELECTING APPLICATION OCCURRENCE AND OPERATION INFORMATION panel.

The graphic shows the shadow job status transition chain while establishing the bind — Figure 1. Shadow job status transition chain while establishing the bind

The initial status of the shadow job is WAITING (W). It changes to READY (R) as soon as the shadow job becomes free from dependencies and is ready to start.

The scheduler then sends an HTTP request to the remote engine asking to bind that shadow job instance with the instance of the remote job that closest precedes the shadow job input arrival in the remote engine plan. The HTTP request contains both the information to identify the shadow job in the current plan and the information to uniquely identify the remote job instance in the remote engine plan. The scheduler requires, as well, to be notified about the status of the remote job instance bound.

As soon as the remote engine receives the HTTP request it tries to identify in its plan the job stream instance to bind. The definition of that job stream must contain the definition of the remote job to bind.

Note: On a distributed remote engine it can be specified which job can be bound by assigning specific authorization to the user ID that runs the bind in the plan. If that user ID has not the needed authorization to run the bind, the bind fails. For more information, see the HCL Workload Automation: User's Guide and Reference.

Depending on whether the shadow job is a z/OS or a distributed job, the way to associate it with a remote job instance is slightly different. The following sections describe how the job instance is matched in the remote engine plan.