Using Robot/SCHEDULE in a High Availability Environment

Introduction

This document is meant only 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:

• All objects in ROBOTLIB on the source box MUST EXIST on the target box – even if all the objects are not being mirrored.
• If you use the Robot/SCHEDULE 10 or higher graphical PC interface, you must end it before proceeding.
• If you use Robot/SCHEDULE Enterprise, see the product-specific information at the end of Step 2.

Step 1—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 currently is not installed on the Source or Target system, follow the instructions for installing Robot/SCHEDULE. You must perform the install on both the Source and Target systems.

Currently Running Robot/SCHEDULE on the Source System

We recommend that you follow the instructions on moving Robot/SCHEDULE to another system. See the appropriate Help/FACTS for complete information: Moving Robot/SCHEDULE 10 to a Different System or Moving Robot/SCHEDULE 11 to a Different System.

Working with ROBOTLIB

Installing ROBOTLIB on an HA System

Install Robot/SCHEDULE onto the 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.

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.

4. Restart the mirroring/journaling process.
5. Restart the product.
6. Do not use the mirroring or journaling process to perform the convert.

Step 2—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 lists the types of objects that you should mirror.

Table 2 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.

Notes:

• Robot/SCHEDULE 10 also includes IFS objects. These objects must exist on the target system, but should not be mirrored. Read Step 1, Installing Robot/SCHEDULE on Your Systems, and the information in Updating and Converting Robot/SCHEDULE in the Additional Information section 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 3, 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 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 3—Considerations When Switching to a Target System

If you are mirroring Robot/SCHEDULE to a target system on which Robot/SCHEDULE is already running, you must do the following on the target system before performing Step 4, Switching from the Source System to the Target System:

• Stop Robot/SCHEDULE. Call the RBT107 program in ROBOTLIB.
• Rename the Robot/SCHEDULE library ROBOTLIB to another name.
• Rename the mirrored library on the target system to ROBOTLIB.

You then can continue with Step 4.

Note: If you are running Robot/SCHEDULE version 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:

• 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)

• End Robot/SCHEDULE Auditing.
• Enter the following commands:

DLTJRN JRN(ROBOTLIB/RBTJRN)

DLTJRNRCV JRNRCV(ROBOTLIB/RBTJRN*)

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

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

On the Source System

Call the RBT107 program in ROBOTLIB to stop Robot/SCHEDULE for a planned switchover.

On the Target System

• Check to see if any jobs are submitted or running on the target system. Enter the following command to check for submitted (S) and running (R) jobs.

CALL PGM(RBT650) PARM(‘S000000000000bbbbbbbbbbbbbbbbbbbbbbbbbX’)

CALL PGM(RBT650) PARM(‘R000000000000bbbbbbbbbbbbbbbbbbbbbbbbbX’)

where b indicates a blank.

If you find running jobs, allow them to complete before continuing. Place any submitted jobs on hold until the switch to the target system completes, and then release the hold.

• 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:

RSLCHGSYSN BEFORE(system_name) AFTER(system_name) PRODUCT(ROBOT)

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

• After the RSLCHGSYSN 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)

• Delete the object RBTWMNTFY *DTAQ in ROBOTLIB. This object is created again when you start Robot/SCHEDULE.
• When the switchover occurs, you must start Robot/SCHEDULE on the target system. Call the program RBT103 in ROBOTLIB to start Robot/SCHEDULE.

Cross-System Reactivity Considerations

• 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 run the RSLCHGSYSN command on all systems in the network that have 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)

The command changes 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 by conversions, upgrades, and new installations. No dynamic data is stored in this library.

User Profiles

The RBTADMIN and RBTUSER profiles are created automatically on all systems when Robot/SCHEDULE is installed. DO NOT modify or replicate them.

High Availability and Other Help/Systems Products

For information about running other Help/Systems products in a high availability environment, see the Help/FACTS, Mirroring Help/Systems Products.

Licensing Help/Systems Products

All Help/Systems 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.

Updated May 15, 2012