HCL Workload Automation, Version 9.4

Defining a cross dependency

About this task

Perform these steps to define a cross dependency between a job running in your environment and another job running on a different HCL Workload Automation engine:

Procedure

  1. Create a remote engine workstation

    Create a remote engine workstation for a specific remote engine when you need to define dependencies on job instances running on that remote engine. On a remote engine workstation you can run only shadow jobs.

    As a best practice, if the remote HCL Workload Automation engine is distributed, you can define a dynamic pool containing an ordered list of remote engine workstations pointing to the remote master and to its backup masters, to ensure that failover and switch manager capabilities are applied. For more information about workstations pool, see Workstation.
    Note: It is recommended that:
    • All the distributed environments involved have the timezone feature enabled. For more information, see Enabling time zone management.
    • You specify as TIMEZONE property of the remote engine workstations the timezone set on the operating system of the remote Master Domain Managers or Backup Master Domain Managers they point to.

    For more information about the specific settings to use when defining a remote engine workstation, see Workstation definition.

  2. Define a shadow job running on the remote engine workstation

    Create a shadow job pointing to a specific job instance defined on a remote engine when you want to track in your local environment the status of that remote job and define cross dependencies on that remote job.

    On HCL Workload Automation distributed environments, you can use alias for job stream names and job names. If you are defining a distributed shadow job, make sure that:
    • The remote job stream name specified, contains the job stream name as it is defined in the database.
    • The remote job name specified, contains the alias, if defined, of the remote job to bind.
    If you do not follow these guidelines, the bind fails and the status of the shadow job becomes ERROR.

    In the shadow job definition set COMPLETE_IF_BIND_FAILS in the rccondsucc field to specify if the shadow job status must be forced to SUCC or ERROR if the bind in the remote engine plan fails.

    For more information about the specific settings to use when defining a shadow job, see Job definition.

    Depending on whether the remote engine is z/OS or distributed, you can use different matching criteria:
    If the remote engine is distributed
    You can choose any of the these matching criteria:
    Table 1. Matching criteria for distributed shadow jobs
    On the Dynamic Workload Console Corresponding keyword used in composer
    Closest preceding previous
    Within a relative interval relative from=time_before_scheduled_time to=time_after_scheduled_time
    Within an absolute interval absolute from=interval_start to=interval_end
    Same scheduling date sameDay
    For more information about these matching criteria, see Managing external follows dependencies for jobs and job streams.
    If the remote engine is z/OS based
    Closest preceding is the only matching criteria supported by IBM Workload Scheduler for z/OS.
    The scheduled time of the job stream instance containing the shadow job is used for the matching in the remote engine plan.

    The shadow job status transition is mapped to the remote job instance status transition.

  3. Add a dependency on the shadow job
    You add the cross dependency for a local job on the remote job by defining a dependency for the local job on a shadow job that:
    • Points to the remote job instance.
    • Is defined on a local workstation that points to the remote engine where the remote job is defined.

    The cross dependency on the remote job instance is released when the local dependency on the shadow job is released.