On Sat, 30 Jan 2016 20:54:20 -0500, Robert A. Rosenberg wrote: >At 14:53 -0600 on 01/30/2016, Paul Gilmartin wrote about Re: Deleting >a dataset that GRS has enqueued.: > >>Even within a single system, to delete a data from one volume when >>a like named data set on a diferent volume is in use ENQ SHR on the >>same system. > >This is a irresolvable design flaw (ie: The Volser is not part of the >ENQ - Only the DSN) that is hard/impossible to fix based on the >different times and ways the ENQ is issued. ... > I said it was hard. I said also that it's important. I don't believe it's impossible.
> ... IOW: The Volume that the >dataset resides on can at times be unknown until AFTER the ENQ is >issued. ... > This does not preclude issuing additional ENQs, SHR, incorporating the VOLSERs in the RNAME at the point in time that the VOLSERs become known. Note that I see this as in addition to, not instead of the current ENQ performed at allocation time which does not incorporate any VOLSER. > ...Thus there is no way that an ENQ on a dataset named DSN1 >which is on VOLSER1 can be told from an ENQ for a dataset named DSN1 >residing on VOLSER2. ... > You are postulating that no ENQ can be deferred until the VOLSER is knowns This is just current practice, not axiomatically true. Then deleting a data set or scratching an extent could issue ENQs EXC on similar VOLSERs+DSN combinations. If one of those ENQs fails, the data set is on the same volume and can not be safely deleted. If all those ENQs succeed, the data set is on (a) separate volume(s) and may safely be deleted. There would be a hazard that the only instance of a DSN could be scratched before another job opens it. I believe this is preferable to the current situation. I was accustomed to this, DATA SET NOT FOUND, when a data set was scratched but left catalogued. >... There are ENQs such as that used >when SPF Editing which get issued with the knowledge of the VOLSER >where the dataset resides so they can have use the VOLSER to help the >ENQ be more specific and thus allow editing of members in different >datasets with the same DSN - I do not know if this occurs or if the >bare-bones DSN-Only is used to be the consistent with SYSDSN's RNAME. > I believe ISPF EDIT issues: o ENQ SHR on DSN (always done by allocation) o ENQ EXC on member+DSN ... but VOLSER is not involved. Skip's followup appears to agree with this (or at least not to contradict it). -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
