Re: Intelligent Reorg #2 -- MIDRANGE-L

In our OS Director product, we do do inteligent Reorgs.  Based on the
AS/400 model & processor feature code, number of arms, deleted records,
active records, Access Paths, and some others we estimate the amount of
time to do a reorg, and then insure that it will complete prior to the
window that you have to do this type of work.

Pete Massiello
OS Solutions
http://www.os=solutions.com

Walden H. Leverich wrote:
> 
> Boy, if ever there was a request to enhance the OS, there it is! I don't
> think RGZPFM is smart enough to look at the file and see that all it needs
> to do is truncate the file space. If it was we could have _true_
> record-level reorgs. We could run a reorg for an hour a night until all the
> free space was at the end of the table and then run a nearly instantaneous
> truncate space reorg. In the immortal words of Tony the tiger, that would be
> "GRRRRRRRRRRRREAT".
> 
> -----Original Message-----
> From: D.BALE@handleman.com [mailto:D.BALE@handleman.com]
> Sent: Tuesday, May 15, 2001 9:54 AM
> To: MIDRANGE-L@midrange.com
> Subject: 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
> +---
> +---
> | 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
> +---

-- 
Pete Massiello
OS Solutions International 
Phone: (203)-744-7854  Ext 11.
http://www.os-solutions.com
mailto:pmassiello@os-solutions.com

+---
| 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
+---