At 09:53 -0600 on 01/12/2011, McKown, John wrote about speculation:
z/OS "enhancments":
OK. I'm not sure if this is off-topic or not. If it is, then I
apologize. But I'm wondering if z/OS is "lacking" in some areas. Or
limited in some way that you wish would disappear. I'm assuming that
"cost is not a problem". Which is a stupid assumption, of course.
Mine is to fix/enhance the ENQs for datasets so they include the
volume name as part of the RNAME. The original use of DSN in lieu of
DSN+VOLSER was OK until GRS and/or Shared DASD was introduced and you
could have multiple datasets with the same DSN in your complex. There
are some components (such as SPF EDIT) that do it right by actually
using the VOLSER to tell the difference between multiple datasets
with the same name. The show stopper in fixing this is that
Initiation does not bother to do its DISP ENQs by looking up the
VOLSER when it does its ENQ in support of DISP=OLD/SHR.
Also enhance ENQ so an EXCLUSIVE ENQ owner can switch itself to SHR
ownership (and thus allow backed up other tasks who are waiting for
it to release to start running). The current inability to downgrade
from EXC to SHR status leads to such design flaws as Job Streams that
have STEP1 with a DISP=OLD and subsequent Steps with DISP=SHR holding
exclusive ownership of the Dataset Name (not the Dataset Itself - see
the lack of Volser as part of the RNAME above for details) until at
least the end of the last step referencing the DSN. I say at least
since I think that early release is what occurs now when originally
the ENQ was held (even when not needed) until Job End. This makes
jobs that might run for an hour but only need the DISP=OLD lock for
the first minute or two lock out other DISP=SHR job streams for the
full hour (when they would already be running if the DISP=OLD step
were not there).
Side-Comment - The fix for EXC->SHR is IMO a VERY simple thing to
implement. You update the ENQ Macro Parms to have a flag to say
EXC->SHR (like the one that does SHR->EXC [what this is supposed to
be used for is a question with the lack of being unable to do
anything except DEQ when you are done with your upgraded EXC state if
you even get it - What you are supposed to use this SHR->EXC ability
for is a separate issue]). When issued, the code just resets the ENQ
chain entry to show that the task has SHR status now and then drives
the DEQ code that runs the chain releasing waiting SHR tasks until
running off the chain or encountering a waiting EXC request. I can
see some potentially minor support issues if you try to issue such an
ENQ on a system that does not support it (ie: What happens if you
send such an ENQ to a down level version of the ENQ routine? Will it
ignore the flag it does not know, return a RC [which the user's code
can ignore by just continuing as EXC as currently would occur], or
ABEND the task [a bad thing]). The ABEND case can be handled by just
having a CVT flag that says the support is there (as there are other
such flags) and the user's program can not bother playing good-guy
and issuing the ENQ TYPE=MAKE-SHR when the support is not there.
Since the Initiator code to make use of this enhancement would COREQ
the ENQ upgrade there would be no possibility for the Initiator code
running on a non-supporting system.
----------------------------------------------------------------------
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
