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
