×
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.
On 18-Nov-2013 13:24 -0800, Stone, Joel wrote:
How can I estimate down-time required to RGZPFM a file? Is there a
utility or rule-of-thumb on these?
The easiest and most accurate is to perform the intended request on
the DBF network restored or duplicated to a test library on the same
partition and ASP. Depending on the characteristics of the deleted
records [mostly the ratio] and the total number of records, some
invocation variants of RGZPFM might be significantly better choices than
the /traditional/ reorganize request which is now effected with [the
defaults]:
RGZPFM ALWCANCEL(*NO) RBDACCPTH(*YES) LOCK(*EXCL)
Another means to estimate the /traditional/ invocation is to CPYF
FROMRCD(1) TORCD(*END) COMPRESS(*YES) FMTOPT(*NONE) into a duplicate of
the file, then CRTDUPOBJ each of the keyed LF [and each join secondary
LF, which requires the other files in that DBF network must have been
copied also]... in successive requests ordered as seen in DSPDBR MBR(named).
Because the effect of that /traditional/ reorg request is that the
access paths are "rebuilt synchronously at the end of the reorganize
operation", there can be great benefit [reduced time] by scheduling the
rebuilds with more desirable work management [than what the OS provides
by default], and with some level of parallelism.
Can it be killed if not completed OR will the file then be
compromised?
If a request to RGZPFM ALWCANCEL(*NO) is canceled [not an oxymoron],
the original data in the file member remains unchanged [data integrity
is maintained], but the logical Access Paths will be scheduled for
rebuild in the background in the RunPty-52 QDBSRV## jobs. Those
rebuilds can be held and the EDTRBDAP entries modified to *OPN, so the
Access Path rebuilds can be performed instead with any desired Work
Management by issuing an OPNDBF ACCPTH(*FILE) against the member(s) of
the file(s) in job(s) that have the desirable attributes; issued in the
order that is desired. Because the ability to process the Edit Rebuild
of Access Path entries can be cumbersome, the data can be locked
exclusive to the job doing the reorganize or preceding the reorg request
with CHGLF MAINT(*REBLD) to each AccPth for which the request is
supported, and then instead of OPNDBF the parallel jobs to rebuild would
use CHGLF MAINT(*IMMED).
midrange.com
