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.

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page