Mirroring Robot Schedule in a Live/Live Environment

 

Introduction

If you’re running Robot Schedule R12M04 or higher, and you run live on both your source and target systems, follow the instructions in this document. For all other systems, see “Mirroring Robot Schedule” on our website.

A live/live environment is illustrated below. Throughout this procedure, we'll refer to System A and System B. You'll need to substitute your system names for System A and System B. Refer to this image for assistance.

Use the instructions in Steps A-G below as a guide to help set up and manage Robot Schedule with your mirroring application. Refer to your mirroring application's documentation for instructions specific to your configuration.

Throughout these instructions, we use the default name (ROBOTLIB) for the Robot Schedule live copy’s product library. Be aware that beginning with Robot Schedule R12M04, during installation or conversion, you can choose a product library name other than ROBOTLIB to run the product. If you’ve used a different name for your product library, be sure to substitute your library name for ROBOTLIB in these instructions. Similarly, we’ve used the default RBTMRGLIB as the merge library name. Be sure to substitute your merge library name, if it’s different. Note: Using a non-default product library name may render some product interfaces unusable with Robot Schedule. For example, the Robot Network and Robot Schedule Enterprise interfaces require ROBOTLIB as the Robot SCHEDULE product library name.

You're no longer required to rename libraries during the procedure when swapping Robot Schedule. When following the new procedure detailed below, you'll use the RBTREGAPP and RBTDRGAPP commands to register/deregister the Robot Schedule product and merge libraries with the Fortra exit point HELPSYS_FYI_ADEX. These commands eliminate the need to rename libraries during the switchover.

Notes:

• Since you’re mirroring Robot Schedule to a target system on which Robot Schedule is already running (referred to as Live/Live), the mirrored product library must have a name that’s different than the live product library, as shown in the above image.

• All objects in ROBOTLIB on the source system MUST EXIST on the target system – even if all the objects are not being mirrored.

• If you use the Robot Schedule graphical PC interface, you must end it before proceeding.

• If you use Robot Schedule Enterprise, see the product-specific information below at the end of "Step B—Replicating Robot Schedule Objects."

• If you use Robot Schedule for EnterpriseOne, see the product-specific information below at the end of "Step B—Replicating Robot Schedule Objects."

• If you are running Robot Schedule in an IASP, see Running Robot Schedule in an IASP with Robot Network.

Step A—Installing Robot Schedule on Your Systems

The source and target systems must be at the same release/modification level. Use the following information to make sure your systems are set up properly.

New Installs

If Robot Schedule is currently not installed on either the source or the target system, you must perform the install on both the source and target systems, for both the live and the mirrored copy. Note: The mirrored product library must have a different name than the live product library.

Follow these instructions to install Robot Schedule:

1. Install your mirrored copy first, following the instructions in "Installing or Updating Robot Schedule 13" on our website. You can choose any product library name for your mirrored copy and its merge library.

2. After the installation is successful for the mirrored instance, execute the following commands to deregister the mirrored instance from the Fortra exit point HELPSYS_FYI_ADEX to allow installation of another instance:

   ADDLIBLE mirrored_library_name

   mirrored_library_name/RBTDRGAPP PRODUCTLIB(mirrored_library_name) ENDRBT(*YES) DLTQUE(*YES)

3. If Robot Network exists on your system, you must delete the Robot Schedule product master library before installing the production instance of Robot Schedule. If library RBNRBTMST exists, execute the following command to delete it:

   DLTLIB RBNRBTMST

4. Install the production instance, following the instructions in "Installing or Updating Robot Schedule 13." You can choose any library name for your production copy and its merge library.

IMPORTANT: Do not use the mirroring or journaling process to perform the installations.

Robot Schedule Exists on the Source and Target Systems, but No Mirrored Copies Exist

If you’re restoring a copy of Robot Schedule from another system to use as the mirrored copy, you can simply restore the library to a name other than the live product’s name on the target system.

Step B—Replicating Robot Schedule Objects

These tables define the Robot Schedule objects and specify which ones you must replicate to run Robot Schedule with high availability software.

Table 1 below lists the types of objects that you should mirror.

Table 1: Object Specifier for High Availability - Objects that Should be Mirrored

Notes:

