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

Reply via email to