RE: Intelligent Reorg #2

Boy, then I really read a LOT into that, didn't I? <g>  I just re-read his
post; I'm not sure how I missed his point.  We've been really pressed here for
reorgs on a couple of huge files but we don't have the disk space necessary to
do them without getting well into the "90% threshold".  So, we're looking to
develop a home-grown solution (read: "free") for something that happens very
infrequently.

I know what you mean, though, about not recovering any deleted space.  I
actually thought about this on the way home on Friday (committed, I tell ya!).
 The $64,000 question is, if you squeeze all of the deleted records to the end
of the file, does a RGZPFM on that file work faster than if you didn't do the
"squeeze"?  Would RGZPFM be smart enough (doubt it) on a reorg with no
reordering by key to realize that there are only deleted records at the end of
the file and just "chop" off the deleted records so that the next record added
to the file appears at RRN+1 of the last non-deleted record in the file?

- Dan
Dan Bale says "BAN DALE!"
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)

-------------------------- Original Message --------------------------
Dan (Bale),

I can't speak for Dan (Rasch) but it looks like he is creating a list of
files in a library, doing a DSPFD *MBRLIST to an outfile and then reorging
the files one by one based on a descending access path over field MLNDTR (#
deleted records.) If he was simply pushing deleted records to the back of
the file, as you are suggesting, he'd not recover any deleted space.

-Walden

-----Original Message-----
From: D.BALE@handleman.com [mailto:D.BALE@handleman.com]
Sent: Friday, May 11, 2001 6:12 PM
To: MIDRANGE-L@midrange.com
Subject: Re: Intelligent Reorg (was rtvsy


Dan, Dan, Dan,

Sorry I can't answer the question you were asking, but what are the chances
you might make that reorg code public?

I was not totally clear on the method you mentioned, but it sounds like your
reorg keeps the file in FIFO sequence?  I.e., if your first deleted record
is
at RRN #10 and the next non-deleted record is at RRN #20, you "move" the
undeleted record to RRN #10 and delete RRN #20?  And repeat the process til
you get to the end of the file?

Really curious about this...

- Dan
Dan Bale says "BAN DALE!"
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)

-------------------------- Original Message --------------------------
        
I am writing an intelligent reorg program that will sort an outfile
descending by number of deleted records and then reorg files in that
order until a time value is reached.  The program is already operational,
but I would like to add a before reorg message of the %ASP used and
an after message, giving the users an idea of how much disk we recovered.

I may even go further to tell them how much storage (instead of a percent)
was regained.

I could do a WRKSTSSTS and parse it, but a retrieve is alot cleaner.
Is there an API or such I could use here?

Thanks,
Dan Rasch - because if the human species concentrated on the really
important things in life, there would be a shortage of fishing poles!
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---