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
