On Wed, 15 Aug 2007 14:57:16 -0500, Patrick O'Keefe wrote:
>
>>100% in order to do an APPLY REDO (but that's a strange thing
>>to do in a LINKLST library). PDSE could make the situation
>>better, even to the extent of needing only surplus space as
>>large as the largest member; or worse, because space may not
>>be reused until all address spaces CLOSE the data set.
>
>Worse (unless things have changed in that last couple years).
>You don't run int the additional extent problem; you just run out of
>space that can't be reclaimed. When I ran into this, every LPAR with
>the library in the LINKLIST had it allocated and open by LLA and
>XCFAS. I assume it was the OPEN that kept the space from being
>reclaimed.
>
Then, how much space does it take to refresh a PDSE by complete
replacement by IEBCOPY? 200% of the quiescent size? Or does
IEBCOPY somehow cleverly optimize the space requirement.
>A royal pain!
>
But this is for integrity in case:
Address space A does a BLDL, FIND, or NOTE.
Address space B replaces or deletes the member that
address space A found.
Address space A then POINTs at the member.
But nowadays, {Z|H}FS directories are supported (read only) as
libraries by BPAM. What then happens in the analogous case,
replacing PDSEs by UNIX directories? Does the POINT or subsequent
READ fail as some sort of invalid reference? Or does the NOTE
cause the open() of a descriptor of the underlying file, anchoring
it in place (although I might expect that unlike a library member
it might nonetheless be overwritten by a concurrent process)?
-- 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
