On Sun, 29 Mar 2009 15:39:21 -0400, Robert A. Rosenberg wrote: > > There is only one GOTCHA (as there is with all the >SYSDSN type ENQs) since in a multi-CPU environment the DSN should be > Doesn't need to be multi-CPU; multi-task is bad enough. Who has a single-CPU system nowadays, anyway?
>unique since the VOLSER is not part of the RNAME even though SPF >KNOWS which volume the dataset is on. Thus you can be editing CPU1's >version of a data set and lock out editing of CPU2's version (on a >different volume) with the same DSN. IBM for historical reasons has >been unable to fix this design-flaw of the ENQ System since there are > The flaw is not in the ENQ system, but in how the data management layer employs it. >components that do the ENQ before they know which volume the dataset > (More often than not.) >resides on. This should not however prevent SPF from doing ITS ENQ >with VOLSER if they wanted to fix this problem (since by the time the >ENQ is done the VOLSER is known). > That would solve the problem for ISPF and leave it outstanding for other operations such as batch. But it's worse. Since the only hazard I perceive would occur when an extent is freed while another task has a DEB for that extent, I once proposed in these pages that at OPEN time, when the VOLSER(s) are known an additional ENQ SHR on DSN and VOLSER be issued; when an extent is freed, an ENQ EXCL be issued, ABEND if not immediately satisfied. An IBM employee countered that there are system processes which ENQ on DSN (not VOLSER) and manipulate the extents while never performing an OPEN nor creating DEBs. QED? Not QED in my perception; omitting the OPEN is bad practice which should be corrected. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
