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.
