Newsletters   Subscriptions  Forums  Store   Career  Media Kit  About Us  Contact  Search   Home 
fhg
Volume 5, Number 29 -- July 27, 2005

Of Middle-Tested Loops


Hey, Ted:


I recently came across the Recursion and the Alternatives story that you wrote, which gives an example of a program that explodes a bill of material. I noticed that in this program, you used the following statement:

DOW      '1'

Can you explain what this means? I have been preaching the importance of readability in programs and this baffles me. It seems like it would be better to code something like DOW NOT %EOF(MYFILE). I am actually using a modified version of your "Chase" routine, but this DOW '1' statement bugs me.

--Eric


This is not the sort of thing I like to deal with in Four Hundred Guru. I prefer to address practical problems, and how a person codes loops seems like small potatoes to me. However, I've received some email about this topic, and this topic shows up occasionally in Web forums, so here goes.

RPG has been a very successful language because it is suited for business computing tasks, especially file processing and report generation. In all its forms, even indicator-infested RPG II, it stands in contradistinction to academic, scientific, and mathematical languages such as those I have studied, used, and taught. To sum it up in one word, RPG is practical.

But RPG is not perfect. Consider its looping structures. There are three: a top-tested loop, which controls operations that may not need to be executed at all; a bottom-tested loop, which controls operations that must be executed at least once, and a counted loop.

But many loops don't fit these patterns. RPG lacks a middle-tested loop, a structure to control a set of operations that must be executed at least once and a set of operations that may not need to run at all. Look at this section of code from the article Eric mentioned.

C                   dow       '1'
C                   read      EndItem
C                   if        %eof()
C                   leave
C                   endif
C                   callp     Chase (EI_ItemNbr: EI_ItemNbr)
C                   enddo

This example contains both top-tested and bottom-tested operations. The READ must be done at least once. The CALLP may not run at all.

The DOW '1' construct sets up an infinite loop. It's up to the programmer to ensure that at least one LEAVE is coded in the loop somewhere. Consider the alternatives. Here are two.

C                   read      EndItem
C                   dow       not %eof(EndItem)
C                   callp     Chase (EI_ItemNbr: EI_ItemNbr)
C                   read      EndItem
C                   enddo

This version uses a top-tested loop, but requires that the READ be duplicated.

C                   dou       %eof(EndItem)
C                   read      EndItem
C                   if        not %eof(EndItem)
C                   callp     Chase (EI_ItemNbr: EI_ItemNbr)
C                   endif
C                   enddo

This version uses a bottom-tested loop with a redundant test for end-of-file. Neither of these seems an improvement to me over the DOW '1' method.

Another problem is that loops are often terminated by more than one condition. For instance, end-of-file might be the normal way to stop a loop, but a certain error condition might also stop it. DOW NOT %EOF gives the impression that there is only one way to stop the loop. A middle-tested loop would contain two LEAVE operations, which makes it obvious that more than one condition can terminate the loop.


I've coded middle-tested loops various ways and I like this method best of all. Once you get used to it, which doesn't take long, it's as intuitive as DOW and DOU.

I would like to see IBM add another looping structure that could handle top-, bottom-, and middle-tested loops. Here's a suggestion.

C                   loop
C                   read      EndItem
C                   if        %eof()
C                   leave
C                   endif
C                   callp     Chase (EI_ItemNbr: EI_ItemNbr)
C                   endloop

I like Eric's premise, which is that code should be readable. I have to work on the code of people who didn't share his programming philosophy.

--Ted

Sponsored By
PRODATA COMPUTER SVCS

What if 'i'...... do DBU & ProData products?

Then I'd have all the solutions!
Unleash the power of 'i' today!
DBU...the iSeries #1 database utility.
DBU Audit...log changes & views made via DBU.
DBUnifier...unify database apps & dump DFUs!
RSP...RPG Server Pages for web-enablement.
STE...to test your stored procedures easily.
SQL/Pro query & reporting tools.

All ServerProven products that are virtually FREE with IBM's rebate offering!
Sign up to WIN a Flat Screen Monitor!
www.prodatacomputer.com
Email sales@prodatacomputer.com


Technical Editors: Howard Arner, Joe Hertvik, Ted Holt,
Shannon O'Donnell, Kevin Vandever
Contributing Technical Editors: Joel Cochran, Wayne O. Evans, Raymond Everhart,
Bruce Guetzkow, Marc Logemann, David Morris
Publisher and Advertising Director: Jenny Thomas
Advertising Sales Representative: Kim Reed
Contact the Editors: To contact anyone on the IT Jungle Team
Go to our contacts page and send us a message.


THIS ISSUE
SPONSORED BY:

ProData Computer Svcs
Advanced Systems Concepts
Patrick Townsend & Associates


Four Hundred Guru

BACK ISSUES

TABLE OF
CONTENTS
Of Middle-Tested Loops

Use SQL to Easily Update Multi-Key Files

Admin Alert: To Each Its Own in Spooled File Management


The Four Hundred
iSeries Programmers Irate Concerning CGIDEV2 Limbo

Is Security the First Step Toward Regulatory Compliance?

iSeries Sales Increase by 10 Percent in Q2

As I See It: In Defense of Entitlement

Four Hundred Stuff
SafeData Launches Hosting Service for HA and DR

Circuit City Streamlines Tedious Testing Tasks with TestBench

SoftLanding Enhances Open Source Change Management System

Cozzi Updates RPG xTools, Partners with Linoma

Four Hundred Monitor


Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved.
Guild Companies, Inc. (formerly Midrange Server), 50 Park Terrace East, Suite 8F, New York, NY 10034
Privacy Statement