"Simon Coulter" <shc@flybynight.com.au> wrote:

>This topic has raised a few questions.  Here is the definitive
>answer (Conceited? Watashi?).

Modest? Anata? Simon, that was a very, very good answer and it certainly
put a stop to some off-beam replies that were trickling in. However, you
should never assume an answer is definitive in this forum. At the risk of
scratching an old sore then...    :-)


>Checking should be dome with CHAIN if you want to process
>the data in the program or SETLL if you are simply checking
>existence.  The raison d'etre behind these recommendations
>is avoiding exception overhead and data overhead.

This is the conventional wisdom, and the reasoning is sound, but I think
it's a bit too simplistic. If a record is found, CHAIN has the overhead of
importing the data and is therefore more expensive than SETLL. However, if
the record is not found then the CHAIN command is significantly less
expensive than SETLL as the latter command has to execute the code to
position the file. That, at least, is my understanding.

Therefore the guidance that I follow is:

If I want to process the record data:    CHAIN
If I want to test for existence:
     If the record is more likely not to exist than to exist:     CHAIN
     Otherwise:     SETLL.

This question came up a couple of years ago, and I think I persuaded a few
people then that I was right. Unless anyone knows better?

Dave Kahn, ABB Steward Ltd.


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


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].