RE: CHAIN versus SETLL

Bob,

>The issue with SETLL vs CHAIN is that SETLL doesn't lock the database 
>record when you're just checking to see if the record exists. However, the 
>new N (no lock) operation extender (that's the old "Half Adjust" column to 
>you RPGII coders) essentially provides a way to avoid locking the db 
>record. CHAIN is a direct-to-the-record process, whereas SETLL does 
>(metaphorically speaking) a CHAIN with no lock, followed by a READP.  This 
>allows the next READ to access the next record in the file. (It doesn't 
>actually do a READP, folks, so don't write letters <g>).

>So I suppose there is a little performance difference in that CHAIN with No 
>lock does fewer things. But hey, I don't believe in rules that say "This is 
>always better than that".  If SETLL does the job the right way for the task 
>at had, USE IT!  If CHAIN with No lock works for you, then use that.  In 
>either case, you probably won't shave enough off a job that runs 2 or 3 
>hours to notice.
 
 You left out the fact that a CHAIN fills the input buffer, whereas SETLL
doesn't.  This will of course affect performance as well as the logistics of
the implementation.

 -mark
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *