|
Dunno if much has changed with 4.5, but last I spake with Rick Turner and the performance lads in Rochester , they did not promote 'Reuse Deleted Records' attribute on files. Now, having said that, I have not followed the thread of this conversation, and I know that there are always 'general rules' that do not satisfy all situations, but if there is any way to avoid the 'reuse' option - I go that way..., esp. if this file is volatile. IMHO. kmh At 07:06 PM 02/08/2001, you wrote: >For what it's worth: > >After V4R4, timeslice has no effect. The value is still there for you to >change but it doesn't do anything. Priority does matter but it shouldn't in >this scenario. You should give an entire CPU to the task - if possible, use >the entire machine. > >Up to this point in the discussion, I haven't seen any attempt to share the >work over multiple CPUs. I would like to think about that before making any >suggestions but I think that it should be reasonable. > >I would look at the sort / reformat utility. It uses the most aggressive >buffering and the largest blocked gets of any low-level IO routines. When >executed by SQL, SORT can flush a large percentage of the pages from a very >busy 10 GB main storage pool. > >All of the solutions that I have seen in this thread so far are >batch-oriented. I want to question why you are purging in the first place. >Why not do something like reuse deleted records? Keep or build a set of >links to data that you want to purge. When the time is right, traverse the >links, copy each record to the backup file, delete each record then go to >the next link. The job could sit running forever. If the file was also set >to reuse deleted records, the space freed up by this operation would be >automatically reclaimed by the system - no reorganization would be needed. > >RJ >(speaking only for myself) > >-----Original Message----- >From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On >Behalf Of Mike Collins (syan) >Sent: Thursday, February 08, 2001 9:08 AM >To: RPG400-L@midrange.com >Subject: RE: Fastest way to delete records. > > >I would suggest you create the logical file keyed by the timestamp, and then >use SQL, as the SQL will then be able to run over an index already in the >correct order, rather than building its own. SQL will run faster than >writing >this in RPG. Other than that, make sure you run the job with a large >timeslice >and a hig job priority to ensure that it spends as much time as possible >active >rather than dequeued. >+--- >| This is the RPG/400 Mailing List! >| To submit a new message, send your mail to RPG400-L@midrange.com. >| To subscribe to this list send email to RPG400-L-SUB@midrange.com. >| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. >| Questions should be directed to the list owner/operator: >david@midrange.com >+--- > >+--- >| This is the RPG/400 Mailing List! >| To submit a new message, send your mail to RPG400-L@midrange.com. >| To subscribe to this list send email to RPG400-L-SUB@midrange.com. >| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. >| Questions should be directed to the list owner/operator: david@midrange.com >+--- +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-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.