Unconfigured Ad Widget



No announcement yet.

My Way of Looping

  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    ** 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

    Lately, I've been preferring the procedure method mentioned earlier. Dow ReadFile()
    Last edited by BobGenis; 04-08-2011, 09:08 AM. Reason: added "lately"


    • #17
      ** 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;

      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.


      • #18
        ** 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