RE: Fastest way to delete records.

["Richard Jackson" <richardjackson@xxxxxxxxxxxxxxxxxx>]

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