HCL Workload Automation, Version 9.4
< Previous

Creating dependencies in a workload running in two HCL Workload Automation scheduling environments

This scenario describes how you can create a dependency relationship in a workload running in different HCL Workload Automation environments using cross dependencies.

Business Goal

An insurance company runs a number of jobs to collect the data processed during the day. The information about the transactions completed during the day by all of the workstations in the company branches is collected and processed on the distributed HCL Workload Automation master domain manager, TWSD.

As soon as this processing completes, the HCL Workload Automation for z/OS controller at the head office, TWSZ, must run reports and statistics on this data to compare the actual results with the projected results.

To accomplish this task, the HCL Workload Automation administrator of TWSZ needs to automate the following process: the job RUNREP that runs the reports starts only after the job COLLECT_TRANSACTIONS, that collects data processed at the branch offices, completes successfully on TWSD.

Roles

This section lists the user roles required to run the scenario:
HCL Workload Automation Administrator
Manages HCL Workload Automation workloads by creating and modifying jobs.
HCL Workload Automation Operator
Manages HCL Workload Automation workloads by submitting and monitoring jobs.

Software requirements

The following software must be installed and configured, before running this scenario:
  • A HCL Workload Automation for z/OS network and a HCL Workload Automation network, whose managers can ping each other.
  • A Dynamic Workload Console.

Setting up the environment

To run this scenario do the following:
On TWSZ
  • Ensure that the version of HCL Workload Automation installed is at least 8.6.
  • Define in the ROUTOPTS initialization statement, an HTTP or HTTPS destination for the TWSD master domain manager and for each backup master defined.
  • Define remote engine workstations for each of these destinations. The primary remote engine workstation, TWSDREM points to the TWSD master domain manager. The other remote engine workstations are defined cascading as alternate workstations.
On TWSD
  • Ensure that the version of HCL Workload Automation installed is at least 8.6.
  • If you specified in the global option bindUser a user different from TWS_user, ensure that the specified user has the required authorizations to bind the job stream containing COLLECT_TRANSACTIONS as well as the COLLECT_TRANSACTIONS job itself.

Running the Scenario

About this task

To complete this scenario, as the TWSZ Administrator, you need to perform the following operations:
  1. Double-check with the TWSD Administrator the information needed to identify the specific COLLECT_TRANSACTIONS job instance in the TWSD plan.
  2. Create a shadow job COLLECTSH with the following characteristics:
    • It is defined on the TWSDREM remote engine workstation.
    • It points to the COLLECT_TRANSACTIONS job instance.
    • The input arrival of the shadow job must follow the input arrival of the COLLECT_TRANSACTIONS job instance.
  3. Define a dependency in RUNREP job from COLLECTSH.
  4. Extend the plan.
Figure 1 shows the workload flow between the two environments:
Figure 1. Processing flow
The figure shows the processing flow
Then, as TWSZ Operator, do the following:
  1. Log in to the Dynamic Workload Console to monitor the status of the shadow job COLLECTSH.
    Note: If the engine connection to TWSD is defined on the Dynamic Workload Console, then the TWSZ Operator can monitor both the status of COLLECT_TRANSACTIONS job defined on TWSD and the status of the shadow job COLLECTSH defined on TWSZ from the same user interface.
  2. Monitor when the status of the shadow job becomes BOUND. This means that the association of COLLECTSH with the instance of COLLECT_TRANSACTIONS was established.
  3. Rerun and recovery of the COLLECT_TRANSACTIONS instance are managed automatically by the product and mapped to the shadow job status. If COLLECTSH is submitted successfully, but then fails or goes to ERROR, you have to contact the TWSD administrator to verify what went wrong in the COLLECT_TRANSACTIONS instance.
As soon as the information collected at the branch offices is collected, the COLLECT_TRANSACTIONS job completes successfully on TWSD. As a consequence, the shadow job COLLECTSH also completes on TWSZ. The RUNREP dependency from COLLECTSH is resolved and, if RUNREP is free from other dependencies, it can start running the report on closing day activities.

Expected Results

You automated your closing day activities run overnight by creating a dependency on a job running locally from a job, that collects data from the branch offices, running on a different HCL Workload Automation environment.

< Previous