Home
HCL Workload Automation for Z
Welcome to the HCL Workload Automation for Z documentation, where you can find information about how to install, maintain, and use the product.
Managing the Workload
You can plan when and how your workload runs and manage it as part of a plan.
Planning and scheduling
Learn how to organize your workload while it runs, and the dependencies among its parts.
Configuring a backup controller for disaster recovery
Recovering from a system failure on the local site
You might want to replicate the configuration that you set on your local site system also on the remote site. Then, if a system failure occurs on your local site, your workload schedule can continue to run on the remote site.

HCL Workload Automation for Z
Welcome to the HCL Workload Automation for Z documentation, where you can find information about how to install, maintain, and use the product.
- Program Directory
- Dynamic Workload Console Readmes
  For the latest information about a Dynamic Workload Console fix pack, see the appropriate Readme File.
- Planning and Installation
- Customization and Tuning
- Managing the Workload
  You can plan when and how your workload runs and manage it as part of a plan.
  - About this publication
  - Planning and scheduling
    Learn how to organize your workload while it runs, and the dependencies among its parts.
    - What is the scheduler?
    - A user scenario
    - Using the scheduler panels
    - Creating Workstations
    - Creating special resources
    - Creating calendars and periods
    - Defining and managing run cycle groups
      You can optionally define a run cycle group for your application instead of - or in addition to - a number of single run cycles.
    - Creating applications and groups
    - Defining applications in batch
    - Overview of the long-term and current plans
    - Producing and modifying the long-term plan
    - Producing the current plan
    - Multiple matching criteria for the resolution of dependencies
    - Using service and optional functions
    - Selecting Work for Automatic Submission
    - Overview of job tracking on z/OS®
    - Planning for recovery and restart
    - Configuring a backup controller for disaster recovery
      - Starting a backup controller
      - Recovering from a system failure on the local site
        You might want to replicate the configuration that you set on your local site system also on the remote site. Then, if a system failure occurs on your local site, your workload schedule can continue to run on the remote site.
      - Running the primary and backup controllers
        During normal processing, the primary controller sends all the data and plan updates to the backup controller, which in turn applies them to its databases.
      - Applying maintenance to your environment
        To apply maintenance to both the primary and backup controllers, complete the following steps.
      - Creating or extending a long-term plan or current plan on the primary controller
        When you create or extend a long-term plan, the primary controller sends a copy of it to the backup controller. When you create or extend a current plan, the primary controller sends a copy of the CP, NCP, and LTP files to the backup controller.
      - Switching from primary controller to backup controller
        You can plan to switch processing from a primary controller to its backup (for example, for maintenance reasons) or command the backup controller to take over from the primary controller for an unexpected event, such as a system crash or controller abend.
      - Browsing the list of job steps
        When a controller switch occurs, you might want to browse the list of steps that were run for the jobs in started status before the switch occurred.
      - Restoring the primary controller
    - Setting error codes
    - Restart and cleanup
    - Automatic recovery of jobs and started tasks
    - Conditioning the processing of operations
    - Defining and managing cross dependencies
    - Running event-driven workload automation
    - Job tailoring
    - Job scheduling and WLM
    - Controlling the system where a z/OS job is to be executed
    - Loop detection and analysis
  - Controlling and monitoring
    Learn how to manage the workload when it becomes part of a plan and is run with real dates and times.
  - TSO commands
  - Batch programs
  - Report examples
  - Supported z/OS Commands
  - Status, error, and reason codes
  - Fields displayed in ready and error lists
  - Defining event rules and invoking EQQLSENT macro
  - HCL Workload Automation for Z ISPF variables allowed in the EQQAJCLE panel
- Scheduling End-to-end with z-centric Capabilities
- Quick Reference
- Diagnosis Guide and Reference
- Workload Automation Programming Language for z/OS User's Guide and Reference
- Driving HCL Workload Automation for Z

Recovering from a system failure on the local site

You might want to replicate the configuration that you set on your local site system also on the remote site. Then, if a system failure occurs on your local site, your workload schedule can continue to run on the remote site.

To replicate your local site system configuration on the remote site, specify a remote alternate workstation for each workstation that exists locally. Configuring the local site and remote site in the same way shows a local site system whose configuration is replicated on the remote site.

Configuring the local site and remote site in the same way — Figure 1. Configuring the local site and remote site in the same way

In this configuration:

You defined the alternate workstations as follows:
- On WSA1 you defined WSA2 as the alternate workstation, on WSA2 you defined WSB1 as the alternate workstation.
- On WSB1 you defined WSB2 as the alternate workstation, on WSB2 you defined WSC1 as the alternate workstation.
- On WSC1 you defined WSC2 as the alternate workstation, on WSC2 you defined WSA1 as the alternate workstation.
Therefore:
When the system on the local site is up and running
- If WSA1 is down, the work is redirected to WSB1.
- If WSB1 is down, the work is redirected to WSC1.
- If WSC1 is down, the work is redirected to WSA1.
If the system on the local site fails and the backup controller takes over from the primary controller
- The work that was scheduled to run on WSA1 is redirected to WSA2.
- The work that was scheduled to run on WSB1 is redirected to WSB2.
- The work that was scheduled to run on WSC1 is redirected to WSC2.

Have feedback?
Google Analytics is used to store comments and ratings. To provide a comment or rating for a topic, click Accept All Cookies or Allow All in Cookie Preferences in the footer of this page.