My Way of Looping

[nevster]

** This thread discusses the article: My Way of Looping **
** This thread discusses the Content article: My Way of Looping **

I'm afraid I belong to the other school of thought where a priming read
is done BEFORE the DOW loop and read the next record before the enddo.
It stems from the good old days of indicators; eg DOW not *in99
If whichever indicator you were using to control the loop had been set on elsewhere in the program and not initialised before the loop? - oops!!
The opening SETLL does not set the indicator or the %EOF.

Also, the checks for EOF and record not wanted result in an ITER statement
ie; a glorified GOTO.
Why not just check if this is a required record?

setll keylist myfile;
reade keylist myfile;

dow not %eof(myfile);

If check = whatIwant;
-- process this record;
endif;

reade keylist myfile;
enddo;

The only time I would use the read inside the loop (at the top of the loop)
would be when using a DOU to make sure at least one attempt to read the file
was done and the indicator or %eof set accordingly but then that needs
another IF statement inside the loop to check %eof.

[lujate]

** This thread discusses the article: My Way of Looping **
I have used your "new" method for 5250 display files for years. I never really saw the need to do it with DB tables.

[BillR]

My Way of Looping

** This thread discusses the article: My Way of Looping **
I can't imagine why people prime the pump and then issue another read at the bottom of the loop. I've done "My Way" since 1998. I had a heck of a time convincing people that it basically saved a read by doing it that way. I don't use the DOW though. I use DOU. Don't know why either won't be as effective as the other.
orderKey setll S1ORDHSTD2
DoU %eof(S1ORDHSTD2)
orderKey readE S1ORDHSTD2
If %eof(S1ORDHSTD2)
Leave
EndIf

f the line is not marked as 0 in then Iter.
If S1HSTSEL <> *zero
Iter
EndIf
Enddo

[JonFParis]

** This thread discusses the article: My Way of Looping **
I also have been a long time proponent of the priming read approach - but that preference has nothing to do with indicators. To me it is a matter of the logic of the situation.

When entering such a read loop there is a difference between reaching EOF on the first read and on subsequent reads.

EOF on subsequent reads is an expected condition - you'd be in trouble if it didn't happen!

On the other hand, EOF on the first read is a condition that we need to warn the user about and more commonly perhaps signal it as an error.

Two logical situations - two reads.

[tcsbiz]

** This thread discusses the article: My Way of Looping **
It seems to me that LEAVE and ITER are just GOTOs in disguise and really shouldn't be used unless there isn't a better way. I prefer the read first, ask questions later approach. I think the resulting code is easier to read and makes more sense to me.

[BillR]

** This thread discusses the article: My Way of Looping **
Exactly Jon. And DOU at least lets you attempt one read (enter the loop) and do some stuff while DOW won't. You won't know why EOF happens.

[jazzjake]

The priming read approach is more efficient and less prone to errors.

** This thread discusses the article: My Way of Looping **
The priming read approach is more efficient and less prone to errors.

It does not cause an extra read to be executed as BIllR says. You just have two "read" lines in your source code.

Using the priming method you only check eof once per loop, the other way you check it twice per loop.

Also, In the non-priming method you are executing a block of code between the "read" and the "eof" check. In other words you do a read. a check eof, a block of code, and another check eof. It is possible for the eof condition to change in that block of code and cause unintended consequences.

"Iter" and "leave" are unstructured constructs which should be avoided. Loops and condition blocks should have only one entrance and one exit.

[BillR]

** This thread discusses the article: My Way of Looping **
I didn't mean to imply that it "saved a read"...it saved having two reads coded. Less confusing in my opinion....less code overall.

[Jguty]

** This thread discusses the article: My Way of Looping **
I think my favorite way of looping solves the problem of wether to put a read inside or outside the loop. I'm coding the read at the loop's "border" as part of the DOW condition. Please see example below, MYFILE is read in the procedure getNextRecord, I like the cleanness of this technique.

     FMYFILE    IF   E           K DISK
     D getNextRecord   PR              N

      /free
 
        Setll  (firstKey:secondKey) MyFile;
        DoW getNextRecord(); 
              If (field=condition );   // Check if wanted record
                ... ;                // Process record
              Endif ; 
        EndDo;
        *inlr=*on;
      /end-free
      
       //---------------------------------------------------------------
       // Read Next Record
       //---------------------------------------------------------------
     P getNextRecord   B
     D                 PI              N
      /free
       // Read data
         Read MyRecord;     
         Return Not %EOF;
      /end-free
     P                 E

