Both the primary and the backup databases are in error
In this situation, follow the procedure for the situation in which your primary database is in error and you have no backup database.
When you have the primary database, follow the procedure for the situation in which the backup database is in error and the primary database is unaffected.
If both the primary database and the backup database
are updated and users are prevented from logging on, (for example,
users are specifically revoked, the SETROPTS INACTIVE is set to one
day, and a weekend is passed and all users revoked.), and if you prefer
to fix your primary, instead of using the most recent offline backup
of your database (which might need a "replay" of all valid commands
since that backup was made), you might do the following.
- Use an emergency data set name table, which names as the emergency primary a new RACF® database, and, which names the production primary database as the emergency backup database. Make sure that you set the flag to duplicate updates for the backup.
- Re-IPL.
- Log on to IBMUSER. For example, all of your users in your production
database are revoked, however, on the emergency primary, IBMUSER is
not revoked, and is special. Note:
If IBMUSER on your primary production database is revoked, you might unrevoke IBMUSER right away, or after step 4.
- Issue RVARY SWITCH and then the emergency primary is the production primary (and IBMUSER's ACEE is still special). Continue with whatever is appropriate for your situation (for example, unrevoke your users, change SETROPTS INACTIVE back to a reasonable value, and so on).
- Resync your offline production backup database from your updated
primary database with IRRUT200 or IRRUT400. Note:
Because the production backup database is offline, the IRRUT200 options PARM=ACTIVATE and PARM=RENAMEACTIVATE are not applicable.
- IPL with your normal data set name table to activate the real production primary and backup databases.