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


  • Subject: Can anyone comment on the reliability of the archive utilitie s s inJBA?
  • From: "David Shea" <dshea@xxxxxxxxxxxx>
  • Date: Wed, 12 Jul 2000 08:44:39 -0400

This didn't go through the first time, so I'll try again...

----- Original Message -----
From: "David Shea" <dshea@arctools.com>
To: <JBAUSERS-L@midrange.com>
Sent: Monday, July 10, 2000 5:48 PM
Subject: Re: Can anyone comment on the reliability of the archive utilitie s
s inJBA?


> WARNING - this method will work, but beware... you should NEVER kick off a
> reorg job unless you have a pretty good idea how much time it will take.
If
> you start reorg-ing a humongous file with millions of records and lots of
> logicals built on top, you could be in for a LONG wait.  Plus, if you
start
> reorg-ing some huge beast, this is not something that can be stopped.  You
> _have_ to let it finish.  If you reorg takes three days, you're screwed.
> This should work fine if you've got reasonable file sizes, but if you've
got
> a lot of data, watch out.
>
> Instead, you might want to put the results of this program's DSPFD command
> into a file, then use query to review it.  Look for files with high
> percentages of deleted records.  Reorg some of the smaller ones first to
get
> a feel for the time requirements.  Work your way up the chain, slowly and
> carefully.  Choose some percentage value as a cutoff, below which the
> benefit of reorg-ing may not be worth it. Don't reorg if you only have a
few
> deleted records.  The old 80/20 rule probably applies -if there's 20
percent
> deleted records, maybe it's worth it.
>
> But - if you've got some of these huge beasts that may take days to reorg,
> you really need to do it at some point (this is why we in the IS business
> never get any long weekends, right?).  Once it's reorg-ed, consider either
> reorg-ing on a regular basis or using REUSEDLT to keep the wasted space
> down.  Be careful with REUSEDLT, though too, because some apps run some
> things by RRN.
>
>
> From: <CMassoglia@dawnfoods.com>
> To: <JBAUSERS-L@midrange.com>
> Sent: Monday, July 10, 2000 2:09 PM
> Subject: RE: Can anyone comment on the reliability of the archive utilitie
s
> s inJBA?
>
>
> >
> > This is a utility we use to reorganize all files.  We got back 5+GB.  We
> > have also changed physical files to REUSEDLT(*YES).
> >
> > Command RGZALLPFM:
> > /*
*/
> > /*  RGZALLPFM - REORGANIZE ALL PHYSICAL FILES
*/
> > /*              COMMAND PROCCESSING PROGRAM - RGZALLPFMC
*/
> > /*  21 MAR 90 - CLM
*/
> > /*
*/
> > /* COPYRIGHT 1990 ALL RIGHTS RESERVED                           */
> > /* MPH, INC., OKEMOS, MI USA                                    */
> > /*                                                              */
> >              CMD        PROMPT('Reorganize all physical files')
> >
<snip>

+---
| This is the JBA Software Users Mailing List!
| To submit a new message send your mail to JBAUSERS-L@midrange.com.
| To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com.
| To unsubscribe from this list send email to JBAUSERS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: doug333@aol.com.
+---


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.