At 16:34 +0300 on 08/01/2006, Binyamin Dissen wrote about Re: Data
set ENQueues and DEQueues in Jobs:
On Mon, 31 Jul 2006 23:48:57 -0700 Edward Jaffe <[EMAIL PROTECTED]>
wrote:
:>Huh? You have this completely reveresed in your mind. Upgrading your ENQ
:>from shared to exclusive is the common case and is a *required* function
:>in order to maintain the integrity of the data. Going the other way
:>would be far less common ... so uncommon, in fact, that OS/MVT/MVS never
:>bothered to create a service for it! There's just no need. If you want
:>to downgrade from exclusive to shared, you simply DEQ and re-ENQ with
:>shared scope.
Which loses control if there are ten SHR waiters followed by an EXC waiter.
I can see the case for EXC->SHR, and it should always be successful.
Thank you for your support of my gripe about the lack of an EXC->SHR
capability. As one example of where this lack is a BAD FLAW/BUG, lets
look at the case of a multi-step job stream. You have Step 1 with an
Exclusive Lock (ENQ EXC) on a dataset which it holds for 1 minute
(either due to create or update). Subsequent steps only need DISP=SHR
(ENQ SHR) and run for Hours. Since the Job holds the Exclusive Lock
until the last step that uses the dataset (when it will get released
if there are subsequent job steps that do not need/use it) or stream
end. A EXC->SHR downgrade capability would let the Initiator go the
lock downgrade and allow DISP=SHR jobs that are waiting to gain
access and start running.
----------------------------------------------------------------------
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
