May I assume (should it be obvious?) that the design is such that
system resources can be sufficiently RACF-protected that a user
lacking authority to update those resources can not threaten system
integrity or security by failing to follow proper protocols, but
only the integrity of that user's
Perhaps it is not obvious to some, though obvious to me.
The only valid protocol for such operations as reallocation of space and
compress is to use DISP=OLD (ENQ obtained exclusive).
If you choose to do such operations with DISP=SHR then you get what you
deserve (i.e., it might work but your
On Mon, 19 Nov 2007 07:21:50 -0500, Peter Relson wrote:
Perhaps it is not obvious to some, though obvious to me.
The only valid protocol for such operations as reallocation of space and
compress is to use DISP=OLD (ENQ obtained exclusive).
If you choose to do such operations with DISP=SHR then
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
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
Gil:
See my previous reply. The DEB exists in the LSQA of the address space
that has the data set OPEN. In order to do what you ask, it would be
necessary for the system to find all OPEN instances of the newly
extended data set and then adding the new extent to its particular DEB.
How it
On Thu, 15 Nov 2007 15:53:49 -0600, Mark S. House wrote:
During SMP/E mantenance a system fils CSF.SCSFMOD0 had a d37. I removed
the file from the PLEX and wanted to increase it's size. It appears the
LLA and XCFAS on the on the other LPAR's in the system have enque on the
name. How can I
On Sun, 18 Nov 2007 13:28:00 -0500, Mike Myers wrote:
Gil:
See my previous reply. The DEB exists in the LSQA of the address space
that has the data set OPEN. In order to do what you ask, it would be
I believe I asked nothing (except insofar as I quoted the OP); I merely
offered two empirical
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
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
How can I remove the enqueue so I can increase and copy the file.
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.
If the system is
- Original Message
From: Mark S. House [EMAIL PROTECTED]
How can I remove the enqueue so I can increase and copy the
file.
Mark,
they only way I know to free others systems' ENQ is
1) P LLA on every system (frees LLA ENQs)
2) SETPROG LNKLST,UNALLOCATE on every system (free XCFAS
On Fri, 16 Nov 2007 06:30:48 -0800, Walter Marguccio
[EMAIL PROTECTED] wrote:
- Original Message
From: Mark S. House [EMAIL PROTECTED]
How can I remove the enqueue so I can increase and copy the
file.
Mark,
they only way I know to free others systems' ENQ is
1) P LLA on every
During SMP/E mantenance a system fils CSF.SCSFMOD0 had a d37. I removed
the file from the PLEX and wanted to increase it's size. It appears the
LLA and XCFAS on the on the other LPAR's in the system have enque on the
name. How can I remove the enqueue so I can increase and copy the file.
14 matches
Mail list logo
