My Way of Looping

** This thread discusses the article: My Way of Looping **
A priming read/chain or whatever, and a DOxxx loop controling the entry and continuation of the loop, is by far the most efficient method of coding such a thing when you consider what and how many instructions the CPU has to process to complete a given read/qualify/process loop.

As for clarity...We're dealing with "coder" preferences. It may be somewhat "old hat" thinking with regards to efficiency, but that's still the whole idea for "good" programmers. That is to get it done as efficiently computer-instruction-wise as possible. Clarity won't matter as much as efficiency when your loop may have to process milllions of records. Translate: millions of records equals millions of checks for %EOF after the single-read within the DOxxx statement. And eliminating ANY extraneous or unneccessary code is what is at the core of being "good" little programmers in our collective minds.

Moral of the story...Do your best with what you know and learn from others. It won't matter how you code it because "good" programmers will change it to "The best known practices" when they find that inefficient code. And you should do so too. Clarity has a marginal appeal, but efficiency gets the job done and therefore always gets the blue ribbon. Of course

[Guest.Visitor]

** This thread discusses the article: My Way of Looping **
Of course you could do the following:

chain (CustomerCode) OrderFile;
if %found(OrderFile);
dou %eof(OrderFile);
'process the record'
reade (CustomerCode) OrderFile;
enddo;
endif;

Back in the day of indicators, the IF statement wasn't even needed since you could set the same indicator with the CHAIN and the READE not found and EOF condition. But the geniuses at IBM didn't code the CHAIN to give an %EOF so I just test for %FOUND condition. Most of the time, I need to do something if NOT %FOUND, so it isn't that big of a deal.

IBM used to have a performance problem with SETLL related to a logical view over multiple physical files. The problem was related to a SETLL to a record format in a logical where there was no matching key. The operating system would do an exhaustive search through the entire index before indicating there was no match. I don't know if they still have that problem, but I have been coding this way for YEARS to avoid the problem since the CHAIN command doesn't have the performance hit. I avoid using SETLL in most cases.

[BobGenis]

** This thread discusses the article: My Way of Looping **
I agree with jazzjake. Coding a DOW 'A' = 'A' renders the conditional looping statement completely meaningless. It forces the programmer to search elsewhere in the code not only for what is being iterated over but also the conditions that will cause iteration to stop. You might as well ditch the DO altogether and code

TAG    TOPLOOP


GOTO TOPLOOP

Lately, I've been preferring the procedure method mentioned earlier. Dow ReadFile()

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

[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

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

[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

[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?

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

[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

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

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

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

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