Re: %EOF, %FOUND and the infamous Dou loop -- RPG400-L

Simon Said;
>> which is clean, obvious, and is probably what we should have been
writing

<SNIP>

C     00202         CHAIN     ORDDTLR
C                   IF        ( %FOUND(ORDDTL) )
C                   DOU       ( %EOF(ORDDTL) )
C                   EVAL      detail = detail
C     00202         READE     ORDDTLR
C                   ENDDO
C                   ENDIF

<SNIP>
-------------------------------------------

Which I agree with.   I just change file names and keylist names,
the tests are always 100% the same. hardly ever a variation.

     Key2 SETLL     FILE

          DOU  %EOF(FILE)
     Key1 READE
          IF   %EOF(FILE)
          LEAVE
          ENDIF

          IF   Code =    'x'
          ITER
          ENDIF

          (process)
          ENDDO


I love those DOW loops with 50 statements or more between the DOW and the
READE and then some neophyte puts in a ITER not knowing that ITER's don't
work with DOW and we all sit and watch the lights dim while the  machine
gets "REAL Good" at knowing the statements it will run next.

James I think said;
>This also gave programmers a little flexibility in "style" that, IMO, is
>easier to read than the BIFs

I generally don't give programmers "Flexibility in Style"  unless they
agree to come back after they leave and maintain their "Stylish" code for
free.


The other point about not being able to Debug a %EOF or similar BIF,  I
find it an rare occasion that that is something I am not sure of.  I can
inspect the contents of the KeyList,  I can determine if a record exists,
That in my experience is rarely where I am not sure of the results. (In my
experience that is).

Joe,
You said;
>IBM is the vendor.  I am the customer.  If every time I made a change, my
>clients had to change how they ran their business, I suspect I would be
out
>of clients very soon.  You don't seem to think that's a problem.  We have
>different world views.

Look at MS and the move from VB to .NET,  Now there is a vendor that BREAKS
stuff. Your "Before" code with indicators still work just like they used
to.   The new %BIF do not behave exactly like Indicators, That is
different.  I understand your position, It was a mild "Learning Curve"
thing when I first noticed it also.
But for me it was just that, A mild irritation.   Personally.


jt

My "New" programs are basically taking "Whole" sections from prototypes.  I
can't remember the last time I keyed in an Fspec or a Read Loop.  It just
doesn't happen.  That is my technique.  I generally take sections of
Pre-Tested parts and "Assemble" more than key in new.   The Creation aspect
is using the pre-existing "Parts" to solve a new business problem.  The
code in our shop,  you'd have to look at the top comments to know who wrote
it.  IT ALL LOOKS EXACTLY THE SAME.   The exact same mechanics used from
implementation to implementation. (Hence my response to James's point.)  We
even have a very simple and very SELF evident Keylist naming strategy. The
Keylist names and Subroutine names for example are the EXACT same from
programmer to programmer.

The creativity the business is paying for is in the solution of the
business problem, not some neat algorithm this programmer thinks is nifty.

soapbox *off
Returning to Lurking mode.

Respectfully,
John Carr