|
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 +---
As an Amazon Associate we earn from qualifying purchases.
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.