× 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 11-Jan-2012 14:10 , rob@xxxxxxxxx wrote:
Is this possible (RGZPFM) while the member is active?

Yes, data for a member can be reorganized using RGZPFM while the member is actively being accessed either for read-only or for update in other jobs\threads. The capability of the effective "Reorganize While Active" is via the ALWCANCEL(*YES) specification. But the later question and comment seem to acknowledge that possibility exists, so the quoted\preceding question may intend to ask something other than what I infer.?

Can I do it without invoking some option to create numerous journal
entries?

The "traditional" RGZPFM ALWCANCEL(*NO) deposits just one entry, but the request requires exclusive access to the data. That request performs effectively one dataspace operation versus individual row I\O which involves potentially numerous row-level operations.

I am reading the ALWCANCEL(*YES) may involve numerous
journal entries.

Moving the data requires some level of tracking and the ability to ensure atomicity of the movements. As such, there necessarily will be logging which could be "numerous journal entries" when using the row-level invocation versus the dataspace-level reorganize invocation. There could instead be very few entries logged for the row-level implementation, if either the deleted rows are already at the location where they can be purged or when ordering the data much of the physical data is already in the expected RRN.

Even if there is a large amount of logging required to complete all of the work of reorganize, the effect can be spread over many separate requests instead of tracked to just one request. For example using *RPLDLTRCD, the work could be limited to 15 seconds at a time, having obtained an *EXCLRD lock, easily allowing for 30-second waiters with probably little impact; each 15-seconds of work limits the overall logging required for each burst of work, after which any review and cleanup can be done. Eventually after repeating the request many times, over perhaps even days, the final effect eventually could be completed within one final 15-second request. The locking level noted is just one idea [to further limit the times when the request can run] and may not be compatible with some applications [where the file will never be open only for read-only], but any of the supported lock levels could be used; then only row locks versus member\data locks and sufficient allowance for any waiters.

Another option is to take a copy from a prior sync-point or save [presumably of the database file network], and then apply any active changes to the original [since the copy\save] to that alternate copy after that copy has been reorganized; the copy can be reorganized without any logging, or created as a copy without any deleted rows and optional ordering. Of course any applied changes must by effected by key rather than by RRN. Then /switch/ the active applications to the new TABLE or database. If the application is not capable of switching, probably easier to deal with the increased logging. However, great benefits can come from enabling suspend and switch capabilities in an application.

<<SNIP>>

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.