Re: estimating RGZPFM runtime

While with both REUSEDLT(*YES) and "RGZPFM while active, we would lose RRN integrity", the /online reorganize/ feature need not allow concurrent activity; i.e. need not be a "while active" invocation. Nor does it seem, that the described process even allows for concurrent access anyhow. So...

If the /farming/ can detect that the row of data represented by the rrn=789 has become rrn=456 due to a RGZPFM ALWCANCEL(*NO), then there seems no obvious reason that the same processing [or possibly slightly modified processing given a subtle reason] would be unable to detect that the new RRN were any other possible value; e.g. due to use of the following similarly exclusive /online reorganize/ request. That is because apparently, although lacking an implemented primary key, the processing must be [is still] able to know that the Cheerios are the same Cheerios, since before until after the reorganize.?

RGZPFM ALWCANCEL(*YES) RBDACCPTH(*NO) LOCK(*EXCL)

Because the access paths with the above request do not need to rebuild, and are not "rebuilt synchronously at the end of the reorganize operation" as they would for the /traditional/ RGZPFM, then that request in some cases [e.g. very large files] can be much quicker than the traditional reorg request [ALWCANCEL(*NO)] that preserves sequential ordering. Files with fewer active rows than deleted rows probably benefit most from RBDACCPTH(*OPTIMIZE). Rebuilding [some of] the access paths in parallel after the reorganize request can also decrease the runtime of the traditional RGZPFM.

Regards, Chuck

On 18-Nov-2013 14:38 -0800, Stone, Joel wrote:

No I don't agree. I don't think re-using deleted records has any
chance of working for us.

If it is a controlled process, it should work OK as is using RRN.

Example: Cheerios cereal

Monday 9 pm:
(Cheerios is item #123 in RRN 789)
lock users off app
dump journals and process them
allow users back into app

Tuesday morning:
Cheerios price is changed by user from $3 to $3.05

Tuesday 9 pm:
lock users off app
Dump journals and process them
Farming journals detects user changed Cheerios - sees RRN 789 has
"Before" vs "After" journal image discrepancy in user data area
Cheerios price change is reported

Tuesday 10 pm: RGZPFM on file containing Cheerios record
Cheerios retains item# 123, but moves up to RRN 456 due to some
records being deleted from above during the day

Tuesday 11 pm:
journal reporting window "start time" is moved forward to 11 pm so
tomorrow night's journal farming activity skips over RGZPFM changes

Tuesday 11:01 PM:
allow users back into app

Now all should be back to normal and ready to start a new cycle.

If we were to allow re-use deleted records, I think that we would
need a real "primary" key (immutable key) which we don't have on
these files which were designed in the late 1970s.

Anyone agree or disagree or have any better ideas???

Charles Wilt on Monday, November 18, 2013 4:23 PM wrote:

If you use RQZPFM at all you'll lose RRN integrity...

You'd be best served by reusing deleted records.

On Mon, Nov 18, 2013 at 5:16 PM, Stone, Joel wrote:

Another caveat I should have mentioned is that we do "farm the
journals" looking for user data changes. The journal processing
depends on the RRN being intact and unchanging between journal
dumps.

For example if Cheerios is item# 123 and was in RRN slot 789
yesterday, then it had better be in slot 789 again tonight with
the next journal farming activity takes place.

I am afraid if we use RGZPFM while active, we would lose RRN
integrity.