shipped on MAINT 2CC
David
Original Message Subject: [IBMVM] z/VM Directory LocationFrom: Howard Rifkind vmes...@yahoo.comDate: Wed, May 06, 2009 11:56 pmTo: IBMVM@LISTSERV.UARK.EDU
Another Senior moment...in z/VM 5.3 which of Maint's minidisks is the directory on...I don't
Another Senior moment...
in z/VM 5.3 which of Maint's minidisks is the directory on...
I don't currently have a z/VM system to work on and forgot this...
Thanks
Two questions , has anyone added CRYPTO statements to their VM directory,
even tho we do not have VM here any longer when we go to DR site we run
under VM
hence 2nd question, can anyone point me towards the correct manual that may
have this info
thanks,
Augie
August,
We use CRYPTO statements in the VM directory. Here's an example from a
z9. z890/z990's use the same syntax. z800/z900's are different.
CRYPTO DOMAIN 00 APDED 1
The Creating and Updating a User Directory chapter in CP Planning and
Administration has the syntax. That's Chapter 17
Subject
SystemRe: VM directory
[EMAIL PROTECTED]
ARK.EDU
Unsurprisingly, it looks as if I need to clarify a little ...
Tom's not happy with, assuming R/R support for Reloc 0 Minidisks. My
take here is that CP is not unilaterally adding any R/R activity - if the
disk at Reloc 0 is a VSE minidisk and VSE doesn't issue any R/R then CP
won't either -
Well Alan, as you've, Opened the floor for discussion - here's my two
penn'orth on how I think it SHOULD work.
I think we're all pretty-much agreed on Virtual R/R support within a
single VM image, it's when to issue a REAL R/R that's the sticking-point.
I would contend that a REAL R/R should
, 2006 9:02 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM directory entry for shared DASD
Well Alan, as you've, Opened the floor for discussion -
here's my two =
penn'orth on how I think it SHOULD work.
I think we're all pretty-much agreed on Virtual R/R support within a
single VM
On 9/7/06, Schuh, Richard [EMAIL PROTECTED] wrote:
I am not even sure that XLINK ought to be in the equation. Requiring it
restricts the functionality to CSE environments.
XLINK is just the part that extends the LINK semantics over multiple
systems with shared DASD. It does not require
: VM directory entry for shared DASD
On 9/7/06, Schuh, Richard [EMAIL PROTECTED] wrote:
I am not even sure that XLINK ought to be in the equation.
Requiring it restricts the functionality to CSE environments.
XLINK is just the part that extends the LINK semantics over multiple
systems
I don't think you'd want to issue real R/R whenever the subject
minidisk begins on real cylinder zero. I say this because VM
systems which host VSE typically have *many* mdisks which begin with
real cylinder 0. Do we really want real reserve/release to occur for
such volumes, especially when
Title: VM directory entry for shared DASD
Hello David,
It is my understanding
the to share DASD across systems under z/VM, you need to have the
MWV on the MDISK and
the VSE lock file to ensure integrity.
The MWV will invoke the CP RESERVE/RELEASE
that is
required by the VSE Lock
On 9/6/06, Wakser, David [EMAIL PROTECTED] wrote:
Please settle an argument: if a DASD volume is to be shared in WRITE
mode between two VSE systems running under VM, should the MDISK statement
specify MWV or MW?
Why settle... can we not just disagree? ;-)
If you have multiple systems
: Wednesday, September 06, 2006 8:33 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM directory entry for shared DASD
On 9/6/06, Wakser, David [EMAIL PROTECTED] wrote:
Please settle an argument: if a DASD volume is to be shared in
WRITE mode between two VSE systems running under VM, should
Title: RE: VM directory entry for shared DASD
Mike:
Firstly, some of these do NOT start at cylinder 0. Does that mean they cannot be shared in WRITE mode? Secondly, I am not EXPECTING cross-system protection from CP, am I? Aren't I expecting it from the VSE systems (via the lockfile
Title: RE: VM directory entry for shared DASD
Rob:
So, if the shared disk does NOT start ay Cyl 0 but at Cyl 1, the MWV is worthless and I cannot share disks?
I think what I need to understand is: who says CP has to issue any reserve/release? Does not VSE (via the lock file or some
Title: RE: VM directory entry for shared DASD
You
are all getting me more confused... Why not ALWAYS use MWV for the shared disks?
What does it hurt?
-Original Message-From: The IBM z/VM Operating
System [mailto:[EMAIL PROTECTED]On Behalf Of Wakser,
DavidSent: Wednesday
Title: RE: VM directory entry for shared DASD
And Dont you have to have SHR on the add statements of
those disks that are really shared?
Ed Martin
Aultman Health Foundation
330-588-4723
[EMAIL PROTECTED]
ext. 40441
From: The IBM z/VM Operating System
[mailto:[EMAIL
Title: RE: VM directory entry for shared DASD
I hope this helps
From the z/VM 5.2 Migration Guide
4.3.1 Reserve/Release Considerations for
VSE
z/VM supports virtual reserve/release for
minidisks that are not a full pack. Therefore, the cross-system communication
(also called
On 9/6/06, Wakser, David [EMAIL PROTECTED] wrote:
So, if the shared disk does NOT start ay Cyl 0 but at Cyl 1, the MWV
is worthless and I cannot share disks?
If you want the VSE guests in this LPAR to use reserve/release, you
need MWV to have CP simulate it (that's the *virtual*
Title: RE: VM directory entry for shared DASD
Rob:
Yes, you have actually underscored what I have been saying: except for the volume containing the lock file, no DASD within a single VM image needs MWV specified!
Thanks.
David Wakser
-Original Message-
From: Rob van der Heij
Title: RE: VM directory entry for shared DASD
Hello David,
I think that your
statement is incorrect. The logic
is there for VSAM, but for the SD and DA files you will need
the R/R. I am thinking
about the Share Power files, DTSFILE, and any Sd files that you have.
There were
Title: RE: VM directory entry for shared DASD
Again
if the lock file is a z/VM vdisk (0 access time) and z/VM isn't going to
'makeup' a RESERVE/RELEASE unless VSE asks for it, I just don't see the problem
with MWV on all of the 'potentially' shared mdisks. By adding the SHR parm on
the VSE
Title: RE: VM directory entry for shared DASD
Hello Thomas Huegel,
I agree with you. I am thinking that the risks out weight the
benefits, unless these are full VSAM packs.
Even then, I
still have MWV on the shared ones we have.
Ed Martin
Aultman Health Foundation
330-588-4723
In answer to your question on why MWV...
Back in the late '80s, I think it may have been with VSE/SP 4, IBM
started sending out the PSRs with the recommendation of MWV for all VSE
minidisks. I guess that it was more of a safety kind of thing. That
is, with MWV on all minidisks, you can't
Title: RE: VM directory entry for shared DASD
There is
probably some slight overhead introduced by making a disk MWV. Whenever a
guesttries to perform I/O on the disk, CP is going to have to check to see
if some other guest has reserved it, even if the guests are using some
PROTECTED]
Behalf Of Alan Altmark
Sent: Wednesday, September 06, 2006 12:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM directory entry for shared DASD
On Wednesday, 09/06/2006 at 01:10 AST, Wakser, David
[EMAIL PROTECTED] wrote:
I believe it is probably overhead that should be avoided
Aultman Health Foundation
330-588-4723
[EMAIL PROTECTED]
ext. 40441
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
On
Behalf Of Schuh, Richard
Sent: Wednesday, September 06, 2006 3:42 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM directory entry
28 matches
Mail list logo
