Processing flow across the distributed scheduling environment

Depending on whether the local engine emits or receives a bind request, the processing flow and the components involved change. In both cases, the broker workstation in the local environment must be up and running to allow the bind requests management.

Processing flow when the local engine sends a bind request to a remote engine

When you define a shadow job, you specify the information needed to establish a bind with a job in the remote engine plan.

When the shadow job scheduled time arrives, if the shadow job is free from dependencies, it is selected by the local batchman for submission and its status is set to INTRO.

The bind request is sent to the remote engine. The shadow job status is set to WAIT.

As soon as the bind processing completes, the remote engine sends back to the local engine a notification with the bind result.

Table 1 shows how the shadow job status changes based on:

• Whether the instance to bind exists or not in the remote engine plan.
• The status of the remote job bound.

Table 1. Shadow job status transition

Status of the shadow job in the production plan:	When on the remote engine:
BOUND	z/OS The remote job stream instance for the bind was found in the long term plan or in the current plan. Distributed The remote job stream instance for the bind was found in the preproduction plan.
ERROR	z/OS One of the following situations occurred: The remote job stream instance for the bind exists neither in the long term plan nor in the current plan. The remote job stream instance for the bind was found in the long term plan but, when it is included in the current plan, it does not contain the requested job instance. Distributed One of the following situations occurred: The remote job stream instance to bind does not exist in the preproduction plan. The remote job stream instance for the bind was found in the preproduction plan but, when it is included in the production plan, it does not contain the requested job instance. The remote bind user is not authorized to access the requested job instance in the production plan.
EXEC	The status of the remote job is EXEC.
SUCC	The status of the remote job is SUCC.
FAIL	The status of the remote job is FAIL.
ABEND	The status of the remote job is ABEND.
SUCC	The status of the remote job is CANCELED.

Note: The status of the shadow job is FAIL also when its submission failed.

For more details about the shadow job status transition, see How the shadow job status changes until a bind is established and How the shadow job status changes after the bind is established.

Processing flow when the remote engine receives a bind request from the local engine

When the remote engine receives a bind request from the local engine, the information contained in the request is used to run the bind in the remote preproduction plan.

The bind request also contains an ordered list of URLs that the remote engine uses to send notifications to the local engine. If the local engine is distributed, the list is made up of the URL specified in the JDURL property of the file named TDWB_HOME/config/JobDispatcherConfig.properties.

Note: By default the HCL Workload Automation uses the TWSUser to run the bind in the production plan. If you want to limit and control which jobs can be bound, you can specify a different user using the global option bindUser. The user specified does not need to be defined as a user on the operating system, or even have a password, but it must exist as entry in the security file with the following access privileges:

• DISPLAY access to the job and schedule objects that can be bound
• LIST access to the job objects that can be bound. This access is required only if the global option enListSecChk is set to yes.

If the required access privileges are not specified, a notification with an error is sent back to the engine that requested the bind.

The remote engine sends back to the local engine:

A notification with the status BOUND

If the preproduction plan contains at least one instance of the job stream specified in the bind request and the definition of that job stream contains the job to bind.

A notification with the status of the job instance bound

If the instance of the job to bind is found in the production plan and whenever its status changes.

A notification with an error

If the job instance to bind is not found or if the bind user is not authorized.

The remote batchman process writes an entry in the PlanBox.msg queue whenever the status of a remote job changes.

Every 30 seconds, the PlanBox.msg queue is scanned for new entries that document a change in the status of remote jobs that were bound. Whenever a status change is found, a notification containing the status of the remote job bound is sent back to the engine that requested the bind.

Note: To change the polling interval, specify a value, in seconds, for com.ibm.tws.planner.monitor.checkPlanboxInterval in the file WAS_HOME/profiles/profile_name/properties/TWSConfig.properties and then restart the WebSphere Application Server.