×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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 mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
