At 13:14 -0600 on 07/28/2006, Paul Gilmartin wrote about Re: Data set
ENQueues and DEQueues in Jobs:
A JES3 partisan once told me, as I whined about a job spewing
ENQ messages into SYSLOG while another job held an ENQUE for
the same DSN on a different volume, "That wouldn't happen with
JES3." Perhaps he merely meant that JES3 would hold the second
job from initiation until all resources it needed were immediately
available.
Part of the problem with this type of incorrect "conflict" is that
the SYSDSN Queue (the QNAME used for the ENQ/DEQ) regards the DSN
(the RNAME) as the identifier of the Dataset not the CORRECT DSN with
VOLSER. This goes back to the OS360 (PCP/MFT/MVT) days when the
concept of having two CPUs sharing their ENQ/DEQ Queue was not
imagined. Since you do not know what VOLSER the DSN you are ENQing on
will be on until you actually allocate it at Step Initiation time,
there is no way to fix this problem (such as having another QNAME
that uses a RNAME that contains the VOLSER along with the DSN). In
fact, ISPF which should know better (since it allocates at
dynamically and thus KNOWS at allocate time which VOLSER to use
[either due to looking at the catalog or accepting this info from the
User]) still does its private ENQ on a DSN only RNAME and thus can
refuse to access a DSN on VOL2 when another ISPF User has a VOL1
resident Dataset with the same name in use.
----------------------------------------------------------------------
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