• The following data area only needs to be replicated if you're using Automate Schedule. Otherwise, it can be excluded.

  NOTIF_SEQ

Table 2 below lists specific objects that you should exclude from mirroring. Although some of these objects may be the same type as objects shown in Table 1, they should be defined as exceptions and excluded from mirroring.

Table 2: Object Specifier for High Availability - Objects to Exclude from Mirroring

Notes:

• Robot Schedule: The following user space can be replicated if you’re using the multiple-entry license screens:

  RBT999

• Robot Schedule Enterprise: The following user spaces can be replicated if you're at release/modification R01M24 or higher and are using the multiple-entry license screens:

  RBE991US1

  RBE992US1

• Robot Schedule for EnterpriseOne: The following user space can be replicated if you’re at release/modification R01M30 or higher and are using the multiple-entry license screens:

  RBJ248US

• Robot Schedule IFS objects must exist on the target system, but should not be mirrored. Read "Step A—Installing Robot Schedule on Your Systems” and “Step C – Maintaining Robot Schedule on Your Systems”. These processes install and update the Robot Schedule IFS.

• It’s important for you to know what your mirroring software does with logical files. This will help you decide whether or not to mirror them. Generally, we don't recommend mirroring logical files because they may have large indexes, and therefore can cause issues with network traffic.

If You Use Robot Schedule Enterprise

The defaults for mirroring Robot Schedule Enterprise are the same as those for Robot Schedule, with the exceptions listed in Table 2 above.

Set up the library RBTENTLIB for mirroring using the defaults defined above. Then, set exclusions in your mirroring software for the objects that should not be replicated.

If You Use Robot Schedule for EnterpriseOne

Robot Schedule for EnterpriseOne requires you to replicate the following directory in the IFS:

/Help Systems/EnterpriseOne*

However, you'll need to exclude the following directory:

