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


Example 6. Copying using a two-stage option

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

In this example, you want to copy the active RACF® database to a larger database at a time when there is still some activity on your system that might result in updates to the RACF database. Because you are using the copy on a test system, not on a production system, The IRRUT400 copy does not need to be an exact copy of the active RACF database.

You do not want to use LOCKINPUT because you do not want to receive errors that result from update attempts to the active database while LOCKINPUT is in effect. Neither do you want to be subject to the unpredictable results that using NOLOCKINPUT can cause. You prefer to use a two-stage process, first using IRRUT200, then IRRUT400. You understand that the active database that is used as input to IRRUT200 and the output database from IRRUT400 will be out-of-synch if updates occur during that interval and that you will lose those updates if you decide to use the IRRUT400 copy as your active database.
//VERIFY    JOB
//STEP1     EXEC   PGM=IRRUT200
//SYSRACF   DD     DSN=SYS1.RACF,DISP=SHR
//SYSUT1    DD     DSN=TEMP.CPY200,DISP=OLD
//SYSUT2    DD     SYSOUT=A
//SYSPRINT  DD     SYSOUT=A
//SYSIN     DD     *
    END
/*
//STEP2    EXEC PGM=IRRUT400,PARM='NOLOCKINPUT,FREESPACE(20)'
//SYSPRINT  DD  SYSOUT=A
//INDD1     DD  DSN=TEMP.CPY200,DISP=OLD
//OUTDD1    DD  DSN=SYS2.RACF,DISP=(,KEEP),
//              VOL=SER=VOL1,
//              SPACE=(CYL,10,,CONTIG),
//              DCB=DSORG=PSU,
//              UNIT=SYSDA                                    

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014