Help! GO TO and PERFORM THRU!

It has been a while since I posted a summary of "approaches" to the LOOP with
immediate exist issue - with summary comments on the PHILOSOPHICAL issues with
"GO TO and PERFORM THRU".

Comments in no particular order.

1) For some (unknown to me) reason, the use of SECTIONS is more common in Europe
while the use of PARAGRAPHS without SECTIONS is more common in the US. (This
may impact the programming style).

2) The '02 Standard introduced "EXIT PERFORM <CYCLE>" syntax which is a good way
to exit from within an inline loop. EXIT PARAGRAPH and EXIT SECTION provide
similar functionality for performed paragraphs and sections.

3) If one is coding in (or maintaining) programs in the "older" pre-85 Standard
(no scope delimiters or inline performs), a (possibly the most common in the
US) way to handle "loops" with immediate "problem" exits was something like.:

001-MAINLINE.
PERFORM 100-INITIAL-STUFF THRU 100-IS-EXIT
PERFORM 200-LOOP THRU 200-LOOP-EXIT
UNTIL SOME-CONDITION
PERFORM 900-FINAL-STUFF THRU 900-FS-EXIT
.
....
200-LOOP.
PERFORM 800-READ THRU 800-READ-EXIT
IF NOT-EOF
IF FIELD-1 GOOD-1
IF FIELD-2 GOOD-2
IF FIELD....
NEXT SENTENCE
ELSE
PERFORM BAD-FIELD.
MOVE "Y' TO SOME-CONDITION-FIELD...
GO TO 200-LOOP-EXIT
ELSE
PERFORM BAD-FIELD-2
MOVE "Y' TO SOME-CONDITION-FIELD...
GO TO 200-LOOP-EXIT
ELSE
PERFORM BAD-FIELD-1
MOVE "Y' TO SOME-CONDITION-FIELD...
GO TO 200-LOOP-EXIT
ELSE
MOVE "Y" TO SOME-CONDITION-FIELD
.
PERFORM 300-PROCESS-REC THRU 300-PROCESS-REC-EXIT
IF NOTHING-WRONG
PERFORM 400-SOME-MORE THRU 400-SM-EXIT
ELSE
MOVE "Y' TO SOME-CONDITION-FIELD...
GO TO 200-LOOP-EXIT
.
PERFORM 400-WRITE-GOOD-AUDIT-TRAIL THRU 400-WGAT-EXIT
200-LOOP-EXIT.
EXIT.
...... AND SO FORTH

Now, there were variations on "naming" standards and whether one did a "read
first" within the loop or before it with a read at end, but this TYPE of
structure was VERY common and provided a way to "exit a loop" when there was a
"problem" or condition that meant one didn't want to perform the rest of the
routine (loop). With this "structure" the ONLY allowed "perform thru" was from
the paragraph to the "exit paragraph" associated with it and NO other paragraphs
were allowed in the "middle". The only allowed GO TO was to the "exit
paragraph" associated with the executing paragraph. .

4) a medium common variation on this structure (particularly in Europe) was to
replace


PERFORM 200-LOOP THRU 200-LOOP-EXIT
UNTIL SOME-CONDITION

by

PERFORM 200-LOOP-SECTION
UNTIL SOME-CONDITION

and change 200-loop paragraph to a section. There would still be an exit
(paragraph or section). If it was an exit paragraph within the
200-loop-section, then you would NOT need to do a "PERFORM THRU" - but if you
made it an EXIT SECTION, then the PERFORM would still need to be a "THRU"

5) With the '85 Standard, it was possible (but not always very readable) to
replace all of the above with nested conditional statements (with their scope
terminator). One could use CONTINUE and "switches" to make certain that when a
"bad situation" occurred, then the logic branch would be either just CONTINUE or
other minimal code - while the "good branch" contained most of the processing
logic.

6) With the '02 Standard, the use of EXIT PERFORM/PARAGRAPH/SECTION would allow
for a "quick" exist from within any performed logic whenever the "bad" situation
occurred. The controversy is/was that this really IS a "hidden" GO TO - but
that it could NEVER lead to "spaghetti" code with crossing logic paths. Also
this feature is not particularly widely implemented. (It does exist in several
compilers, but probably NOT most of them)

****

Ignoring the controversy on paragraphs and sections (very vocal but never with
any real resolution), the issue behind all of this is
- "strict" GO-TO-LESS programming
vs
- "semi-" structured coding (with only explicit or implicit GO TO of the
executing logic block)
vs
- allowing spaghetti code (where GO TO and PERFORM logic paths can cross)

Today, there is GENERAL (not universal) agreement that the latter is a "bad"
thing to do (and even to allow). Deciding between the first two approaches is
an "emotional" issue that never gets resolved based on any "facts" (at least
that I have ever seen). Certainly sticking STRICTLY to the first approach
prevents anyone from EVER falling into the 3rd one. On the other hand, if one
has a "strictly enforced" (even software) way of following the 2nd approach, it
rarely leads to "hard to maintain" code which is the REASON why the 3rd approach
is viewed (by most) as "bad".


--
Bill Klein
wmklein <at> ix.netcom.com


.

Relevant Pages

  • Re: Para1 THRU Para2
    ... HB>>> The best way to exit a paragraph this way is with an EXIT ... r> putting everything in one sentence makes the nesting too deep. ... One has to look at this logically, and create a transformation ...
    (comp.lang.cobol)
  • Re: COBOL aint quite dead - yet !
    ... sometimes I will replace the EXIT. ... the exactly the same label made into a comment. ... Putting in a paragraph label is a lightweight ... possibility of errors such as goto the wrong one, ...
    (comp.lang.cobol)
  • Re: COBOL aint quite dead - yet !
    ... sometimes I will replace the EXIT. ... was via the last paragraph. ... In Cobol a label may be the target of a goto, a perform, a drop ...
    (comp.lang.cobol)
  • Re: Infinite Loops and Explicit Exits
    ... Massive changes qualify as a 'redesign'. ... A perform of a section or a perform of a paragraph is no matter as both ... Afterwards they would reset the exit point back to what it ... > was a NULop. ...
    (comp.lang.cobol)
  • Re: Infinite Loops and Explicit Exits
    ... > COBOL program is that the program branched out of a perform range and ... paragraph and return to the next statement after the PERFORM command - ... paragraph as an exit from the performed paragraph. ... A way to exit a performed paragraph loop and go to the next statement (as though ...
    (comp.lang.cobol)