z/OS Security Server RACF System Programmer's Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Sysplex considerations

z/OS Security Server RACF System Programmer's Guide
SA23-2287-00

If you use the above procedure when your current RACF® system is enabled for sysplex communication, and the emergency ICHRDSNT is also requesting sysplex communication, you must re-IPL the entire RACF data sharing group to cause all the sharing systems to use the same new set of data sets. To do this:

  1. Bring down all systems in the sysplex that are using sysplex communication. If you do not bring down all the systems, the operator is not prompted and the system uses the same data set names as the rest of the data sharing group.
  2. When all the systems are down, re-IPL them. If an asterisk (*) has been specified for the data set names, one system prompts you for the data set names. The other systems use the same data set names.

It is a good idea to also have an emergency ICHRDSNT that has the sysplex communication and data sharing bits OFF (either instead of the above emergency ICHRDSNT with either bit on, or in addition to it). You can now open a single necessary member in non-sysplex-communication/datasharing mode, which might be necessary in some recovery scenarios.

Attention: This ICHRDSNT should specify a database other than the one used in your sysplex. (Perhaps a weekly backup of your sysplex database could be specified.) This is necessary because serialization used in non sysplex-communication/datasharing environment is incompatible with serialization in a sysplex-communication/datasharing environment. Bringing up a non sysplex-communication/datasharing system against your main sysplex database is likely to result in database corruption.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014