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


The primary database is in error, the backup database is unaffected

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

In this situation, follow this procedure:
  1. Ensure that the backup is active.
  2. Take one of the following actions:
    1. Issue RVARY SWITCH (the backup is now the new primary).
    2. Vary offline the device that the primary resides on. RACF® automatically does an RVARY SWITCH.
  3. Take one of the following actions:
    1. Correct the problem on the original primary, using BLKUPD.
    2. If the device is accessible, copy the backup (new primary) onto the original primary, using IRRUT200 or IRRUT400.
    3. If the device is inaccessible, allocate, catalog and copy a replacement primary onto a different DASD device, using IRRUT200 or IRRUT400. You must catalog it on all systems sharing the database.
  4. Issue RVARY ACTIVE for the original primary or replacement primary.
  5. If you used option 3.b with IRRUT400 with LOCKINPUT, run IRRUT400 with UNLOCKINPUT to unlock your new primary (original backup).
  6. Issue RVARY SWITCH.
  7. Issue RVARY ACTIVE for the backup (original backup).
Note: After an RVARY SWITCH when your backup is inactive, your primary and backup databases might become out of synch. If this is a concern to you, the safest approach is to use option 3.b, and use IRRUT400 with LOCKINPUT. But note that even in this scenario your databases could become out of synch between steps 6 and 7.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014