Re: estimating RGZPFM runtime

[CRPence <CRPbottle@xxxxxxxxx>]

  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.