Re: CHAIN vs. SETLL (was Re: DOW vs DOU) -- MIDRANGE-L

Dave,

I don't mean to beat a dead horse (we're going to end up agreeing to
disagree), but I'm just now getting around to replying...


On 31 May 97 04:29 GMT, Kahn, David wrote:
>
>I think you're right that a successful CHAIN does not set the file cursor in 
>RPG/II. However, it always has in RPG/III. This may help explain the 
>persistence of SETLL/READE as a technique with RPG/III programmers. They're 
>used to seeing it that way so they recognise it quickly and continue to 
>code.

Evidently I was wrong about the CHAIN issue with RPG II according to
others.  It's been about 15 years since I've even seen a System/34,
so I guess my memory has faded somewhat.  I do seem to remember there
being some issue with this, but I disagree that this has fueled the
persistence of SETLL/READE as a technique.  

>It's habit rather than effective use of the language definition. 
>However, in RPG/III a successful CHAIN sets the file cursor and RPG 
>programmers should be aware of that.

I couldn't disagree with this more.  As we've seen in this thread,
"effective use of the language definition" is very subjective.  You
imply that SETLL/READE is a poor techinque and that any
self-respecting programmer would use CHAIN instead.  I can argue the
opposite: that the use of CHAIN obscures the fact that you intend to
read a series of records.  I agree that programmers should be aware
of CHAIN's behavior, but we both know how that goes.  We all started
as junior programmers at one time, and the underlying behavior of
CHAIN is not something that's generally known until we "learned to
walk".

>Another reason it has persisted, of 
>course, is that it lends itself naturally to a DOU loop with the read at the 
>top. If I were to code such loops using DOU then I would use SETLL outside 
>the loop and READE within it, but I don't so I don't. Looked at the other 
>way, SETLL/READE may help account for the popularity of DOU.

I find this quite a stretch.  I really don't think people consciously
or unconsciously think "Gee, I want to use DOU, so I'll use
SETLL/READE..."  I've always used DOW for loops like this (just can't
stand the SETLL/DOU/READE/IFEQ structure), and from my personal
experience this seems to be the pervasive technique.

>
>You see CHAIN/READE or CHAIN/READ as "cute". I see SETLL/READE as clumsy and 
>SETLL/READ as a useful construct allowing you to set the file cursor and 
>read on when a key match may not be present in the file. To me the use of 
>SETLL simply means "set the file cursor" and CHAIN means "get a record, 
>setting the file cursor if found".

Here's where we'll have to agree to disagree.  I don't see
SETLL/READE as "clumsy" by any stretch.  I do see it _implying_ an
iterative I/O process, where CHAIN implies a single I/O operation
even though its behavior is as you describe.  As you poing out, SETLL
alone does mean "set the file cursor", but followed by READE it
implies that a series of records are going to be read.  You could
argue that CHAIN followed by DOWxx implies the same thing, but I
would still disagree.  CHAIN's primary use is to get a single
specific record, and it has the "side effect" of setting the file
cursor in the process.  READE's primary use is to get the _next_
record in a series.  I believe in using the right tool for the job. 
I don't use a hammer to start a screw (even though it can be done),
and I don't use CHAIN start an iterative read process.


And now for some real fun, lets debate:

*IN90   DOWEQ*OFF
KEY1    DELETRCD1        90
        ENDDO

as opposed to:

KEY1    SETLLRCD1
KEY1    READERCD1        90
*IN90   DOWEQ*OFF
        DELETRCD1
        READERCD1        90
        ENDDO

or in your case, Dave :)

KEY1    CHAINRCD1    90
*IN90   DOWEQ*OFF
        DELETRCD1
        READERCD1        90
        ENDDO


Adding fuel to the fire and fanning the flames.....



-------------------------
Greg Thielen
Innovative Systems Design
gregt@isda.com
http://www.isda.com


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