Re: RGZPFM quick question

[CRPence <CRPbottle@xxxxxxxxx>]

  Actually if any keyed access paths exist, all will be rebuilt by the 
request for RGZPFM KEYFILE(*NONE), due to the default RBDACCPTH(*YES). 
Prior to the existence of this AccPth rebuild parameter [and the online 
reorganize by ALWCANCEL(*YES)], there was never any choice; i.e. access 
paths were all rebuilt synchronously and serially in the job requesting 
the RGZPFM.  To specify RBDACCPTH(*NO) requires that the ALWCANCEL(*YES) 
be specified.

  However the request to RGZPFM RBDACCPTH(*OPTIMIZE) KEYFILE(*NONE) is 
presumably allowed, and if so, that should enable the optimization 
algorithm to try to guess if it might be faster to maintain one or more 
logical access paths during the removal of deleted records, rather than 
rebuild them all synchronously and serially after the deleted rows are 
removed.  Because the index /points/ to the physical row, that is whey 
they must all be rebuilt or maintained, even while the arrival order is 
maintained.

Regards, Chuck

Pete Massiello wrote:
> The parm for KEYFILE(*NONE) will just compress out deleted records
> and not rebuild the access paths, it will be faster and not change
> the sequence.  If you use KEYFILE(*FILE) it will take longer, and it
> will rebuild all the access paths over the file, and not guarantee
> the records stay in the order.