× 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.



(I have taken the liberty of replying to this original RPG400-L post on
MIDRANGE-L.  The original poster asked about the time required to reorg a
huge file.  Responders suggested looking into reorg-in-place commercial
products.  The thread history in this context follows my response.)

In particular, I am writing about the technique that this "product" uses
(and I presume that other "products" i.e., Turnover, use this same technique
as well).  Generally speaking, it seems that the general technique is as
follows:

1) Create empty duplicates of the physical and its logicals in a new
temporary library.
2) Start journaling the file.  (before only?  before & after?)
3) Submit a job to CPYF the production physical to the temporary physical
4) After step 3 finishes, start applying journal changes to the temporary
physical (don't know if this is a home-grown app or if command will let you
do this to a different file from the journaled file).
5) Once step 4 is pretty much "caught up", find a spot of time to grab
exclusive use of the production file, apply the last of the journal changes,
rename the original production physical and its logicals, and move the files
from the temporary library into production.

Is this pretty much it?  This really shouldn't be beyond the capabilities of
most experienced AS/400 pros, unless there's one or more small tricks or
gotchas that need to be considered.  Plus there's the fact that the typical
candidate file is usually a critical file required for the continued
operation of a company; mess it up in any small way, and the bankruptcy
lawyers sign your next check.  I'm thinking there may be other
considerations that are linked to the original file object that does not
relink to the new file object, i.e., triggers?  Others?

Of course, if the commercial apps to do this type of reorg is reasonably
priced, then it may be more penny-wise and safer to use that type of
solution.

- Dan Bale
(I am *NOT* "Dale"
http://archive.midrange.com/midrange-l/200105/msg00281.html )
SAMSA, Inc.
989-790-0507
DBale@SAMSA.com <mailto:DBale@SAMSA.com>
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)

-----Original Message-----
From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]On
Behalf Of Nicolay, Paul
Sent: Thursday, April 18, 2002 9:07 AM
To: 'rpg400-l@midrange.com'
Subject: RE: Re-Organize File


HI,

http://www.iterainc.com/products2/reorg_while_active.doc is one of them...
don't have experiences with it however.  I think I saw different ones in the
Midrange newsletter but can't find it immediatly (maybe it was even the
same).

Kind regards,
Paul

-----Original Message-----
From: JJW [mailto:rpgilejjw@charter.net]
Sent: 18 April, 2002 14:45
To: rpg400-l@midrange.com
Subject: Re: Re-Organize File


Not what I wanted to hear, but what I had expected to
hear.  Thanks for the quick responses.

Anybody know of any products that can re-org files faster
than RGZPFM or CPYF?

TIA!!!

On Thu, 18 Apr 2002 08:24:30 -0400
  "Fisher, Don" <Dfisher@roomstoreeast.com> wrote:
>We had a file similar to that on our model 720 with two
>processors and it
>took DAYS to execute an RGZPFM command.
>
>On the other hand, copying the file, as Paul suggested,
>only took about
>eight hours.  Granted, the file only had about four
>access paths to rebuild.
>
>Hope that helps.
>
>Donald R. Fisher, III
>Project Manager
>The Roomstore Furniture Company
>(804) 784-7600 extension 2124
>DFisher@roomstoreeast.com
>
><clip>
>Given the following: I have a file that has Total records
>= 75 million and Total deleted records = 50 million and
>there are 25 logicals attached and total record length is
>442.
>
>How long would RGZPFM take to run over this file?
><clip>



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.