Using Robot Schedule in a High Availability Environment

 

Introduction

Use this document 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 this document, 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.

If you’re running Robot Schedule R12M04 or higher, do not follow these instructions. Instead see “Mirroring Robot Schedule” on our website in order to decide which set of instructions apply to your system.

Notes:

• 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 the Robot Schedule Interface to Oracle EnterpriseOne, see the product-specific information below at the end of "Step B—Replicating Robot Schedule Objects."

• You normally will replicate objects into the ROBOTLIB library on the target system. However, if Robot Schedule is active on the target system, the mirrored library must have a different name. Read "Step C—Considerations When Switching to a Target System" below for more information.

• 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

Note: 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 the source or target system, follow the instructions in the topic in the Robot Schedule Installation Guide to install.

Currently Running Robot Schedule on the Source System

If Robot Schedule is currently installed on the source system, we recommend that you follow the instructions in the topic "Moving Robot Schedule 10, 11, 12, or 13 to a Different System" on our website.

Working with ROBOTLIB

Installing ROBOTLIB on an HA System

Install Robot Schedule onto the high availability (HA) system, exactly as you would onto your production system.

Do not use the mirroring or journaling process to perform the install. The product release/modification levels MUST be the same, so do this at the same time, or using the same media. Do this even if you are not purchasing a full license for the HA system, as it ensures that all objects are present. Then, set up mirroring/journaling based on the relevant product document.

If you choose to install by using a Save/Restore method, refer to the appropriate Moving Robot Schedule to another system instructions.

Updating ROBOTLIB on an HA System

1. Ensure the mirroring/journaling process is up to date.

2. Stop the process.

3. Stop Robot Schedule on both the live and HA systems, and update them individually.

   Note: The product release/modification levels MUST be the same, so do this at the same time. If you don’t have a permanent license key, you may need to get a temporary key for the target box in order to do the update. Contact your Regional Sales Manager for more details.

4. Restart the mirroring/journaling process.

5. Restart the product.

6. Do not use the mirroring or journaling process to perform the update.

Converting ROBOTLIB on an HA System

1. Ensure the mirroring/journaling process is up to date.

2. Stop the process.

3. Stop Robot Schedule on both the live and HA systems, and convert them individually.

   Note: The product release/modification levels MUST be the same, so do this at the same time. If you don’t have a permanent license key, you may need to get a temporary key for the target box in order to do the update. Contact your Regional Sales Manager for details.

4. Restart the mirroring/journaling process.

5. Restart the product.

6. Do not use the mirroring or journaling process to perform the conversion.

Step B—Replicating Robot Schedule Objects

The tables below are for customers who are planning for high availability applications. The tables define the Robot Schedule objects and specify which objects 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

Table 2 below lists specific objects that you should exclude from mirroring. Although 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:

• The following user spaces can be replicated if you are at the indicated release/modification level and are using the multiple-entry license screens:

  • Robot Schedule, RBT999, R11M12 or higher.

  • Robot Schedule interface to Oracle EnterpriseOne, RBJ248US, R01M30 or higher.

• Robot Schedule 10 also includes IFS objects. These 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 "Updating and Converting Robot Schedule" in the Additional Information section below to make sure that these IFS objects are set up properly.

• You probably will replicate objects into the ROBOTLIB library on the target system. However, if Robot Schedule is active on the target system, the mirrored library will have a different name. Read "Step C—Considerations When Switching to a Target System," for more information.

• It is important for you to know what your mirroring software does with logical files. This helps you decide if you do or do not need to mirror them.

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 will need to exclude the following directory:

