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: [email protected] > 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 >
