× 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: RE: Fastest way to delete records.
  • From: Kevin H <kevinh@xxxxxxxxxxx>
  • Date: Thu, 08 Feb 2001 20:04:21 -0500

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

Replies:

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.