Discussion:
Moving RACF databases
(too old to reply)
Angel Tamayo
17 years ago
Permalink
Hi,

I need to move RACF databases to another volume. From RACF System
programmers manual I read chapter Recovery Procedures that could be useful,
but I wonder if anybody of you guys has any other procedure that could be
better.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
John Laubenheimer
17 years ago
Permalink
The official "supported" method to move a RACF database is by using the
utility IRRUT400. This utility provides the proper ENQ and locking mechanisms
to prevent updates to the database while the copy is in progress. And, it's
simple enough to use.

However, if you can afford the downtime, and have a 2nd "completely"
independent operating system image, the database can be moved using
FDR/DFSMSdss and/or IEBGENER/ICEGENER/SYNCGENR. This is
officially "unsupported", but works, provided the databases are not in use (in
any way) while the copy is in progress.

My opinion, always use IRRUT400.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Errol
17 years ago
Permalink
...
Very true. If you don't have FDR you can also migrate all other data
from the Volume, mirror it, then issue a P/DAS command to switch to
the new device address.
it depends on your reasons for moving it.

1. IOACTION STOP,DEV=0100
Quiesce I/O to primary device
2. SWAP 0100,0200
Swap primary and secondary UCBs
3. IOACTION RESUME,DEV=0200
Resume I/O to secondary device

Try the above on a test system first, depending what else is on the
volume you are switching

If you are moving it and renaming it, don't forget to zap the ICHRDSNT
in SYS1.LINKLIB to the new name
R.S.
17 years ago
Permalink
...
My opinion, is to *avoid* IRRUT400 whenever possible. It is possible in
this case.
I would suggest IRRUT200 as first tool for copying/backuping RACFdb.
UT400 is needed when source and target volumes are unlike (who's still
using 3380's ?), database enlarge, split/merge and some others.

In this cas I would use ...IEBGENER.

Scenario:
RVARY SWITCH -> backup DB becomes PRIMARY, primary is "freed".
move primary db as regular PS file, having in mind that it have to be
single extent and the same same.
RVARY ACTIVE for just-moved primary. It will play BACKUP role.
RVARY SWITCH -> backup DB which plays role of PRIMARY is freed, primary
database which plays role of BACKUP bacomes PRIMARY.
move backup db as regular PS file...
RVARY ACTIVE
now primary db is PRIMARY, backup db is BACKUP.

Explanation: the text above is "case sensitive" <g>
PRIMARY, BACKUP - means actual role of the database file.
primary, backup - "original" role of the files
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Loading...