Cloning scheduling definitions from one environment to another

About this task

This section applies to HCL Workload Automation master domain managers and its backup. It documents how to clone HCL Workload Automation data from one environment to another.

Note: This cloning procedure does not clone the following information from the source environment:
  • The preproduction plan
  • The history of job runs and job statistics
  • The audit records
  • The state of running event rule instances. This means that any complex event rules, where part of the rule has been satisfied prior to cloning of the environment, are generated as new rules after the cloning procedure. Even if the subsequent conditions of the event rule are satisfied, the record that the first part of the rule was satisfied is no longer available, so the rule will never be completely satisfied.
With the following steps all scheduling object definitions and global options can be migrated from a source environment named "ENV_1" to a target environment named "ENV_2".
  1. In ENV_2, install a fresh instance of an HCL Workload Automation version 10.1 Fix Pack 5 master domain manager and it point to its database by defining MDM_ENV2 as the master domain manager workstation name. The installation process automatically defines the following workstations in the ENV_2 database:
    • MDM_ENV2 is the master domain manager workstation name.
    • MDM_ENV2_DWB is the broker workstation name.
    • MDM_ENV2_1 is the agent workstation name.
    • MASTERAGENTS is the dynamic pool which includes, by default, MDM_ENV2_1 dynamic agent workstation.
  2. On the ENV_1 master domain manager, run the dataexport command or script to export all scheduling object definitions and global options from ENV_1. You can find this file in the bin subdirectory of the TWA_home directory.
    Run dataexport from a Windows™ or UNIX® command prompt as follows: 
    dataexport source_dir export_dir
    where:
    source_dir
    The TWS_HOME directory of the ENV_1 instance of HCL Workload Automation version 10.1 Fix Pack 5.
    export_dir
    The directory where the export files are created.
    For example: 
    dataexport.cmd F:\IWS10105\twsDB2user F:\IWS10105\export
    The object definitions and the global options are retrieved from the ENV_1 database and placed in the F:\IWS10105\export directory.
  3. Verify that the following files were created in export_dir:
    • acls.def
    • calendars.def
    • erules.def
    • folders.def
    • globalOpts.def
    • jobs.def
      Note: The record length supported by DB2® is 4095 bytes, but it decreases to 4000 bytes with Oracle. When you migrate your job definitions to Oracle, any job with task string (scripts or commands) exceeding 4000 bytes in length are not migrated. In this case, the data import utility replaces the job definition with a dummy job definition and sets the job priority to 0, guaranteeing that successors are not run.
    • parms.def
    • prompts.def
    • rcgroups.def
    • resources.def
    • scheds.def
    • sdoms.def
    • srols.def
    • topology.def
    • users.def (includes encrypted user passwords)
    • vartables.def
  4. Open the export_dir\topology.def file and remove the MASTERAGENTS definition to avoid replacing the same workstation definition that was created when you installed a fresh instance of the HCL Workload Automation version 10.1 Fix Pack 5 master domain manager in ENV_2.

    If you plan to dismiss ENV_1 and you want to move the other workstations from ENV_1 to ENV_2, then you do not have to perform any additional steps.

    If you plan to install new agents in ENV_2, then it is recommended to install them using the same displayname used by the agent present in ENV_1 so that you do not need to modify the erules.def, jobs.def, resources.def, scheds.def, and users.def files exported in the previous step. If you do not install them using the same displayname, then you must edit these files so that they match the agent displayname present in ENV_2.

  5. Edit the export_dir\users.def file to specify the current valid password for the Windows™ users.
  6. To import the object definitions and the global options retrieved from the ENV_1 into the ENV_2 database, copy the files that were created when you ran the dataexport utility to a directory on the ENV_2 master domain manager and run the dataimport command or script to import all scheduling object definitions and global options to the ENV_2 database. You can find this file in the bin subdirectory of the TWA_home directory.
    Run dataimport from a Windows™ or UNIX® command prompt as follows: 
    dataimport source_dir export_dir
    where:
    source_dir
    The TWS_HOME directory of the ENV_2 instance of HCL Workload Automation version 10.1 Fix Pack 5.
    export_dir
    The directory where you copied the object definitions and the global options retrieved from ENV_1.
    For example: 
    dataimport.cmd F:\IWS10105\twsDB2user F:\IWS10105\export
  7. If you want to dismiss the instance of HCL Workload Automation installed in ENV_1 and reuse the same agents in ENV_2, stop the HCL Workload Automation processes running on the master domain manager in ENV_1 to avoid conflicts.

Results

You have now completed cloning scheduling definitions from one environment to another.