BTW, this is the earlier post I referred to in my "later" post, but it
seems not to have been passed along.
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.
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.
The DEB (Data Extent Block) is created when the dataset is OPENed and
only adds new extents when that same address space occurs an EOV (End Of
Volume) condition during its own data set processing. Consequently, the
new extent created by another address space in NOT recognized by the
original owner without its CLOSEing and re-OPENing the data set.
Mike Myers
Mentor Services Corporation
Paul Gilmartin wrote:
On Sat, 17 Nov 2007 12:30:34 -0500, Peter Relson wrote:
Removing the ENQ is easy. Increasing the size of an existing data set for
which the system has obtained ENQs is not supported, and you do so at your
own risk. The ENQ's are in place so that you do NOT do this.
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
