I came across the following explanation from IBM when setting up out RACF.
Looks like you could use mdisks if only VM shares the database, but you
still have to waste the rest of the space on the volumes.
.FO OFF
.RH ON
Item BDC000028340 NOM (DATE/20031125) IBM INTERNAL USE
ONLY
.SP 2
.RH OFF
TITLE:
RACF database build
*** SOURCE: UNITED STATES (ASKQQA) ***
-OPM2008 -5799WZY00 -ETRPRO -P3S3-03/11/24-22:13 -XE
************************** For IBM Use Only ****************************
* In RETAIN use CR CA to complete the call. *
* The use of CC will not notify the originator of a response! *
************************************************************************
RESPOND ELECTRONICALLY.
Route = 5799WZY00 .
Abstract: RACF database build
Welcome to zSeries Q A Technical Support - Electronic Q/A Service
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This queue is for VM and related products: DFSMS/VM,DIRMAINT,GCS,
ISPF/VM,PVM,RACF/VM,REXX/VM,RSCS,RTM/ESA etc.
To help us accurately respond to your GENERAL-USAGE (How-To) QUESTION,
please provide the Product Name,
Version, Release and Maintenance Level of all software that may be
related to this question. Include any other relevant info. that will
help expedite a response, eg. hardware installed, error messages etc.
Product Name Version/Release Maintenance Level
* * You can add the text of your question after you press enter * *
I am on z/VM V4R4 with RACF. I am attempting to build a racf database
that will be shared with several (level 1) VM systems. The documentation
in the RACF program directory (5739-A03) is a little confusing. It
recommends using a full volume mini disk but then says do not place any
mini disk on cylinder zero.
Can you start at cylinder zero?
Can you use another name in the racdsf command besides RACF and RACFBK
if you start at cylinder zero?
If I start at cylinder 1 will the z/VMs do the physical enqueuing to
reserve the volume?
If not how do I configure them to use that facility?
=EVANS, PAUL G -5799WZY00 -L40D/QAVM -P3S -03/11/24-22:38 -CT
=EVANS, PAUL G -568411202 -L40D/QAVM -P3S3-03/11/24-22:41 -CR
S5> SERVICE GIVEN= 39 SG/39/
S7> SERVICE GIVEN= 39 SG/39/
Action taken:
Hello Walter
The Program directory is a bit misleading. I will check into
this and have a further update for you in the morning.
Many Thanks
Paul Evans
action plan; investigate sharing between VM systems.
=EVANS, PAUL G -568411202 -L40D/QAVM -P3S3-03/11/25-16:23 -CR
S7> SERVICE GIVEN= 39 SG/39/
Action taken:
Hello Walter,
That Program Directory is somewhat confusing so I will try to sort
it out for you. When sharing a RACF database between VM systems,
you have a bit more choice as to how to do it than you have if
MVS is in the picture. If a MVS system will ever be sharing this
database then that makes a big difference. MVS does not understand
what a minidisk is and expects the real label in real cylinder zero
to have a VTOC pointer and all the MVS stuff. Thus is MVS is going to
share the RACF database, then you would want to use a Full Pack Minidisk
for the database addresses. A Full Pack Mini actually starts at Cylinder
Zero for the entire volume. The Minidisk statements in the directory
would be something like:
MDISK 200 3390 0 END RACF MWV
MDISK 300 3390 0 END RACFBK MWV
Please note that the MWV means Multi Write with Virtual Reserve/Release
The volume also needs to have the SHARED option in the SYSTEM CONFIG
to tell z/VM to use Real Reserve/Release.
In the RACF p^rogram directory, it mentions that you can use different
values than RACF and RACFBK by reassembling ICHRDSNT I believe.
The RACF System Programmer's Guide has further information about
that.
If you are just sharing between VM systems and MVS will never be
in the picture, then you can define the 200 and 300 as regular minidisks
but the EXACT same definition must be made on ALL z/VM systems and
again the MWV for the MDISK is needed and the SHARED option in the
SYSTEM CONFIG is needed. Note that reserve/release affects the
entire volume so it is not wise to place any other minidisks on that
volume. Of course, the backup database should be on a different physical
volume for availability purposes.
Hope this helps clarify things. If you have further
questions, please let us know.
Many Thanks
Paul Evans
action plan: await further update from Walter ( or closure )
-OPM2008 -568411202 -ETRPRO -P3S3-03/11/25-17:42 -XC
Reason For Closure:
Thank you. Beautiful explaination. Include that in
the Program Directory.
=EVANS, PAUL G -568411202 -L40D/-------P3S3-03/11/25-19:46 -AT
Action taken:
Hello Walter,
Many thanks for your comments. I will pass this info along to the
authors of the Program Directory for their consideration.
In the meantime, I will archive this for our reference.
Many Thanks
Paul Evans
action taken: closed by Walter
promote qavm
=EVANS, PAUL G -568411202 -L993/-------P3S3-03/11/25-19:52 -LC
Florian Bilek
<florian.bi...@gm
AIL.COM> To
Sent by: The IBM [email protected]
z/VM Operating cc
System
<[email protected] Subject
ARK.EDU> Sharing the RACF database in CSE
01/15/2009 10:11
AM
Please respond to
The IBM z/VM
Operating System
<[email protected]
ARK.EDU>
Dear all,
I am planning to setup RACF in a CSE environemnt. The CSE is on two
different processors. I have read in the Program Directory that in this c
ase
the RACF database mustn't be on a CSE formatted volume since it uses real
reserve/release CCWs. Therefore I can put it only on a real volume and
dedicate it to RACFVM or make a fullpack minidisk out of it.
Isn't that an overkill of dedicating two full 3390 addresses (5 GB) for 2
x
17 cylinder of data, the size of the database??
Could I put the Primary and the Backup at least on the same volume?
What would you recommend?
Thank you.
Best regards,
Florian
-----------------------------------------
******************************************************************
This message originated from the Internet. Its originator may or
may not be who they claim to be and the information contained in
the message and any attachments may or may not be accurate.
******************************************************************
