Re: z/VM Directory Location
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 currently have a z/VM system to work on and forgot this...Thanks
z/VM Directory Location
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
VM directory
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
Re: VM directory
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 in the z/VM 5.3.0 version of the book. Dennis O'Brien I don't have a girlfriend. I just know a girl who would get really mad if she heard me say that. -- Mitch Hedberg -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of August Carideo Sent: Tuesday, August 14, 2007 09:22 To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] VM directory Importance: High 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
Re: VM directory
thank you O'Brien, Dennis L Dennis.L.O'Brien To @bankofamerica.co IBMVM@LISTSERV.UARK.EDU m cc Sent by: The IBM z/VM OperatingSubject SystemRe: VM directory [EMAIL PROTECTED] ARK.EDU 08/14/2007 01:00 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU 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 in the z/VM 5.3.0 version of the book. Dennis O'Brien I don't have a girlfriend. I just know a girl who would get really mad if she heard me say that. -- Mitch Hedberg -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of August Carideo Sent: Tuesday, August 14, 2007 09:22 To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] VM directory Importance: High 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
Re: VM directory entry for shared DASD
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 - but if VSE DOES, feel the need then the R/R will be honoured by CP and protection from other systems running in other images will be provided - just as it would be in the, Real World. This being the case, I don't see how with R/R propagation at the, real level we're significantly worse off than we are today - if VSE doesn't do it then CP doesn't do it - if VSE DOES do it then it gets the protection it's asking for instead of a weak subset of what it's expecting. There IS a new impac t (in terms of responsiveness) for users of other minidisks that share the real volume - but I would far rather manage the impact of coping with the consequences of, safe behaviour than manage the impact of coping with the consequences of a data corruption caused by CP's failure to fully honour a request from a guest asking for short-term exclusive use of a minidisk. (I contend that the CPU overhead of checking for the need to drive R/R support is not worthy of consideration - we are talking a few tens of instructions increase in the normal pathlength at most and - to my mind - the benefit of consistent behaviour far outweighs the cost of these few instructions.) Richard's appears to be unhappy with me suggesting that XLINK has a part to play here. I think that Rob's response should have settled these concerns but, just to make sure, a reminder that XLINK extends the protection against, unintentional multi-write access that one gets on a single system to cover multiple systems sharing a single real volume. It does this via a, Compare-and-Swap mechanism on a cylinder-map that resides on the real volume and it requires no additional hardware or (onc e set up) support process. Again, as it's intrinsically dangerous to have multiple CP images sharing minidisks on a real volume without the protection of XLINK, and XLINK is part of the base system, why on Earth would anyone wish to operate a production system without it? That being the case, it seems natural to me to deliver real R/R in support of any virtual R/R issued by a guest to any minidisk with a, V in the MDISK statement (or starts at Cylinder 0) that's on a real volume under the control of XLINK. In the vast majority of cases the non-reloc-0 minidisks will be CMS minidisks and (because CMS doesn't use R/R) there will not be any reason to code the, V anyway - but having the support in CP gives u s the CAPABILITY (which we don't currently have) should we wish to make use of it for - say - a VSE LOCKFILE residence minidisk. (At least nobody's yet taking me to task for suggesting that volumes unde r XLINK control should default to SHARED when ATTACHED to SYSTEM! grin) Hopefully I've been able to make my points somewhat more clearly this tim e around. Tom and Richard - through your comments, thanks for giving me the opportunity to do so. Regards Jeff
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 image, it's when to issue a REAL R/R that's the sticking-point. I would contend that a REAL R/R should be issued whenever the virtual R/R is honoured on ANY minidisk associated with a real volume (that supports real R/R) that's under control of cross-system link (aka XLINK) or whenever the subject minidisk begins on real cylinder zero. I would like to retain the V appendage to explicitly tell CP which minidisks are subject to virtual R/R support because this would protect m e from, denial of service behaviour based on someone realising that their CMS minidisk is on a cross-system-linked disk and that they can therefore mess things up by issuing a RESERVE CCW. However, this is unlikely enough that I'd be willing to be persuaded that CP should simply honour all R/R activity on all minidisks under the scheme outlined above. (Maybe relocat e- zero should imply, V but it needs to be explicitly coded on non-relocat e zero?) While I was at it, I would also extend the automatic assignment of SHARED status to any real volume that's put under XLINK control at the time that it's ATTACHED to SYSTEM, with (of course) the option of using the appropriate SET command to change this to cater for, unusual circumstances. I find the current mechanisms for establishing SHARED status on real packs tiresome - and it'd be so natural to assume shared for XLINK packs. OK, let's see what others think :-) Regards Jeff Gribbin
Re: VM directory entry for shared DASD
I am not even sure that XLINK ought to be in the equation. Requiring it restricts the functionality to CSE environments. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Jeff Gribbin, EDS Sent: Thursday, September 07, 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 image, it's when to issue a REAL R/R that's the sticking-point.= I would contend that a REAL R/R should be issued whenever the virtual R/R= is honoured on ANY minidisk associated with a real volume (that supports = real R/R) that's under control of cross-system link (aka XLINK) or whenever the subject minidisk begins on real cylinder zero. I would like to retain the V appendage to explicitly tell CP which minidisks are subject to virtual R/R support because this would protect m= e from, denial of service behaviour based on someone realising that their= CMS minidisk is on a cross-system-linked disk and that they can therefore= mess things up by issuing a RESERVE CCW. However, this is unlikely enough= that I'd be willing to be persuaded that CP should simply honour all R/R = activity on all minidisks under the scheme outlined above. (Maybe relocat= e- zero should imply, V but it needs to be explicitly coded on non-relocat= e zero?) While I was at it, I would also extend the automatic assignment of SHARED= status to any real volume that's put under XLINK control at the time that= it's ATTACHED to SYSTEM, with (of course) the option of using the appropriate SET command to change this to cater for, unusual circumstances. I find the current mechanisms for establishing SHARED status on real packs tiresome - and it'd be so natural to assume shared = for XLINK packs. OK, let's see what others think :-) Regards Jeff Gribbin
Re: 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 with shared DASD. It does not require additional communication channels like ISFC or sharing of spool volumes. Obviously if you're sharing volumes on mini disk level, you'd want something to ensure the CP directory on all participating systems is the same (or otherwise matches). Rob
Re: VM directory entry for shared DASD
No argument there. Jeff's post seemed to be pretty xlink-specific. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Rob van der Heij Sent: Thursday, September 07, 2006 10:03 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: 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 with shared DASD. It does not require additional communication channels like ISFC or sharing of spool volumes. Obviously if you're sharing volumes on mini disk level, you'd want something to ensure the CP directory on all participating systems is the same (or otherwise matches). Rob
Re: VM directory entry for shared DASD
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 you consider that VSE has implemented its own locking mechanism (the lock file)? In VSE literature from the '80's, it was said that one should use MWV only for the lock file itself. Nowadays VM literature says to use MWV for all shared VSE minidisks. See the following excerpt, quoted in a posting in the vse listserv, 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 the lock file) volume does not have to be defined as a full pack. MDISK statements for all DASD you want to mount to VSE as shared (in other words, you want to use the S operand of the IPL ADD statement) must include the V suffix on the link mode. That is, the link mode must be MWV. If this is not done, VSE issues MSG 0I23I for the minidisks that do not have link mode MWV on their MDISK statements. At 09:02 AM 9/7/2006, you wrote: I would contend that a REAL R/R should be issued whenever the virtual R/R is honoured on ANY minidisk associated with a real volume (that supports real R/R) that's under control of cross-system link (aka XLINK) or whenever the subject minidisk begins on real cylinder zero. Tom Cluster County of Sonoma Santa Rosa, CA (707) 565-3384 (Tuesdays and Wednesdays only)
Re: VM directory entry for shared DASD
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 file. Now my question I would like to add, I have two separate CPUs using the same DASD (some EMC system to be exact). I have two z/VM systems that have access to the same VSE systems. Will the lock file on VSE protect the files? Both have MWV for the Mdisk and MW for the links. If CPU A starts TEST and CPU B starts PROD, will the lock file be enough to ensure integrity? TEST * TEST MDISKS * * MDISK 740 3390 000 3339 RAM040 MWV ALL VSETSW VSETSMW PROD * * SHARED VOLUMES * LINK TEST 740 740 MW Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 From: owner-[EMAIL PROTECTED] [mailto:owner-[EMAIL PROTECTED]] On Behalf Of Wakser, David Sent: Wednesday, September 06, 2006 10:58 AM To: VSE Discussion List Subject: VM directory entry for shared DASD -- Note - this is cross-posted to VM list! All: 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? I recall that the V is only needed (or desired) when you wish to invoke CP RESERVE/RELEASE. However, if a VSE lock file is being used (or there is some other method for ensuring integrity), then the V is not needed. Can anyone settle this dispute? David Wakser InfoCrossing Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
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 the MDISK statement specify MWV or MW? Why settle... can we not just disagree? ;-) If you have multiple systems on the same z/VM, you need MWV to make sure that CP will intercept reserve / release and emulate it. You could not have all virtual machines do real reserve release because the hardware would not be able to distinguish between virtual machines (only sees which LPAR does it). When the virtual machines are on different LPARs (or machines) you need the disk to start at cylinder 0 to ensure that CP will indeed pass the reserve/release to the real device (and I am not sure whether you have to define it as SHARED in the configuration file, but you prolly want to disable MDC anyway). When you more than one VSE in the z/VM LPAR and another one outside the LPAR (native or under z/VM, same machine or other machine) you need MWV *and* start at cyl 0 to make sure that CP will keep the guests apart, and will issue the real reserve/release that comes from that. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: VM directory entry for shared DASD
For real reserve/release to be used for cross-system protection, the minidisks must be full-pack, not just start at cylinder 0, and SHARED must be on for the rdev. Mike Harding EDS VM National Capability 134 El Portal Place Clayton, Ca. USA 94517-1742 * phone: +01-925-672-4403 * Fax: +01-925-672-4403 * mailto:[EMAIL PROTECTED] * mailto:[EMAIL PROTECTED] (personal) Note: For 2006, I am off on Fridays with even Julian dates and Mondays with odd ones. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: 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 the MDISK statement specify MWV or MW? Why settle... can we not just disagree? ;-) If you have multiple systems on the same z/VM, you need MWV to make sure that CP will intercept reserve / release and emulate it. You could not have all virtual machines do real reserve release because the hardware would not be able to distinguish between virtual machines (only sees which LPAR does it). When the virtual machines are on different LPARs (or machines) you need the disk to start at cylinder 0 to ensure that CP will indeed pass the reserve/release to the real device (and I am not sure whether you have to define it as SHARED in the configuration file, but you prolly want to disable MDC anyway). When you more than one VSE in the z/VM LPAR and another one outside the LPAR (native or under z/VM, same machine or other machine) you need MWV *and* start at cyl 0 to make sure that CP will keep the guests apart, and will issue the real reserve/release that comes from that. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: VM directory entry for shared DASD
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)? And where do you expect SHARED to be specified? I don't believe you mean on the VSE ADD device statements, do you? David Wakser InfoCrossing -Original Message- From: Harding, Mike [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 06, 2006 11:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM directory entry for shared DASD For real reserve/release to be used for cross-system protection, the minidisks must be full-pack, not just start at cylinder 0, and SHARED must be on for the rdev. Mike Harding EDS VM National Capability 134 El Portal Place Clayton, Ca. USA 94517-1742 Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: VM directory entry for shared DASD
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 internal locking mechanism) handle this? Why does CP need to be involved? BTW, there are no LPARS involved here. And the reason why not all shared packs start on cyl 0 is because we wanted to retain uniqueness of DASD volids whenever possible. Thus, the VSE DASD starts at REAL CYL. David Wakser -Original Message- From: Rob van der Heij [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 06, 2006 11: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 the MDISK statement specify MWV or MW? Why settle... can we not just disagree? ;-) If you have multiple systems on the same z/VM, you need MWV to make sure that CP will intercept reserve / release and emulate it. You could not have all virtual machines do real reserve release because the hardware would not be able to distinguish between virtual machines (only sees which LPAR does it). When the virtual machines are on different LPARs (or machines) you need the disk to start at cylinder 0 to ensure that CP will indeed pass the reserve/release to the real device (and I am not sure whether you have to define it as SHARED in the configuration file, but you prolly want to disable MDC anyway). When you more than one VSE in the z/VM LPAR and another one outside the LPAR (native or under z/VM, same machine or other machine) you need MWV *and* start at cyl 0 to make sure that CP will keep the guests apart, and will issue the real reserve/release that comes from that. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: VM directory entry for shared DASD
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, September 06, 2006 11:44 AMTo: IBMVM@LISTSERV.UARK.EDUSubject: Re: VM directory entry for shared DASD I just had a lucid moment; I recall that only the device which contained the VSE lock file needed "MWV". Anyone else who recalls that? David Wakser Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. ella for Spam Control has removed 6907 VSE-List messages and set aside 4584 VM-List for meYou can use it too - and it's FREE!www.ellaforspam.com
Re: VM directory entry for shared DASD
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 PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, September 06, 2006 12:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: 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, David Sent: Wednesday, September 06, 2006 11:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM directory entry for shared DASD I just had a lucid moment; I recall that only the device which contained the VSE lock file needed MWV. Anyone else who recalls that? David Wakser Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. ella for Spam Control has removed 6907 VSE-List messages and set aside 4584 VM-List for me You can use it too - and it's FREE!www.ellaforspam.com
Re: VM directory entry for shared DASD
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 the lock file) volume does not have to be defined as a full pack. MDISK statements for all DASD you want to mount to VSE as shared (in other words, you want to use the S operand of the IPL ADD statement) must include the V suffix on the link mode. That is, the link mode must be MWV. If this is not done, VSE issues MSG 0I23I for the minidisks that do not have link mode MWV on their MDISK statements. Specifying MWV does not result in any additional overhead because z/VM does not do a reserve/release to any pack unless the guest asks it to. VSE only does a reserve/release to the cross-system communication file (the lock file) after IPL. Note that if the cross-system communication file (the lock file) is shared by more than one CPU, SHARED must be YES on the RDEVICE statement in the system configuration file. Also, for sharing a volume concurrently between real and virtual machines, the volume must be defined as a full-pack minidisk. Note: z/VM supports virtual reserve/release for the virtual disks in storage function. Virtual disks in storage are temporary FBA minidisks simulated in system storage rather than mapped to real DASD. Therefore, a virtual disk in storage may be faster than other minidisks because it avoids the overhead of I/O operations. VSE guests may benefit from this function by using a virtual disk in storage instead of a permanent minidisk to store label information areas and the cross-system communication file (the lock file). The virtual disk in storage function may be used by a guest running any supported version or release of VSE. 0I23I DASD ON cuu NOT PHYSICALLY SHARABLE Explanation: An ADD command with the SHR option was given for the disk volume at the indicated address. This disk volume is attached to a control unit that does not support RESERVE/RELEASE commands. System Action: For data integrity reasons the SHR option is not reset. The system continues processing. Programmer Response: If the message occurred during system start-up by ASI, you may have to correct the applicable IPL proce- dure to avoid this message in the future. Operator Response: Report this message to your programmer. Gary Gary L. Shiminsky It's What I Do! Wormhole Xtreme Systems Communications Sciences, Inc At TSG, OIT Services Data Center State of New Hampshire
Re: VM directory entry for shared DASD
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* reserve/release part). The cyl0 is only when it needs to go to the real device so other LPARs can participate. 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 internal locking mechanism) handle this? Why does CP need to be involved? The control unit is supposed to acknowledge R/R to provide exclusive access to the volume for more than one channel program. If you would have guest A issue the reserve and then get guest B from the same z/VM image try it, the control unit would grant access because the LPAR already holds a reserve, so the control unit thinks this is fine. What you want is CP to be arbiter and issue the real reserve for the volume as long as one of the guests holds a reserve. BTW, there are no LPARS involved here. And the reason why not all shared packs start on cyl 0 is because we wanted to retain uniqueness of DASD volids whenever possible. Thus, the VSE DASD starts at REAL CYL. If it's just 1 z/VM LPAR then you have no need for real reserve to be issued because there is nobody outside who can try. And afaik VSE only does the R/R for some disks (like the lock file) and for the other disks there is logic (in the lock file) that protects the datasets (rather than reserve the entire volume anytime you want to write a shared dataset). I hope I did not make it more confusing that it has to be. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: VM directory entry for shared DASD
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 [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 06, 2006 2:26 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM directory entry for shared DASD 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* reserve/release part). The cyl0 is only when it needs to go to the real device so other LPARs can participate. 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 internal locking mechanism) handle this? Why does CP need to be involved? The control unit is supposed to acknowledge R/R to provide exclusive access to the volume for more than one channel program. If you would have guest A issue the reserve and then get guest B from the same z/VM image try it, the control unit would grant access because the LPAR already holds a reserve, so the control unit thinks this is fine. What you want is CP to be arbiter and issue the real reserve for the volume as long as one of the guests holds a reserve. BTW, there are no LPARS involved here. And the reason why not all shared packs start on cyl 0 is because we wanted to retain uniqueness of DASD volids whenever possible. Thus, the VSE DASD starts at REAL CYL. If it's just 1 z/VM LPAR then you have no need for real reserve to be issued because there is nobody outside who can try. And afaik VSE only does the R/R for some disks (like the lock file) and for the other disks there is logic (in the lock file) that protects the datasets (rather than reserve the entire volume anytime you want to write a shared dataset). I hope I did not make it more confusing that it has to be. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: VM directory entry for shared DASD
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 some IBMLINK INFO APARs about these problems. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Wakser, David Sent: Wednesday, September 06, 2006 2:30 PM To: IBMVM@LISTSERV.UARK.EDU Subject: 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 [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 06, 2006 2:26 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM directory entry for shared DASD 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* reserve/release part). The cyl0 is only when it needs to go to the real device so other LPARs can participate. 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 internal locking mechanism) handle this? Why does CP need to be involved? The control unit is supposed to acknowledge R/R to provide exclusive access to the volume for more than one channel program. If you would have guest A issue the reserve and then get guest B from the same z/VM image try it, the control unit would grant access because the LPAR already holds a reserve, so the control unit thinks this is fine. What you want is CP to be arbiter and issue the real reserve for the volume as long as one of the guests holds a reserve. BTW, there are no LPARS involved here. And the reason why not all shared packs start on cyl 0 is because we wanted to retain uniqueness of DASD volids whenever possible. Thus, the VSE DASD starts at REAL CYL. If it's just 1 z/VM LPAR then you have no need for real reserve to be issued because there is nobody outside who can try. And afaik VSE only does the R/R for some disks (like the lock file) and for the other disks there is logic (in the lock file) that protects the datasets (rather than reserve the entire volume anytime you want to write a shared dataset). I hope I did not make it more confusing that it has to be. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: VM directory entry for shared DASD
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 ADD statement the VSE instruction path will increase slightly for the lock file maintaince but with the lock file being virtual it eliminates any wait time. -Original Message-From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]On Behalf Of Edward M. MartinSent: Wednesday, September 06, 2006 1:41 PMTo: IBMVM@LISTSERV.UARK.EDUSubject: 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 some IBMLINK INFO APARs about these problems. Ed MartinAultman Health Foundation330-588-4723[EMAIL PROTECTED]ext. 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Wakser, DavidSent: Wednesday, September 06, 2006 2:30 PMTo: IBMVM@LISTSERV.UARK.EDUSubject: 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 [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 06, 2006 2:26 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM directory entry for shared DASD 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* reserve/release part). The cyl0 is only when it needs to go to the real device so other LPARs can participate. 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 internal locking mechanism) handle this? Why does CP need to be involved? The control unit is supposed to acknowledge R/R to provide exclusive access to the volume for more than one channel program. If you would have guest A issue the reserve and then get guest B from the same z/VM image try it, the control unit would grant access because the LPAR already holds a reserve, so the control unit thinks this is fine. What you want is CP to be arbiter and issue the real reserve for the volume as long as one of the guests holds a reserve. BTW, there are no LPARS involved here. And the reason why not all shared packs start on cyl 0 is because we wanted to retain uniqueness of DASD volids whenever possible. Thus, the VSE DASD starts at REAL CYL. If it's just 1 z/VM LPAR then you have no need for real reserve to be issued because there is nobody outside who can try. And afaik VSE only does the R/R for some disks (like the lock file) and for the other disks there is logic (in the lock file) that protects the datasets (rather than reserve the entire volume anytime you want to write a shared dataset). I hope I did not make it more confusing that it has to be. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. ella for Spam Control has removed 6914 VSE-List messages and set aside 4601 VM-List for meYou can use it too - and it's FREE!www.ellaforspam.com
Re: VM directory entry for shared DASD
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 [EMAIL PROTECTED] ext. 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, September 06, 2006 3:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: 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 ADD statement the VSE instruction path will increase slightly for the lock file maintaince but with the lock file being virtual it eliminates any wait time. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]On Behalf Of Edward M. Martin Sent: Wednesday, September 06, 2006 1:41 PM To: IBMVM@LISTSERV.UARK.EDU Subject: 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 some IBMLINK INFO APARs about these problems. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Wakser, David Sent: Wednesday, September 06, 2006 2:30 PM To: IBMVM@LISTSERV.UARK.EDU Subject: 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 [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 06, 2006 2:26 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM directory entry for shared DASD 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* reserve/release part). The cyl0 is only when it needs to go to the real device so other LPARs can participate. 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 internal locking mechanism) handle this? Why does CP need to be involved? The control unit is supposed to acknowledge R/R to provide exclusive access to the volume for more than one channel program. If you would have guest A issue the reserve and then get guest B from the same z/VM image try it, the control unit would grant access because the LPAR already holds a reserve, so the control unit thinks this is fine. What you want is CP to be arbiter and issue the real reserve for the volume as long as one of the guests holds a reserve. BTW, there are no LPARS involved here. And the reason why not all shared packs start on cyl 0 is because we wanted to retain uniqueness of DASD volids whenever possible. Thus, the VSE DASD starts at REAL CYL. If it's just 1 z/VM LPAR then you have no need for real reserve to be issued because there is nobody outside who can try. And afaik VSE only does the R/R for some disks (like the lock file) and for the other disks there is logic (in the lock file) that protects the datasets (rather than reserve the entire volume anytime you want to write a shared dataset). I hope I did not make it more confusing that it has to be. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. ella for Spam Control has removed 6914 VSE-List messages and set aside 4601 VM-List for me You can use it too - and it's FREE!www.ellaforspam.com
Re: VM directory entry for shared DASD
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 accidently destroy a disk by writting on it from another VSE on the same VM image. (Of course, they also had SHR on all ADD statements recommended, also) I was at two different sites, in the early '90s, that were upgrading to a new box. Single VSE image under VM. And had a lock file defined. All packs MWV and SHR on the ADD statement. The lock file (real disk not vdisk), was getting millions of I/O to it every day. And each site said: I don't knowIBM said To some extent, I could see the logic. If you have a single VSE system under VM, and someone, brought up a second VSE system and didn't know the proper way to share VSE packs, this kind of practice could keep you from shooting yourself in the foot. I seem to recall that a Redbook came out later on how to share VSE disks, under a single VM image. You might want to do a search for it. I normally share, 1 volume across VSE systems for sequential disk and 1 volume across VSE systems with it's own VSAM catalog. When I check the LOCK01 pack for total I/O counts (using Vollie), I see that day to day, I get very little change in total I/Os to the lock file. Just the way I like it G. Tom Duerbusch THD Consulting Tom Duerbusch THD Consulting
Re: VM directory entry for shared DASD
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 softwareserialization method. This is undoubtedly negligible as long asRESERVE is not really being used. Regards, Richard Schuh -Original Message-From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]On Behalf Of Edward M. MartinSent: Wednesday, September 06, 2006 12:08 PMTo: IBMVM@LISTSERV.UARK.EDUSubject: 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 MartinAultman Health Foundation330-588-4723[EMAIL PROTECTED]ext. 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, ThomasSent: Wednesday, September 06, 2006 3:01 PMTo: IBMVM@LISTSERV.UARK.EDUSubject: 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 ADD statement the VSE instruction path will increase slightly for the lock file maintaince but with the lock file being virtual it eliminates any wait time. -Original Message-From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]On Behalf Of Edward M. MartinSent: Wednesday, September 06, 2006 1:41 PMTo: IBMVM@LISTSERV.UARK.EDUSubject: 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 some IBMLINK INFO APARs about these problems. Ed MartinAultman Health Foundation330-588-4723[EMAIL PROTECTED]ext. 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Wakser, DavidSent: Wednesday, September 06, 2006 2:30 PMTo: IBMVM@LISTSERV.UARK.EDUSubject: 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 [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 06, 2006 2:26 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM directory entry for shared DASD 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* reserve/release part). The cyl0 is only when it needs to go to the real device so other LPARs can participate. 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 internal locking mechanism) handle this? Why does CP need to be involved? The control unit is supposed to acknowledge R/R to provide exclusive access to the volume for more than one channel program. If you would have guest A issue the reserve and then get guest B from the same z/VM image try it, the control unit would grant access because the LPAR already holds a reserve, so the control unit thinks this is fine. What you want is CP to be arbiter and issue the real reserve for the volume as long as one of the guests holds a reserve. BTW, there are no LPARS involved here. And the reason why not all shared packs start on cyl 0 is because we wanted to retain uniqueness of DASD volids whenever possible. Thus, the VSE DASD starts at REAL CYL. If it's just 1 z/VM LPAR then you have no need for real reserve to be issued because there is nobody outside who can try. And afaik VSE only does the R/R for some disks (like the lock file) and for the other disks there is logic (in the lock file) that protects the datasets (rather than reserve the entire volume anytime you want to write a shared dataset). I hope I did not make it more confusing that it has to be. Rob
Re: VM directory entry for shared DASD
Wasn't there a time way back in the dark ages when CP would check for RESERVE/RELEASE hardware during its IPL roll call and unconditionally mark the (real) device as sharable if present? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL 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? But even if that is not the case, why buy bicycle tires if you have no bicycle? For clarity: - The V enables CP simulation of RESERVE/RELEASE for guests on the *same* VM system. Without it, CP causes a Command Reject on the RESERVE or RELEASE (resulting the VSE message) - IF a minidisk link mode has the V on it AND it is full-pack (not just starting on cyl 0) AND it is defined as SHARED THEN CP will propagate a RESERVE/RELEASE to the real DASD volume. The V is optional to allow continued simulation of older dasd configuration that don't have the then-optional two-channel switch feature. You *do* have 2835 and 3880 control units, right? :-) Back then on the real dasd you would get a Unit Check with Command Reject. You get the same thing on a minidisk without the V. [20 years pass] So, it is now the 21st century and Walter Cronkite no longer hosts the CBS Evening News. Should we change CP such that V is the unchangable default(SM)? Is there any reason RESERVE/RELEASE should remain disabled in an ECKD world? (VM no longer supports CKD devices, where RESERVE would be optional.) If the disk is a full-pack mini, should CP treat the volume as if it were defined as SHARED? The floor is open for discussion. Alan Altmark z/VM Development IBM Endicott
Re: VM directory entry for shared DASD
Hello Richard, I do know that if you have MW on the MDISK PROD MDISK 7AA 3390 000 3339 RAM0AA MW ALL VSEPSW VSEPSMW MDISK 7AB 3390 000 3339 RAM0AB MW ALL VSEPSW VSEPSMW And BETA has LINK PROD 7AA 7AA MW LINK PROD 7AB 7AB MW And the ADD statement for the VSE BETA has SHR You will get the message during the BETA IPL of BG 0I23I DASD ON 7AA NOT PHYSICALLY SHARABLE BG 0I23I DASD ON 7AB NOT PHYSICALLY SHARABLE I am testing the other way around. Having MWV on the mdisk statement and no shr on the add. Ed Martin 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 for shared DASD Wasn't there a time way back in the dark ages when CP would check for RESERVE/RELEASE hardware during its IPL roll call and unconditionally mark the (real) device as sharable if present? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL 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? But even if that is not the case, why buy bicycle tires if you have no bicycle? For clarity: - The V enables CP simulation of RESERVE/RELEASE for guests on the *same* VM system. Without it, CP causes a Command Reject on the RESERVE or RELEASE (resulting the VSE message) - IF a minidisk link mode has the V on it AND it is full-pack (not just starting on cyl 0) AND it is defined as SHARED THEN CP will propagate a RESERVE/RELEASE to the real DASD volume. The V is optional to allow continued simulation of older dasd configuration that don't have the then-optional two-channel switch feature. You *do* have 2835 and 3880 control units, right? :-) Back then on the real dasd you would get a Unit Check with Command Reject. You get the same thing on a minidisk without the V. [20 years pass] So, it is now the 21st century and Walter Cronkite no longer hosts the CBS Evening News. Should we change CP such that V is the unchangable default(SM)? Is there any reason RESERVE/RELEASE should remain disabled in an ECKD world? (VM no longer supports CKD devices, where RESERVE would be optional.) If the disk is a full-pack mini, should CP treat the volume as if it were defined as SHARED? The floor is open for discussion. Alan Altmark z/VM Development IBM Endicott
