Introduction

If you’re running Robot Schedule R12M04 or higher, and you’re 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 "Installing Robot Schedule 12." 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’re 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, or 12 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

Replicate?
Yes or No
Object Name Object Type Object Attributes
Yes ROBOTLIB/*ALL *DTAARA  
Yes ROBOTLIB/*ALL *JOBD  
Yes ROBOTLIB/*ALL *FILE *ALL
Yes RBTEPRLIB/*ALL (EnterpriseOne interface) Note: All *DTAARA should be mirrored EXCEPT RBJ9000DA *DTAARA  
Yes RBTEPRLIB/*ALL (EnterpriseOne interface) *JOBD  
Yes RBTEPRLIB/*ALL (EnterpriseOne interface) *FILE *ALL

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

Replicate?
Yes or No
Object Name Object Type Object Attributes
No ROBOTLIB/*ALL *PGM *ALL
No ROBOTLIB/*ALL *SRVPGM  
No ROBOTLIB/*ALL *MSGF  
No ROBOTLIB/*ALL *CMD  
No ROBOTLIB/*ALL *OUTQ  
No ROBOTLIB/*ALL *PNLGRP  
No ROBOTLIB/*ALL *MSGQ  
No ROBOTLIB/*ALL *DTAQ  
No ROBOTLIB/*ALL *FILE LF - see note below
No ROBOTLIB/*ALL *USRSPC  
No ROBOTLIB/RBT999 *USRSPC See note below
No ROBOTLIB/RBT090DA *DTAARA  
No ROBOTLIB/RBT660 *DTAARA  
No ROBOTLIB/RBT635 *DTAARA  
No ROBOTLIB/RBT542DA *DTAARA  
No ROBOTLIB/RBT695DA *DTAARA  
No ROBOTLIB/RBT1641DA *DTAARA  
No ROBOTLIB/RBTAPPINST *DTAARA  
No ROBOTLIB/CNLIDLEF *FILE PF
No ROBOTLIB/DISKUSE *FILE PF
No ROBOTLIB/RBTJT* *FILE *ALL
No ROBOTLIB/RB0*–RB9* (Robot REPLAY) *DTAARA  
No ROBOTLIB/RBTDFT *DTAARA  
No RBTENTLIB/RE1099SDA *DTAARA  
No RBTENTLIB/RE1099SDA2 *DTAARA  
No RBTENTLIB/RBE991DA *DTAARA  
No RBTENTLIB/RBE991US1 *USRSPC See note below
No RBTENTLIB/RBE991US2 *USRSPC  
No RBTENTLIB/RBE992DA *DTAARA  
No RBTENTLIB/RBE992US1 *USRSPC See note below
No RBTENTLIB/RBE992US2 *USRSPC  
No RBJ248US (EnterpriseOne Interface) *USRSPC See note below
No RBTEPRLIB/RBJ2483SPC2 (EnterpriseOne Interface) *USRSPC  
No RBTEPRLIB/RJ* (EnterpriseOne Interface) *DTAQ  
No RBTEPRLIB/RJ* (EnterpriseOne Interface) *DTAARA  
No RBTEPRLIB/*ALL *PGM *ALL
No RBTEPRLIB/RBJ9000DA (EnterpriseOne Interface) *DTAARA  

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 the information in "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 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 don’t 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 don’t 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 11M10 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 11M11 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. 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.

 


Still have questions? We can help. Submit a case to Technical Support.

Last Modified On: July 19, 2019