At 13:17 -0500 on 05/22/2007, Scott Fagen wrote about Re: Why is
there JOB scope for DSN ENQ's anyway?:
On Sat, 19 May 2007 20:59:40 -0500, Paul Gilmartin <[EMAIL PROTECTED]>
wrote:
On Sat, 19 May 2007 20:52:05 -0300, Clark Morris wrote:
... If the ENQ is exclusive for the first step and
shared for the second, it will be changed by the initiator/terminator
between steps.
Nope.
Wishful thinking.
But why not?
ENQ RET=CHNG only supports 'upgrade' from SHR to EXC, not 'downgrade' from
EXC to SHR. DEQing and re-ENQing may put you behind some waiting request,
which would expose you to deadly embraces.
Can you PLEASE explain why there was/is support for a SHR->EXC
Upgrade (which has an almost 100% probability of not being doable due
to some other task sharing your SHR ENQ status - IOW: Will only work
when you are the sole ENQ'er in the first place) when the 100%
Guaranteed to Succeed EXC->SHR Downgrade (since all it entails is
updating the ENQ E/S field to SHR and acting as if you were the first
SHR waiter with some OTHER task having just done the DEQ - IOW: You
keep the ENQ but now as SHR and all the tasks who were waiting for
you to DEQ [up until the first EXC waiter] get released)?
What was the original justification for the SHR->EXC support (even
though it has timing restrictions that make it impossible to use
consistently) while the design DELIBERATELY excluded EXC->SHR support
that will ALWAYS work and would prevent the unnecessary holding of
the EXE lock in Job Steps when only a SHR is needed (as well as other
cases where a user written task needs to start with an EXC ENQ but
only needs a SHR ENQ for the rest of the job step once the EXC
protected work has been done)? As others have pointed out the
rectification of this design flaw/decision is mired in the need to
insure that the attempt to issue this request on a system that does
not support it is detected and dealt with. If pushed, I think I can
come up with a macro expansion that will be able to check for the
support (by chasing and CVT anchored chain) and issue an ABEND when
needed although it would be a major kluge of an expansion. The
alternative, as noted, is to come up with an updated ENQ/ISGENQ parm
list that will trigger an error if feed to a downlevel ENQ/ISGENQ
routine.
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
