I am running z/OS on zPDT on my Linux server. I want to test out some RACF commands, but want to be able to recover if I get it wrong. What can I do?
The product zSecure Admin offers RACF Offline can be used by those who have the license.
I do not have this product so I need a different way.
I am running a single user z/OS image. For anything more complex than this, talk to the experts.
Background to RACF
RACF has a database, typically SYS1.RACFDS. For availability you can have a backup RACF database, typically SYS1.RACFDS.BACKUP. Typically these are both updated when changes are made to the RACF environment. I would call this a duplexed dataset.
You can make a copy of a RACF database using the RACF utility IRRUT200. This takes a lock on database for the duration of the copy and ensures the copy is consistent. If you use other tools to backup the primary database, and there were concurrent database updates, the backup may not be consistent. You risk a partial update, and an inconsistent database.
Changing your RACF
You can use the RVARY command (TSO and operator) to change the RACF data sets. You can setup controls for the RVARY command.
If you use SETROPTS LIST it will list the RACF options being used. Mine has (near the bottom)
DEFAULT RVARY PASSWORD IS IN EFFECT FOR THE SWITCH FUNCTION.
...
DEFAULT RVARY PASSWORD IS IN EFFECT FOR THE STATUS FUNCTION.
In this case the default password is YES
You will get a prompt
ICH703A ENTER PASSWORD TO SWITCH RACF DATASETS JOB=IBMUSER USER=IBMUSER
If you have an I/O problem with the SYS1.RACFDS database
You can
- switch to use the backup, and stop duplex updates.
- fix the problem. Perhaps delete the data set and recreate it on a different device.
- copy the backup dataset using IRRUT200 to the newly allocated dataset
- activate the newly allocated dataset activate the duplex updates.
Updates to the RACF database are written to SMF 80 records.
If you make mistakes with your commands
Some RACF command changes you can undo, for example, you can use an alter command to set a new value. To be able to undo the change you need to know what the original value was, so it is always a good idea to display a resource before you change or delete it.
If you delete a record there is no easy way of undoing it.
Rob van Hoboken suggested the following.
Plan A – online switch
Display the status
#rvary list
This gave me
ICH15013I RACF DATABASE STATUS:
ACTIVE USE NUM VOLUME DATASET
------ --- --- ------ -------
YES PRIM 1 A3CFG1 SYS1.RACFDS
YES BACK 1 A3CFG1 SYS1.RACFDS.BACKUP
This shows both data sets are active and which is the primary and which ise the backup.
Switch off your RACF DUPLEX (backup) data set
#RVARY INACTIVE,DATASET(SYS1.RACFDS.BACKUP)It prompts with
ICH702A ENTER PASSWORD TO DEACTIVATE RACF JOB=RACF USER=START1
I didnt know the password, but I replied r xx,YES and it worked!
Run the commands that you hope will work.
If the commands do not work successfully
If the commands do not work successfully, make the backup active and switch to it.
#RVARY ACTIVE,DATASET(SYS1.RACFDS.BACKUP)
#RVARY SWITCH See the command RVARY (Change status of RACF database) .
After you have switched to the backup, make the primary inactive
#RVARY INACTIVE,DATASET(SYS1.RACFDS)and copy the backup into the primary using IRRUT200
//IBMUSRAC JOB 1,MSGCLASS=H
//S1 EXEC PGM=IRRUT200 PARM=ACTIVATE
//SYSRACF DD DISP=SHR,DSN=SYS1.RACFDS.BACKUP
//SYSUT1 DD DISP=SHR,DSN=SYS1.RACFDS
//SYSUT2 DD SYSOUT=*
//SYSIN DD *
//SYSPRINT DD SYSOUT=*
First run it without PARM=ACTIVATE. If this works successfully, then use PARM=ACTIVATE, this take a lock during the copy, and then activates the SYSUT1 data set, so both are now active.
This gave the output
IRR62005I - IDCAMS REPRO copied SYSRACF to the work data set SYSUT1
ICH15013I RACF DATABASE STATUS:
ACTIVE USE NUM VOLUME DATASET
------ --- --- ------ -------
YES PRIM 1 A3CFG1 SYS1.RACFDS.BACKUP
YES BACK 1 A3CFG1 SYS1.RACFDS
ICH15020I RVARY COMMAND HAS FINISHED PROCESSING.
The #RVARY LIST gave, as expected
ICH15013I RACF DATABASE STATUS:
ACTIVE USE NUM VOLUME DATASET
------ --- --- ------ -------
YES PRIM 1 A3CFG1 SYS1.RACFDS.BACKUP
YES BACK 1 A3CFG1 SYS1.RACFDS
Which shows it has worked.
If the commands do work successfully
If the commands do work successfully, you need to bring the backup up to date with the primary.
//IBMUSRAC JOB 1,MSGCLASS=H
//S1 EXEC PGM=IRRUT200,PARM=ACTIVATE
//SYSRACF DD DISP=SHR,DSN=SYS1.RACFDS
//SYSUT1 DD DISP=SHR,DSN=SYS1.RACFDS.BACKUP
//SYSUT2 DD SYSOUT=*
//SYSIN DD *
//SYSPRINT DD SYSOUT=*
The #rvary active command.
I would be careful about using the #RVARY ACTIVE command. If you copy a RACF data set, then use the RVARY ACTIVE command to make it available, there is a small window where changes made to the active RACF data base are not made to the offline one. You could tell people “do not issue any commands while this work is going on”, but the RACF database is updated during normal work, for example with profile use counts, and last used date.
Plan B – REIPL with different data sets.
- Convert to using IRRPRMxx PARMLIB member definitions to specify the data set names, instead of using a load module. See RACF setup, and changing the RACF dataset
- Copy the RACF database to a recovery RACF data set using IRRUT200
- Create a new IRRPRMxx member pointing to your recovery data set.
- Create a new IEASYSxx member to use the RACF=xx member
- You may have to create a new LOADxx member in SYS1.IPLPARM to point to the new IEASYSxx member.
- REIPL, and specify the appropriate LOADxx suffix.
- Fix the problem; copy from the recovery into the SYS1.RACFDS dataset and SYS1.RACFDS.BACKUP, so the primary and backup are the same.
- Reipl using the normal IPL parameters
You could use the emergency stand-alone one pack system SARES1, but this may not have access to all of the data sets due to SMS and catalogs.
ColinPaice 