/Help Systems/EnterpriseOne/WorkDir/*

If You Use Robot Schedule Enterprise

The defaults for mirroring Robot Schedule Enterprise are the same as those for Robot Schedule, with the following exceptions.

Set up the library RBTENTLIB for mirroring using the defaults defined above. Then, set exclusions for the following objects in your mirroring software.

Step C—Considerations When Switching to a Target System

If you are mirroring Robot Schedule to a target system on which Robot Schedule is already running (sometimes called running "Live/Live"), you must do the following on the target system before performing "Step D—Switching from the Source System to the Target System":

1. Stop Robot Schedule. Call the RBT107 program in ROBOTLIB.

2. Rename the Robot Schedule library ROBOTLIB to another name.

3. Rename the mirrored library on the target system to ROBOTLIB.

4. Continue with "Step D—Switching from the Source System to the Target System" below. Note: If you are running RSLCHGSYSN, you will need to follow the special instructions in that section.

Note: If you are running Robot Schedule 9 and Robot Schedule auditing is active on the target system, you must delete the journals and journal receivers before renaming the ROBOTLIB library. Do the following to save the library and journal receivers before deleting them:

1. Stop Robot Schedule and enter one of the following commands to save the journal objects or library:

   SAVOBJ OBJ(RBTJRN*) LIB(ROBOTLIB) DEV(*SAVF)SAVF(SAVFILELIB/SAVE_FILE)

   SAVLIB LIB(ROBOTLIB) DEV(*SAVF) SAVF(SAVFILELIB/SAVE_FILE)

2. End Robot Schedule Auditing.

3. Enter the following commands to delete the journal and journal receivers:

   DLTJRN JRN(ROBOTLIB/RBTJRN)

   DLTJRNRCV JRNRCV(ROBOTLIB/RBTJRN*)

Note: Remember to turn auditing on again when you go back to the source system.

Step D—Switching from the Source System to the Target System

On the Source System

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

On the Target System

1. Execute the following commands to create exit points, database triggers, stored procedures, and functions:

   ADDLIBLE ROBOTLIB

   CALL RBT108

   CALL PGM(ROBOTLIB/RBTINST3) PARM('ROBOTLIB' 'ROBOTLIB' '0' '0' '*')

2. You must change the system name in our database files before running Robot Schedule on the target system. You can run the RSLCHGSYSN command in RBTSYSLIB, which modifies the name, in batch or interactively. Use the DSPNETA command to retrieve the target system name and then enter it on the RSLCHGSYSN command.

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

   Do one of the following (whichever is appropriate for your environment):

   • If you are running Robot Schedule 11M10 or earlier and you are not running "Live/Live", enter the following command:

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

   • If you are running Robot Schedule 11M10 or earlier, and you are running "Live/Live", and you have cross-system reactivity set up between the source system and the target system, enter the following commands on the target system:

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

     RSLCHGSYSN BEFORE(sourcesysname) AFTER(targetsysname) PRODUCT(ROBOT)

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

   • If you are running Robot Schedule 11M11 or higher enter the following commands:

     ADDLIBLE ROBOTLIB

     RBTSWAPSYS SOURCESYS(old_system_name) TARGETSYS(new_system_name)

3. After the appropriate command completes, run the following command to initialize the Robot Schedule database. (Do this only if RBTSYSLIB is at R01M96, dated 071119, or higher. Enter the command RSLVER to see the release/modification level of RBTSYSLIB.)

   RSLSETOID PRC(RBT)

4. Delete the object RBTWMNTFY *DTAQ in ROBOTLIB. This object is created again when you start Robot SCHEDULE.

5. If you have an environment where there is reactivity between the source and other systems, see “Step E—Considerations for Cross-System Reactivity with Other Systems” before proceeding with step 5 to start the product.

6. When the switchover occurs, you must start Robot Schedule on the target system. Call the program RBT103 in ROBOTLIB to start Robot Schedule.

Step E—Considerations for Cross-System Reactivity with Other Systems

If you have an environment where there is reactivity between the source system and a different system, follow the directions below that apply for your environment.

• If the source system and the target system have the same system name, cross-system reactivity will continue to work without any further actions.

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

  • If you are on version 11M10 or earlier, run the RSLCHGSYSN command on each system in the network (not the source or the target) that has either a reactive job or a prerequisite job from the original source system, enter the command as follows:

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

  • If you are on version 11M10 or earlier, run the RSLCHGSYSN command on each system in the network (not the source or the target) that has either a reactive job or a prerequisite job from the original target system, enter the command as follows:

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

  • If you are on version 11M11 or later, run the RBTSWAPRMT command on all systems in the network (not the source or the target) that have either a reactive job or a prerequisite job from the original source system. If you are unsure what systems may have reactive jobs or remote group members, run one of the following reports:

    • Cross System Prerequisite Jobs

    • Cross System Reactive Jobs

    • Remote Group Member Jobs

    Then, enter the following commands:

    ADDLIBLE ROBOTLIB

    RBTSWAPRMT PREVIOUS(source_system_name) CURRENT(target_system_name)

  The commands change only the records that contain the original source system name to the 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, upgrades, and new installations. No dynamic data is stored in this library.

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.

Updating or Converting Robot Schedule

When you update or convert Robot Schedule on the source system, you also must make the same changes on the target system. We recommend that you end the mirroring product, perform the update or conversion on the source system, update or convert the target system, then restart the mirroring process. Different mirroring software products may have options to synchronize the libraries, or to send all changed objects to the source system. However, to make sure that all the necessary added or updated objects are on the target system, we recommend that you follow the normal update or conversion process on both systems.