RE: RGZPFM vs RSTOBJ

["Evan Harris" <spanner@xxxxxxxxxx>]

Well, that said, the concurrent option *can* cause issues if you are using a
modern tool like journaling (*smirk). I've seen it overwhelm a HA
environment because the individual writes and deletes dumped MILLIONS of
entries into the journal driving the target HA machine crazy.

You could start the re-org and then it cancel after a period of time to
allow working though the table "in batches"; I seem to remember that ops
navigator even shows you how far done it is (i.e. % re-orged) so you can
monitor what is happening.

The final re-org has to be done dedicated - it needs an exclusive lock - but
takes very little time as it is essentially just truncating the table. The
re-org while active moves all the deleted records to the "end" of the table.

Regards
Evan Harris


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, 28 August 2009 11:56 p.m.
To: Midrange Systems Technical Discussion
Subject: Re: RGZPFM vs RSTOBJ

RTM
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/dbp/rbaforeorg
types.htm
Really - RTM.

For many of you using the concurrent option will not be an option because 
you are loathe to use any useful tools on your data - like journalling. 
It's only been around for a decade or so therefore it must be still buggy.

See also "... requires exclusive use for only a few seconds..." in the 
above link.

For more detail
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/dbp/rbafomngpr
gz.htm

Rob Berendt