Re: estimating RGZPFM runtime

I would think that a before/after image would be in very close proximity.
Granted there's no guarantee that they will be consecutive in a high
volume environment. Right? However, I would think they would be close
enough together that you would not be able to fit a reorg between them.
Active or dedicated.
Sequence Code Type Object Library Job Time
24706634 R UB ITEMMSTR ROB ROBS1 11:12:05
24706635 R UP ITEMMSTR ROB ROBS1 11:12:05

IDK how you activate these fields
Logical unit of work :
Transaction ID . . . :
or if they would help your tying it all together.

Sorry about the farm the journals. I thought you were dumping them
another file for perceived easier processing. Must have been another
poster...

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Stone, Joel" <Joel.Stone@xxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 11/19/2013 11:04 AM
Subject: RE: estimating RGZPFM runtime
Sent by: midrange-l-bounces@xxxxxxxxxxxx



You lost me at your first statement.

I am thinking that you HAVE to rely on RRN when processing the journals.
How else can you compare the BEFORE & AFTER images and be sure that you
are comparing the same entity?

When I say "farm the journals" I am referring to the same thing you are
doing; ie "read the journals".



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, November 19, 2013 8:36 AM
To: Midrange Systems Technical Discussion
Subject: Re: estimating RGZPFM runtime

1 - We journal like crazy and use it to audit transactions. We do not
rely upon RRN. Then again, we read the journals - not some journal farm
created by processing the journals.
2 - Reorg while active, or reorging while not active, will have the same
effect. RRN's are going to change. You may want to consider the one
poster's idea about disabling the journal during the reorg. Modify his cl

by adding your journal farm request right before the reorg, if you still
want to stick with your journal farm.
3 - If you can adapt your train of thought to accept the RRN change
associated with reorganization you might want to consider reuse deleted
records. The only difference being is you can snapshot your journal farm
around the reorgs, not around the reuse.
4 - You may want to consider the KEYFILE parameter of RGZPFM. This can
help your performance on reading. Use the DB tools to see the most
popular index or suggested index.
5 - If you do start using reuse deleted records, and the number of deleted

records doesn't get terribly skewed, then you should never have to do a
dedicated RGZPFM. For example, if you're going to have roughly the same
number of deleted records every night due to some process you may as well
not try reorging to get the disk space back since it will need it again
the next night. However, if you recently discovered that you're dropping
from retaining 15 years of history to just 2, then by all means, reorg to
get the space back. Or one oopsie runaway job really stuffed it full of
garbage you cleaned out, then reorg to get that space back.

Trying to duplicate the reorg on a different lpar, test library, etc can
be a terrible waste of time. Unless you're very certain all things are
equal: memory, disk, controllers, current load on system, etc. Well,
normally your second setup is less powered than your primary so it may
show you 'worst case'. Keep in mind that some indexes may be configured
for delayed rebuild and be doing that in the background so you'll have to
check out some system tasks for that to see when it's 'really' done. But
if you do the duplication by some process that inherently does a reorg,
like certain options of CPYF or CRTDUPOBJ, then your results will again be

quite skewed.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Stone, Joel" <Joel.Stone@xxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 11/18/2013 04:24 PM
Subject: estimating RGZPFM runtime
Sent by: midrange-l-bounces@xxxxxxxxxxxx



How can I estimate down-time required to RGZPFM a file? Is there a
utility or rule-of-thumb on these?

Can it be killed if not completed OR will the file then be compromised?

Thanks!



______________________________________________________________________
This outbound email has been scanned for all viruses by the MessageLabs
Skyscan service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


________________________________________________________________________
This inbound email has been scanned for all viruses by the MessageLabs
SkyScan
service.
________________________________________________________________________

______________________________________________________________________
This outbound email has been scanned for all viruses by the MessageLabs
Skyscan service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.