At 08:37 -0500 on 05/22/2007, Paul Gilmartin wrote about Re: Why is
there JOB scope for DSN ENQ's anyway?:
>Note: I acknowledge that there also needs to be updates to the ENQ
and ISGENQ macros to request this option and a new flag bit in their
Parm fields. That and what happens if you make the request on a
system that is missing the support is the bigger problem than making
the few lines of code change to support the capability.
The format of the new parameter list needs to be such that it is invalid
on a system that is missing the support.
As I was typing one of my replies yesterday, I rethought the issue
and realized we got off-track. What we are addressing (at least
initially) is a solution to the issue of the Initiator holding the
EXC ENQ longer than it needs to (ie: During Job Steps where a SHR ENQ
is adequate since no Job Steps from this point until Job Term need
the EXC ENQ). The updating of the ENQ code to support the EXC->SHR
downgrade request and the updating of the Initiator code to make this
request at Step Term of the last step that needs the EXC ENQ when one
or more steps only need a SHR ENQ will fulfill this need.
Our desire to want the request for this function to be bullet-proof
so that it will trigger a failure if issued on a system without the
support is a non-issue since there is no need to make this a general
usage interface AT THIS POINT IN TIME. Just make it a
private/undocumented interface (as has been done with other internal
functions such as SuperLocate and others) and restrict its use to
ONLY the Initiator (and possibly other IBM routines that could be
more efficient by its availability). The Initiator can make the
request without any need to update the SYS1.MACLIB versions of the
ENQ and ISGENQ macros (or their generated parameter list). Since the
only routine that is issuing the request is the Initiator, it will
automatically be running on a system that has the needed enhanced ENQ
support. Since this facility only gets used by the Initiator, you do
not have the exposure that would exist if it were made a standard
User Interface or one that could also (under NDA) be used by 3-Party
Products.
Note: I have not looked at the format of the ISGENQ parmlist but if
it has some version level field that might solve the incompatible
format issue IF/WHEN the EXC->SHR capability were made a general-use
function. That issue is for the future since all that is needed RIGHT
NOW is to allow the Initiator to use it.
----------------------------------------------------------------------
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
