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



John:

Rick is a good guy.  I believe him.  But not in all circumstances.

The file in question obviously gets written to a lot.  The program that we
are all talking about deletes a lot of records.  Inserts and deletes
traverse the "reuse deleted records" code.  If that code runs slowly, this
scenario is the worst.

This can be tested.  Create an empty copy of the file.  Use CPYF to copy the
data from the production copy to the test copy.  Time this copy and call it
A.  Use SQL to delete all the records.  Time this delete and call it B.
Clear the file.  Change the physical file to reuse deleted records.  Copy
the production file to the new file while timing and call it C.  Delete all
the records from the new file using SQL while timing and call it D.  Copy in
all the records from production while timing and call it E.  C minus A
divided by records is the additional cost per record to add records when
there are no available deleted records.  D minus B divided by records is the
cost per record to mark deleted records for reuse.  E minus A divided by
records is the cost per record to insert when a deleted record is always
available.  The actual cost to insert will be between "insert when none
available" and "insert with always available" since in some cases, deleted
records will be present and in other cases they will not be present.

I would run the test and decide from there.  It won't take long, the
information is perfect for your environment (there is no higher quality
information available anywhere), and it is valuable to you.  The same
thinking applies to all the other suggestions.  Pick the ones that you like,
test them, then pick the best one.

RJ

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of jpcarr@TREDEGAR.COM
Sent: Friday, February 09, 2001 6:39 AM
To: RPG400-L@midrange.com
Subject: RE: Fastest way to delete records.



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

Thats what I love about performance seminars,  They say those things and
people believe them.   I remember programmers arguing against having
functional subroutines because they went to a John Sears session and John
said that "For Performance straight top down programming is faster"

I went to an audio store one time and the sales man told me about a tape
drive that had .00000001 wow and flutter,  I asked "What can a human
physically hear?"  Well only about .01 .

Sorry for the rant.  But its like saying that 30 seconds off a 10 minute
runtime is cause for a change of programming techniques.

We use "Reuse Deleted"  on all our files and never have to worry about
them. And no noticeable performance impact.   Do we have huge files?  No,
Should we worry about IBM not "Promoting" reuse delete in our shop ?  No.

If I had a 100 million record file,  I would consider the impact.  Just as
Mr. Turner(who I know and respect) should consider the impact of
generalized  statements at seminars to people who think it applies
"Everywhere, everytime situations"

rant *off

John

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