/Help Systems/EnterpriseOne/WorkDir/*

Step C—Maintaining Robot Schedule on Your Systems

Updating or Converting the Source Product Library and its Mirrored Copy

The product release/modification levels MUST be the same for both the live copy on the source system and its mirrored copy on the target system.

To understand what's meant by System A and System B in this procedure, see the illustration in the Introduction section above.

1. On the source and target systems (System A and System B), ensure the mirroring/journaling process is up-to-date. But, do not use the mirroring or journaling process to perform the update or conversion.

2. Stop Robot Schedule on both System A and System B by calling program RBT107 in ROBOTLIB.

3. Stop the mirroring/journaling process on both systems.

4. On one of the source systems (System A in this example), run the update or conversion process.

5. On the target system (System B in this example):

   1. Execute the following commands to deregister the live instance (ROBOTLIB) from the Fortra exit point HELPSYS_FYI_ADEX, so that the mirrored copy can be registered and updated:

      ADDLIBLE product_library_name

      product_library_name/RBTDRGAPP PRODUCTLIB(product_library_name) ENDRBT(*YES) DLTQUE(*NO)

   2. Execute the following commands to register the mirrored instance (ROBOTLIBX) with the Fortra exit point HELPSYS_FYI_ADEX to make it the live instance:

      ADDLIBLE mirrored_library_name

      mirrored_library_name/RBTREGAPP PRODUCTLIB(mirrored_library_name) MERGELIB(merge_library_name)

      Note: If you don’t have a merge library on this system, enter *NONE for the MERGELIB parameter.

   3. Run the update or conversion process.

      Note: You don't need to rename this library to ROBOTLIB in order to update or convert it, because it's currently registered with the Fortra exit point as the live instance.

   4. After the update or conversion, execute the following commands to deregister this instance (ROBOTLIBX) from the Fortra exit point HELPSYS_FYI_ADEX:

      ADDLIBLE mirrored_library_name

      mirrored_library_name/RBTDRGAPP PRODUCTLIB(mirrored_library_name) ENDRBT(*YES) DLTQUE(*NO)

   5. Execute the following commands to register the production instance (ROBOTLIB) with the Fortra exit point HELPSYS_FYI_ADEX:

      ADDLIBLE production_library_name

      production_library_name/RBTREGAPP PRODUCTLIB(production_library_name) MERGELIB(merge_library_name)

      Note: If you don’t have a merge library on this system, enter *NONE for the MERGELIB parameter.

6. If you're also updating or converting the source System B and it’s mirrored copy on System A, then repeat all steps in this section using System B as the source and System A as the target system.

7. Restart the mirroring/journaling process on both systems.

8. Restart Robot Schedule on both systems by calling program RBT103.

Step D—Preparing the Source Systems before the Planned Switchover of a Live/Live Environment

To understand what's meant by System A and System B in this procedure, see the illustration in the Introduction section above.

This step allows for the completion of currently running jobs on both systems, and also ends the product and mirroring before the switchover can occur.

1. Perform steps 2-7 on one of the source systems (System A in this example).

2. Add the product library name to the library list.

   ADDLIBLE ROBOTLIB

3. If data area RBT087DA exists, execute the following command to turn off the Robot Schedule Submit Job feature:

   RBTINSSBM *OFF

4. Execute the following commands to check for jobs in submitted (S) or running (R) status:

   CALL PGM(RBT650) PARM('S000000000000bbbbbbbbbbbbbbbbbbbbbbbbbX')

   CALL PGM(RBT650) PARM('R000000000000bbbbbbbbbbbbbbbbbbbbbbbbbX')

   where the string of b's indicates 25 blank spaces.

   If you find submitted or running jobs, allow them to complete before continuing, so that those history records can be displayed on the target system.

5. Use the following command to stop Robot Schedule for the planned switchover:

   CALL RBT107

6. If you turned off the Robot Schedule Submit Job feature above, then turn it back on before ending the mirroring process:

   RBTINSSBM *ON

7. End the mirroring process.

8. Now, perform steps 2-7 on the other source system (System B in this example).

Step E—Preparing the Target System’s Database for the Planned Switchover

To understand what's meant by System A and System B in this procedure, see the illustration in the Introduction section above.

This step (Step E) performs the switchover from System A to the mirrored copy on System B, using the above example.

1. Perform steps 2-7 on the target system, System B.

2. Use the following command to stop Robot Schedule for the planned switchover:

   CALL RBT107

3. Execute the following command to add the mirrored library name to your library list.

   ADDLIBLE mirrored_library_name

4. Execute the following command to register the mirrored Robot Schedule product library with the Help Systems exit point HELPSYS_FYI_ADEX. Note: You don't have to rename the library. However, the Robot Network and Robot Schedule Enterprise interfaces require ROBOTLIB as the Robot Schedule product library name.

   mirrored_library_name/RBTREGAPP PRODUCTLIB(mirrored_library_name) MERGELIB(merge_library_name)

   If you don’t have a merge library on this system, enter *NONE for the MERGELIB parameter.

5. You must change the system name in our database files before running Robot Schedule on the target system.

   Execute the following command:

   RBTSWAPSYS SOURCESYS(source_system_name) TARGETSYS(target_system_name)

   Note: The system name of jobs with a status of S, R, or P are not changed. This means that you won't be able to see the jobs with S, R, or P status in the Robot Schedule Completion History.

6. After the RBTSWAPSYS command completes, use the following command to initialize the Robot Schedule database:

   RSLSETOID PRC(RBT)

7. Delete the RBTWMNTFY *DTAQ from library RBTSYSLIB, if it exists. This object will be created again when Robot Schedule is started.

Step F—Updating Cross-System Reactivity

If you have an environment where there’s reactivity between the original source system (System A in this example) and remote systems (Systems C and D in the example below), follow the directions in the option that applies to your environment, using the example below; otherwise, skip to “Step G—Completing the Switchover of the Live/Live Systems.”

If you’re unsure which systems have reactive jobs or remote group members, the following reports can help. Look for the target system's name because the original source system name has already been changed in the database on the target system. Look for other networked systems with reactive jobs or remote group members. Run these reports on the target system (System B in this example).

• Cross System Prerequisite Jobs

• Cross System Reactive Jobs

• Remote Group Member Jobs

Important: Only perform this step (Step F) after all the above steps have been completed. The items in Step D should be run for both source systems. The items in Step E should be run on the target system. Step F should be run only once, after all the items in Steps D and E have been run.

Choose either option 1 or option 2 below. When executing the commands in the option, the order of the parameter values for the source and target system might matter. For example, in the following diagram, if both Live/Live systems have reactivity and/or remote group members to the same remote system (see System C), then the order of the parameter values for the source and target systems doesn’t matter. You’d be on System C, swapping the values of System A and System B in the database. However, if both Live/Live systems do not have reactivity and/or remote group members to the same remote system (see System D), then the order does matter. See examples below.

Option 1: If the remote system is running Robot Schedule R11M11 or higher, execute the following commands on the remote system:

ADDLIBLE product_library_name

RBTSWAPRMT PREVIOUS(source_system_name) CURRENT(target_system_name)

Example 1: (based on the example diagram above), the commands would be entered like this:

• On remote System C – Only one of the following commands would be executed:

  RBTSWAPRMT PREVIOUS(System_A) CURRENT(System_B)

  Or

  RBTSWAPRMT PREVIOUS(System_B) CURRENT(System_A)

  The command takes care of “swapping” the names. In this case, the order the parameter values appear in is not important, because both System A and System B have reactivity and/or remote group members to System C.

• On remote System D – The following command would be executed once:

  RBTSWAPRMT PREVIOUS(System_A) CURRENT(System_B)

  It’s imperative that the parameter values be in this order, because any System A data is changed to System B in the System D database.

Example 2: If you are switching both systems to run on the other and you have cross system reactivity to other systems, you need to do the following to change the system name from A to B and B to A: run RBTSWAPRMT 3 times as follows on system C (or any remote nodes that has cross system reactivity to system A and system B).

• RBTSWAPRMT PREVIOUS(A) CURRENT(TEMP) to change from system name A to TEMP
• RBTSWAPRMT PREVIOUS(B) CURRENT(A) to change from system name B to system name A
• RBTSWAPRMT PREVIOUS(TEMP) CURRENT(B) to change from system name TEMP to B

Option 2: If your remote system is running Robot Schedule R11M10 or lower, execute one of the two sets of commands listed below – whichever is appropriate for your environment.

• If your remote system has reactivity and/or remote group members for both of the Live/Live systems (see System C in the example diagram), use the following commands on that remote system:

  RSLCHGSYSN BEFORE(target_system_name) AFTER(TEMPSYS) PRODUCT(ROBOT)

  RSLCHGSYSN BEFORE(source_system_name) AFTER(target_system_name) PRODUCT(ROBOT)

  RSLCHGSYSN BEFORE(TEMPSYS) AFTER(source_system_name) PRODUCT(ROBOT)

• If your remote system only has reactivity and/or remote group members for one of the Live/Live systems (see System D in the example diagram), use the following command on that remote system:

  RSLCHGSYSN BEFORE(source_system_name) AFTER(target_system_name) PRODUCT(ROBOT)

Step G—Completing the Switchover of the Live/Live Systems

1. Restart mirroring from each source system to each target system again, if desired. However, you must change the library names in your mirroring software, because you’re now running live from the original mirrored library on the target system.

2. Start Robot Schedule on each system by executing the following commands:

   ADDLIBLE ROBOTLIBX

   CALL RBT103

   Note: If you wish to start Robot Schedule with RBTSLEEPER, be sure to set the autostart feature by executing this command:

   RBTAUTOSTR AUTOSTR(*YES)

   If you prefer to manually control the starting of Robot Schedule use:

   RBTAUTOSTR AUTOSTR(*NO)

Your original mirrored library is now the live product library for Robot Schedule on each system.

Additional Information

RBTSYSLIB

The Robot system library, RBTSYSLIB, is a general purpose library that contains common modules for the Robot Automated Operations Solution. You do not have to replicate this library; however, the library must be updated when the source or target system is updated with new modifications. If you are replicating RBTSYSLIB please review the exclusions in the tables above. RBTSYSLIB is updated automatically during conversions, updates, and new installations.

RBTMRGLIB

Used to export jobs, message sets and report sets. Mirroring this library is optional; however, it does need to exist on the DR system. NOTE: If you have Robot Network, you can use packets.

User Profiles

The RBTADMIN and RBTUSER profiles are created automatically on all systems when you install Robot Schedule. DO NOT modify or replicate them.

High Availability and Other Robot Products

For information about running other Robot products in a high availability environment, see "Mirroring the Robot Products" on our website.

Licensing the Robot Products

All Robot products must be licensed on each system before using them in a high availability environment. Discuss product licensing with your Regional Sales Manager.