[derek.foden62]

** This thread discusses the article: My Way of Looping **
I guess there is no right or wrong way, it is just down to personal preference. I tend to use something like

SetLL (CustomerCode) Orderfile;
For Ever;
ReadE (CustomerCode) OrderFile;
If %eof;
Leave;
EndIf;
If dontwanttoprocess;
Iter;
EndIf;
process record
EndFor;

where Ever is defined as 10i 0. DoU %eof may confuse someone else looking at the code since it does not actually do anything, DoW Not %eof is probably worse as it should not do anything but has not been initialised here!

If I needed to check at least one record exists I would use this before the loop

SetLL (CustomerCode) OrderFile;
If Not %Equal;
oops, no records
EndIf;

I prefer this construct as Iter should be allowed within the loop, imho the resulting code is tidier and easier to maintain. I have come across (badly) maintained programs with the Read at the end of the loop where Iter has been added without adding a Read prior to it
or where the priming SetLL and Read have been changed but the Read at the end of the loop.

[BillR]

My Way of Looping

** This thread discusses the article: My Way of Looping **

The priming read approach is more efficient and less prone to errors.

Also, In the non-priming method you are executing a block of code between the "read" and the "eof" check. In other words you do a read. a check eof, a block of code, and another check eof. It is possible for the eof condition to change in that block of code and cause unintended consequences.

I'm confused...where is "and another check eof" ? And if the first eof check works how can the eof condition change in the subsequent block of code. Example?

[D.Abramowitz]

** This thread discusses the article: My Way of Looping **
I never liked the idea of having two READE or two reads of any kind to establish a loop.

My preference is to have a single READE immediately after the DO statement. This is similar to the concept in the article.

I believe that the code appears more clear than to have the first read prior to the loop, and an additional read just before the end of the loop.

It is also my $.02 worth that clarity is important in any shop where code may be worked on by multiple coders.

Dave

[nevster]

** This thread discusses the article: My Way of Looping **
Clarity?

the setll and reade before the loop is, in effect, a chain (assuming that the keylists are the same)
The dow loop wont even be entered if the priming reade fails.
ie no matching records
So, why enter the loop anyway, then check eof just to leave again immediately?

[S.Lennon]

** This thread discusses the article: My Way of Looping **
I tend to like your approach and generally use something like it. I have no qualms about using Iter or Leave, but draw the line if the indention level is more than two.

The procedure suggestion is also good, but I suspect most folk won't take the time for it.

A quibble though, on your use of "DoW NOT EOF;" at the top of the loop. From reading the comments, it seemed like some people didn't notice that this was actually a "Do Forever" loop and the condition would always evaluate true.

Initially I read it as "DoW NOT %EOF;" which is quite different and potentially deadly if you access another file somewhere in the loop. I tend to do something like "DOW 'A' = 'A';" since this hides nothing and is also a positive construct.

At one time, in a former life, I was cute and used "DOU CowsComeHome", but that apparently confused quite a number of my off-shore colleagues.

Sam

[jazzjake]

** This thread discusses the article: My Way of Looping **
I'm sorry but DOW 'A' = 'A' is a terrible coding practice. Talk about confusing. Loops should be fully defined when thy are initiated. This is a basic structured programming principle.

Some argue that having the second read line makes the code more confusing. Actually having extra condition blocks makes the code more confusing and complicated than it needs to be.

The author of this article gives no reasons why his method should be preferred. The method with the priming read is both more efficient and complies with basic structured principles.

As to the argument that the author's method is less confusing; it is only less confusing because you have been writing your loops that way for years and that is what you are used to seeing. If that is the case then I would urge you to read up on structured programming and design patterns.