On Wed, 23 May 2007 00:46:28 -0400, Robert A. Rosenberg <[EMAIL PROTECTED]> wrote: >I do not regard my query about why this glaring design flaw in ENQ is >not being addressed (even if the usage of the enhanced support is >restricted to the Initiator initially) as insulting (or do you regard >my characterization of the original/current design of ENQ lacking a >EXC->SHR Downgrade capability as "poor"/"flawed" as insulting?).
Perhaps we differ, but the characterization of poor and/or flawed appears to me as pejorative. Please read the following as facts, not insults: Since you are not in a custodial position for the design or implementation of ENQ, GRS, or Allocation, you cannot know if such a design has ever been proposed, written, or embodied. You can only know that it is not available as the operating system is currently implemented through consideration of the written documentation and empirical experimentation. ENQ/DEQ, in its current form (barring the two currently open APARs against it, neither of which do not violate the integrity of the function), is not flawed, the function is merely incomplete. >I am doing exactly what a SHARE Requirement is supposed to do - Point >out a lack of functionality and provide an suggestion as to one way >to rectify the lack. I do not have access to the SHARE Request List >but I'd be surprised if there has not been one already submitted (or >at least proposed) about this exact issue (the lack of a EXC->SHR >downgrade at the job step boundary between DISP=OLD and DISP=SHR >steps). Although obvious, I'll state that IBM-MAIN is not considered a forum for gathering requirements for IBM products. >IMO, the lack of a fix in progress amounts to a deliberate crippling >of the Initiator since the fix is so easy to make You are entitled to your opinion. On Wed, 23 May 2007 22:38:13 -0500, Paul Gilmartin <[EMAIL PROTECTED]> wrote: >Would repairing a defect be considered (part of) a business case? Of course. > >I was sensitized to this matter many years ago when I learned that >under certain conditions of contention attempting to DYNALLOC a data >set with options NEW and CATALOG can fail and leave the data set on >a volume not catalogued and not deleted. I discovered this with >considerable discomfort only when I had run the job enough times >and it had failed enough times (usually it succeeded) that I had >a copy of the problem data set on every storage volume on the floor. > >A dedicated IBM developer researched the problem and sought a solution. >Finally, he reported to me that under the design requirements of >DYNALLOC, and lacking the facility to downgrade an ENQ, no solution >was possible. (I would have changed the specifications of DYNALLOC, >since the problem I reported demonstrated in itself that the specification >was not being met.) With an ENQ downgrade facility, the problem >could easily have been solved within the constraints of the DYNALLOC >specification. And what was the outcome of the incident? > >And, finally, to throw an additional wrinkle Robert's way, suppose: > > ALLOCATE DD(E) DSN(FOO.BAR) OLD > ALLOCATE DD(S) DSN(FOO.BAR) SHR > FREE DD(E) > >A programmer might reasonably expect this would leave a SHR ENQ >on SYSDSN FOO.BAR. What component should do the accounting, and >what's the algorithm? But perhaps this hardly more complex than >what is done nowadays when a data set name is statically allocated >in JCL, then multiply allocated to different DDNAMEs and FREEd >dynamically within the job step. A programmer might come to that conclusion. This programmer would agree if the result of the set of directives concluded with _no_ ENQ on FOO.BAR. However, if the result was that an EXCL ENQ remained on FOO.BAR, I'd come to the same conclusion as I do now for the batch allocation case. It ain't perfect, but it gets the job done and maintains the integrity of the data. Scott Fagen z/OS Core Technology Design IBM Poughkeepsie ---------------------------------------------------------------------- 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
