MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » June 2008

Re: RGZPFM quick question



fixed

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.





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

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact