What I always do: - I give RACFVM two new minidisks, eg 1200 and 1300 In any userid you like: - I copy the exisitng RACF DB to new minidisks (RACFVM 200 & 300) using DDR - I LINK the new minidisks in Write as 200 and 300 - I LINK & ACCESS the minidisk with the new RACF code (maybe 5VMRAC40 505) - issue RACFCONV Then in RACFVM: - LINK the new minidisks as 1200 & 1300, - issue DEFINE 200 2200 and DEFINE 300 2300 - issue DEFINE 1200 200 and DEFINE 1300 300 - issue IPL 490 to restart RACF If all is fine (as it always was in my 20 years experience), I update the directory to alter the minidisk addresses: 1200 becomes 200, the old 200 F200, similar for the 300. Remark I don't DETACH minidisks, I use DEFINE to give them a new address: if RACF would fail to start, issuing a LINK may fail as RACF cannot control it, restoring the old addresses with DEFINE always works.
2009/7/3 Tobias Doerkes <tdoer...@hotmail.com> > Hi list, > > i found this posting while searching for information regarding RACFCONV. > > Just one question: How can i run RACFCONV on my 5.3.0 using the 5.4.0 > templates? I found no hints in the documentation ... > > On z/OS i am just using a different STEPLIB. > > Any help appreciated. > > Tobias Doerkes. > > > On Thu, 16 Aug 2007 16:06:23 -0400, Jim Bohnsack <jab...@cornell.edu> > wrote: > > >I'm bringing up z/VM 5.3 and came across a couple of items that aren't > >exactly plainly stated in the SDO doc. Both have to do with RACF. Also > >both are related to or caused by the fact that I really don't like to do > >a "big bang" type of upgrade. I build a new system on a 2nd level guest > >and then like to move it piece meal to my "test" lpar. In this case I > >am putting 5.3 in on the test system running z/VM 4.4. > > > >The first item or assist is one that I got from Colin Allison. I knew > >about the new database templates for RACF and, I guess, in recalling the > >trauma of having to convert the RACF DB to the structured format 10-15 > >years ago when you were making an irreversible change to the DB, I was > >nervous about doing it. Colin told me, however, that you can do the > >RACFCONV to add the new templates to the DB and then still use that DB > >running the older RACF. I did that and it worked just fine. I've been > >running the RACF that came with 4.4 with the 5.3 templates for a month > >or so with no problems. The only hint in the RACF prog. dir. is that if > >you are using a shared DB, you "must convert the templates from the > >system with the highest level of RACF". > > > >The 2nd item that caught me is that today I decided to put CP 5.3 and > >the new RACF on the test lpar. RACF woudn't run. I had ipled with > >NOAUTOLOG and then logged onto RACFVM using the directory pw in order to > >switch to the new 490 and 305 disks. RACSTART would end with the rather > >crytpic message "RACF is not defined to the Z/VM system". The problem > >is that the SYSTEM CONFIG file didn't have the new character string in > >it containing 5VMRAC30 that was inserted with the ENABLE command when I > >installed on the 2nd level system. It only had the old ENABLE statement > >containing the PRODID of 5767002P. I added the line containing 5VMRAC30 > >and it worked just fine. > > > >I just thought I'd pass on these tips for anyone who likes to upgrade a > >system in a little more granular manner than all at once. > > > >Jim > > > >Jim Bohnsack > >Cornell University > >(607) 255-1760 > >jab...@cornell.edu > >========================================================================= > -- Kris Buelens, IBM Belgium, VM customer support
