Re: CHAIN vs. SETLL (was Re: DOW vs DOU)

[lgoodbar@xxxxxxxxxxx (lg - Loyd Goodbar)]

On Sat, 14 Jun 97 10:52:57 -0700, "Greg Thielen" <gregt@isda.com>
wrote:
>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".

I've been programming RPGIII for a couple of years now (I'm very new
to the AS/400 world I suppose) and I've used all the forms of CHAIN,
SETLL/READ(E) and RPG cycle mentioned in this post. I don't see any
problem with using a CHAIN/READ vs a SETLL/READ, depending on the
application.

I like CHAIN/READ because it saves a step in coding. And since I only
program RPGIII at the moment, the issue of CHAIN filling the input
buffer in III as opposed to not in II is irrelevant for me at this
time. 

I also think that the logic of assuming that SETLL/READ means
iterative i/o and CHAIN does not is false. Nothing substitutes for
reading the code and understanding it. I comment when necessary, but
some things should be self-explanatory. IE, EXSR MAIN *is* the main
loop, a programmer should know that's the heart of the program.

For the opinion that CHAIN is more advanced for programmers, nah.
Actually, the hardest thing to learn was how RPG cycle worked. It is
an incredibly useful tool, and I use that for some stuff, but the
majority of the time I want loop control.

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

I've never had the need to use DOU, and I really think it's a matter
of semantics. Both DOW and DOU accomplish the same thing in different
routes, as does CHAIN and SETLL/READ. A variety of tools for whatever
job is at hand. People have more than one screwdriver for the same
reason...

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

But it's this side effect that saves some coding time. I take
advantage of such side effects in language.

>And now for some real fun, lets debate:
>
>*IN90   DOWEQ*OFF
>KEY1    DELETRCD1        90
>        ENDDO

I'm at a disadvantage here, I don't use DELET much. However, I would
suspect this process is used in RPG cycle programs. I'm not sure I'd
like that for such a destructive process. I'd rather prefer loop
control.

>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

I have no problem with either of these constructs. As I said before,
just because you see CHAIN does not mean you can assume a single I/O.
Read the code. If you know these are in a delete subroutine, exactly
how you accomplish this is immaterial.

I've enjoyed reading the discussions of DOW/DOU, SETLL/CHAIN, etc. as
it gives me new ideas about the language.

 - lg -

--
For the most part [we] end up with a collection of whimpering machines,
whose flashing 12:00 is like a small cry to "please make me just a
little bit more intelligent." --Nicholas Negroponte, _being digital_
lgoodbar@tecinfo.com  ICQ#504581  www.tecinfo.com/~lgoodbar/
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *