Mirroring Robot Schedule Using ROBOTLIB to ROBOTLIB

 

Introduction

If you are running Robot Schedule 12.04 or higher, and you are not running live on both the source and target systems, follow the instructions in this article. For all other systems, see “Mirroring Robot Schedule.”

Use the instructions in Steps A-F 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.

Notes:

• Throughout these instructions, the source system refers to the base system where Robot Schedule is installed; the target system refers to the mirrored high availability (HA) system where the second copy of Robot Schedule is installed.

• 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."

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, follow the instructions in the Robot Schedule Installation Guide. You must perform the install on both the source and target systems.

Do not use the mirroring or journaling process to perform the install. Install on both systems at the same time, or use the same media. Do this even if you are not purchasing a full license for the high availability system, as it ensures that all objects are present. Then, set up mirroring and journaling based on the relevant product document.

Robot Schedule Exists on Source System, but not Target System

If Robot Schedule is already installed on the source system but not on the target system, see "Moving Robot Schedule 10, 11, 12, or 13 to a Different System" for instructions on creating the mirrored copy 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 are at release/modification 1.24 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 1.30 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 the information in "Step C—Maintaining Robot Schedule on Your Systems". These processes install and update the Robot Schedule IFS.

• It is 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 do not 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 ROBOTLIB

The product release/modification levels MUST be the same on both systems, so we recommend that you update or convert both systems at the same time, and use the same media. If you do not have a permanent license key for the target system, you may need to get a temporary key in order to do the update or conversion. Contact your Regional Sales Manager for more details.

1. 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 by calling program RBT107 in ROBOTLIB.

3. Stop the mirroring/journaling process.

4. Update or convert Robot Schedule on both systems.

5. Restart the mirroring/journaling process after both systems have been updated or converted.

Step D—Preparing the Source System before a Planned Switch to the Target System

1. On the source system, add the product library name to the library list.

   ADDLIBLE ROBOTLIB

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

   RBTINSSBM *OFF

3. 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.

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

   CALL RBT107

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

   RBTINSSBM *ON

6. End mirroring from the source to the target system.

Step E—Preparing the Target System Database for a Planned Switch

1. On the target system, add the product library name to your library list.

   ADDLIBLE ROBOTLIB

2. Execute the following command to register the Robot Schedule product library with the Help Systems Exit Point HELPSYS_FYI_ADEX.

   ROBOTLIB/RBTREGAPP PRODUCTLIB(ROBOTLIB) MERGELIB(RBTMRGLIB)

   If you do not have a merge library on the target system, enter *NONE for the MERGELIB parameter.

3. 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.

4. After the command completes, use the following command to initialize the Robot Schedule database.

   RSLSETOID PRC(RBT)

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

6. If you have an environment where there is reactivity between the source and other systems, see “Step F—Updating Cross-System Reactivity” before proceeding with step 7 to start the product.

7. When the switchover occurs, call the following program to start Robot Schedule.

   CALL RBT103

   Note: If you wish to start Robot Schedule with RBTSLEEPER, make sure to set the autostart feature by using:

   RBTAUTOSTR AUTOSTR(*YES)

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

   RBTAUTOSTR AUTOSTR(*NO)

Step F—Updating Cross-System Reactivity

If you have an environment where there’s reactivity between the source system and a different system, follow the option below that applies for your environment.

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. Look for other networked systems with reactive jobs or remote group members. Run these reports on the target system.

• Cross System Prerequisite Jobs

• Cross System Reactive Jobs

• Remote Group Member Jobs

Option 1: If the source system and the target system have the same system name, cross-system reactivity will continue to work without any further action.

Option 2: If the source system and target system have different system names and you want to continue using cross-system reactivity, do one of the following:

• If your remote system is version 11.10 or earlier, run the RSLCHGSYSN command on the remote system (not on the source system or the target system) that has either a reactive job or a prerequisite job from the original source system, enter the command on the networked system as follows:

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

• If your remote system is version 11.11 or higher, run the RBTSWAPRMT command on the remote system (not on the source system or the target system) that has either a reactive job or a prerequisite job from the original source system.

  Enter the following commands:

  ADDLIBLE ROBOTLIB

  RBTSWAPRMT PREVIOUS(source_system_name) CURRENT(target_system_name)

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."

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.