My Way of Looping

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

[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

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

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

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