Re: impact of deleted records

On 30-Jun-2014 12:17 -0500, Krill, Coy wrote:

Steinmetz, Paul on Monday, June 30, 2014 08:34 wrote:

You must be careful when changing PF to REUSEDLT(*YES).
We have some 3rd party apps that require REUSEDLT(*NO) for various
reasons. Also, if you can afford several hours of extra down time
during IPL, then Chris's idea works. We cannot be down that extra
time so we use RGZPFM while active.
For this to work, PF must be journaled, so the automated process
begins journaling, ends when complete. <<SNIP>>

<<SNIP>> do you by chance know if this works with the file already
being journaled by MIMIX?

The file must be journaled. For what purpose the file was originally associated with a journal is immaterial if the file remains journaled; obviously, ending journaling for an already-journaled file, likely would be problematic.

I have a 300GB+ file that is replicated and the bulk of the file is
deleted records. Unfortunately it's always locked and in use for an
online banking system and I would love to reorg it without having to
take down our online banking.

The while-active\online reorg capability used to require at least /momentarily/ the ability to achieve an exclusive lock to truncate the data segment(s) in which all rows were inactive\deleted. I believe there may have been an enhancement to allow even that operation, without the exclusive lock.

It's also one of those files that cannot be set to reuse deleted
records due to the way it's processed.

If a physical database file has a requirement that prohibits the attribute REUSEDLT(*YES), then the file is also likely prohibited from having the Reorganize Physical File Member (RGZPFM) performed with the Allow Cancel (ALWCANCEL) [online\while-active] specification in effect for that reorg request; i.e. the effects of the ALWCANCEL(*YES) reorg request is quite similar to the effects from use of the REUSEDLT(*YES) definitional attribute, whereby the /Arrival Sequence/ is unlikely to be maintained.