Chapter 13. Scenarios
This chapter contains scenarios that might help you in planning your mi Security Server (RACF) Release 2.
Migrating an Existing | RRSF | Network | to | Use | Multisystem | Nodes |
|
|
|
|
|
|
| |||||
If | an | existing | RRSF | network | contains | that | share | |||||||||||
RACF database, you can reconfigure the | ||||||||||||||||||
multisystem RRSF node. When you do this, | the | system that is | the |
| rec | |||||||||||||
existing RRSF network for the | RRSF nodes sharing a RACF |
| ||||||||||||||||
database must be the main system for the | multisystem | node. If | you | |||||||||||||||
system to be the main system, configure the receiver as the main s | ||||||||||||||||||
reconfigure the | network | with | a | new | main | system. |
|
|
|
|
|
| ||||||
Figure 24 | shows | an RRSF | network | that | does | not | have | multisystem | node | su | ||||||||
installed. MIAMI1, | MIAMI2, | and ORLANDO | are RRSF nodes. MIAMI1 and |
|
| |||||||||||||
MIAMI2 | share a | RACF | database, | and | ORLANDO uses profiles in the | RRSFDA | ||||||||||||
class |
| to | ensure | that | database | updates | are | sent | to | only | MIAMI1, | the |
node
MIAMI1
MIAMI1
MIAMI2
node
MIAMI2
RACF
database
ORLANDO
RACF
database
node
ORLANDO
Figure | 24. An RRSF Network Where Two Single System Nodes Share a RACF Database |
|
| |||||
This | scenario illustrates | how to | migrate the | RRSF network | shown | in | Figur | |
one implementing a multisystem node, after multisystem node | support | has | ||||||
installed on MIAMI1, MIAMI2, and | ORLANDO. Assume | that the | CVTSNAME | for |
| |||
MIAMI1 is SYSTEM1, and the | CVTSNAME | for MIAMI2 | is | SYSTEM2. |
|
|
|
On MIAMI1:
1.To ensure that RACF activity is stopped, take down TSO/E and JES. should drain all RACF work from the system.
Copyright IBM Corp. 1994, 1996 | 61 |