Configuring a new main system in a multisystem node

If you configure a multisystem node in your RRSF network, at a later time you might decide that you need to reconfigure the multisystem node to make a different system the main system. This type of reconfiguration is complex, and it is not a good solution when a system drops or a connection is broken. Instead, when a system drops, re-IPL it. When a connection breaks, let requests and returned output queue up in the workspace data sets while you fix the connection. However, if you need to shift the RRSF workload performed by the main system to another system, you need to reconfigure the multisystem node. RACF® allows you to reconfigure the multisystem node dynamically, without stopping the RACF subsystem on any system other than the original local main system, or losing any RRSF requests or returned output.

Restriction: You cannot change the main system to or from a node for which a non-functional TCP/IP protocol instance exists, or for which a protocol conversion is in progress. If you try to do this, the TARGET command fails.

When you reconfigure a multisystem node, you cannot safely just delete node definitions on live systems and redefine them. You risk losing requests from automatic direction or password synchronization while the nodes are not defined. Instead, to configure a different main system in a multisystem node, follow these steps:

Drop TSO/E and JES on the original local main system.
Doing this prevents any further RACF activity on the system, and so prevents RACF databases from becoming unsynchronized if you use automatic command direction.
On the original local main system, issue the RACF STOP command to stop the RACF subsystem.
Doing this causes the system to attempt to finish up all outstanding work and to close its workspace data sets. New requests and returned output from remote nodes will queue up in their OUTMSG workspace data sets.
Make connections dormant:
- On the local system that is to be the new main, issue a TARGET DORMANT command for its local connection. Also issue TARGET DORMANT commands to make all connections with remote nodes dormant.
- On each remote node, issue TARGET DORMANT commands for the original and new main systems. Do not perform step 7 until the INMSG files for the original and new main systems on each remote node have drained.
Tip: In this step and others where you must issue the same command or set of commands on every system (or every nonmain system, in this case) on a multisystem node, you can make the task a little easier by creating a RACF parameter library member, IRROPTxx, containing the commands. Then you can issue a SET INCLUDE(xx) command on each system instead of manually entering the commands.

After you issue the TARGET DORMANT commands, requests in the INMSG workspace data sets are processed, and their output is queued up in the OUTMSG workspace data sets. New requests and returned output also queue up in the OUTMSG data sets. Issue TARGET LIST commands to verify that the INMSG data sets on the local node have been drained before you go on to the next step.
If the workspace data sets for the original main system and the new main system are not on shared DASD with a shared catalog, copy the workspace data sets for the original main system to DASD accessible to the new main system, using the same workspace data set names.
On the new main system, issue a TARGET MAIN command to make it the main system. For example, if the multisystem node name is NODEABC, and MVSB is the new main system, issue:
```
TARGET NODE(NODEABC) SYSNAME(MVSB) MAIN
```
This command causes RACF to transfer requests and returned output from the original main system's OUTMSG workspace data sets to the new main system's OUTMSG workspace data sets.

If you have not specified the prefixes for the workspace data sets and the LU names for the member systems consistently in the TARGET commands that defined the local multisystem node, this step will fail. See Defining RRSF nodes to RACF.
Issue the same TARGET MAIN command that you issued in step 5 on each nonmain system on the local multisystem node. Issue this command on the original main system only if it is to remain in the multisystem node.
Issue TARGET LIST commands to verify that the INMSG data sets on the remote nodes have been drained before you perform this step.
On each remote system (that is, all remote systems of all remote nodes), issue the same TARGET MAIN command that you issued in step 5.
On the new main system, issue TARGET OPERATIVE commands to make the connection with itself and all connections with remote nodes operative.
On each remote system (that is, all remote systems of all remote nodes), issue TARGET OPERATIVE commands for the original main (if it is to remain in the multisystem node) and new main systems.
Update the TARGET commands in the RACF parameter libraries for all systems on all nodes in the RRSF network to reflect the new main system.
If you fail to update the RACF parameter library for a system, the next time that system has its RACF subsystem restarted or is IPLed, the original TARGET commands will be issued, and requests and returned output will accumulate in the wrong OUTMSG workspace data set. However, RACF will issue appropriate error messages and prevent communications.

You can update the parameter libraries at the same time you issue the TARGET MAIN commands in steps 5, 6, and 7. This approach helps to ensure that no parameter library updates are missed.
If the original main system is still part of the multisystem node, (and assuming that you have updated its RACF parameter library as discussed in step 10) restart the RACF subsystem, TSO/E and JES on the original main system.