Paul:
OK, it looks like I missed your ENQ shared condition. On looking back, I
see you just allocated the file DISP=SHR, which would allow you to OPEN
it in another job and then extend it. Of course, you realize that you
violated the purpose of the exclusive ENQ by updating the data set in
one of the sharing instances. And you create the potential problem
situation which I tried to describe.
Mike Myers
Mentor Services Corporation
Paul Gilmartin wrote:
On Sun, 18 Nov 2007 13:15:42 -0500, Mike Myers wrote:
It is true that you can increase the size of a dataset that is OPEN by
another address space after removing its ENQ protection, as you have
obviously demonstrated with your experiment.
I removed no ENQ protection. I suspect that to end an ENQ in another
address space would require considerable privilege that my batch job
lacked. Didn't my TSO session continue to hold the SHR ENQ on the DSN?
However, you need to understand that the internal constructs
representing that OPENed data set to the address space that had ENQueued
it previously are not dynamically updated to show the existence of the
new extent.
Understood.
Paul Gilmartin wrote:
Apparently the key word here is "system". I tried the experiment
and readily performed secondary allocation with a batch job
(IEBGENER SYSUT2) while my TSO session had the DSH allocated SHR.
Does the system hold an exclusive ENQ to prevent this?
-- gil
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
