The MDISK statements prove that the RACF database minidisks are not fullpack, hence CP wil not let Reserve/release propagate to the HW, hence RACFs in multiple z/VM systems can both perform updates concurrently (and destroy the database).
2011/1/18 Feller, Paul <pfel...@aegonusa.com> > Thanks Alan, I forwarded your reply to my co-worker and he came back with > some more comments/questions. I'm not sure what , if anything, he has heard > from the support center. > > I'm pretty sure that I have the sharing setup correctly. > From SYSTEM CONFIG > RDEV 96BD Type DASD Shared yes > RDEV 9AAF Type DASD Shared yes > > q dasd vmurce > DASD 96BD CP SYSTEM VMURCE 2 SHARED > Ready; T=0.01/0.01 14:49:12 > q dasd vmurcf > DASD 9AAF CP SYSTEM VMURCF 2 SHARED > Ready; T=0.01/0.01 14:49:15 > > From RACFVM entry in USER DIRECT > MDISK 0200 3390 0001 0200 VMURCF MWV XXXXXXXX XXXXXXXX XXXXXXXX > MDISK 1200 3390 0201 3138 VMURCF MW XXXXXXXX XXXXXXXX XXXXXXXX > MDISK 0300 3390 0001 0200 VMURCE MWV XXXXXXXX XXXXXXXX XXXXXXXX > MDISK 1300 3390 0201 3138 VMURCE MW XXXXXXXX XXXXXXXX XXXXXXXX > > rac rvary list > ICH15013I RACF DATABASE STATUS: > ACTIVE USE NUMBER VOLUME DATASET > ------ --- ------ ------ ------- > YES PRIM 1 RACF RACF.DATASET > YES BACK 1 RACFBK RACF.BACKUP > Ready; T=0.01/0.01 14:50:05 > > > I'm trying to figure out a method to perform the template conversion > without having to take down all three of the z/VM systems. I planned the > following steps > > 1) RVARY SWITCH all systems to the backup RACF database, leaving the > primary RACF database inactive > 2) LINK RACFVM 200 200 MW > 3) run RACFCONV > 4) RVARY ACTIVE DATASET(RACF.DATASET) on all systems > 5) RVARY SWITCH on all systems, leaving the backup RACF database inactive > 6) LINK RACFVM 300 300 MW > 7) run RACFCONV > 8) RVARY ACTIVE DATASET(RACF.BACKUP) on all systems > > I got through steps 1 and 2 but when I ran the RACFCONV exec, I got the > following error > > Blocksize for the RACF database at virtual address 200 was not 4096 or > could not be determined. The RACF database must be in restructed format > with a blocksize of 4096. > > I'm positive that I have a restructured database because I'm running the > RACFDBU utility daily to unload it, and that is one of the requirements for > using RACFDBU to unload the file. > > Paul Feller > AIT Mainframe Technical Support > > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On > Behalf Of Alan Altmark > Sent: Tuesday, January 18, 2011 2:34 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: RACF question > > On Tuesday, 01/18/2011 at 02:56 EST, "Feller, Paul" <pfel...@aegonusa.com> > wrote: > > I've got three z/VM LPARs that share a RACF database. It is not > > shared > with > > any other systems. > > > > The LPARs were running z/VM Version 5 Release 3.0, service level 1001 > (64-bit). > > I upgraded one of the z/VM LPARs to 5.4 this weekend. It's running > > z/VM > > > Version 5 Release 4.0, service level 0902 (64-bit). > > > > I'm now seeing this error when I attempt to do an LU command on the 5.4 > > LPAR. > > > > rac lu xxxxxxx > > IRR52115I Error during RACF manager processing. Return code is 36. > Reason code > > is 3. > > ICH51004I PARAMETER LIST ERROR DETECTED BY RACF MANAGER Ready(00012); > > T=0.01/0.01 14:03:09 > > > > I've tried several other RACF display commands (SR, RL) and they all > seem to > > work ok. It's also possible to do an ALU on the 5.4 LPAR and see the > results > > on one of the other LPARs. Logins and other security checks seem to > > be unaffected. > > > > RACF was initially installed on the 5.3 system. I verified that we > > have > > > VM64383 installed on the 5.3 systems. It was installed prior to RACF > being > > activated on 5.3 > > > > I have not run RACFCONV for zVM 5.4 yet. > > > > We have opened an issue with IBM support, but I thought I would ask on > the list > > if anyone has seen this before. Any thoughts? > > > From the Program Directory: > "The RACF database must have templates at the function level 540 for RACF > to function properly. If you are migrating from a previous release of RACF > to RACF FL540, you must run the RACFCONV EXEC to convert the existing > database templates to the current release." > > So run RACFCONV. > > As a reminder, the rules for sharing the database are: > 1. Each RACF database (primary & backup) must be on its own full-pack > minidisk or dedicated volume 2. If on a full-pack minidisk, the RDEV must be > defined with the SHARED option > 3. If on a full-pack minidisk, the MDISK must be defined with link mode MWV > > If any one of the above rules is not followed, then you may have database > corruption since the database will not have been protected by > RESERVE/RELEASE. > > Alan Altmark > > z/VM and Linux on System z Consultant > IBM System Lab Services and Training > ibm.com/systems/services/labservices > office: 607.429.3323 > alan_altm...@us.ibm.com > IBM Endicott > -- Kris Buelens, IBM Belgium, VM customer support
