Re: Infinite Loops and Explicit Exits

From: Chuck Stevens (charles.stevens_at_unisys.com)
Date: 11/02/04 

Date: Tue, 2 Nov 2004 12:39:26 -0800

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9K6NMeKPflB@jpberlin-l.willms.jpberlin.de...
> . On 29.10.04
> wrote charles.stevens@unisys.com (Chuck Stevens)
> on /COMP/LANG/COBOL
> in clu41g$1t2b$1@si05.rsvl.unisys.com
> about Infinite Loops and Explicit Exits
>
>
> CS> One of these proposals relaxes the current restriction that an EXIT
> CS> PERFORM or EXIT PERFORM CYCLE statement may only appear within a
> CS> PERFORM ... END-PERFORM range.
>
>
> I put here my answer which I had written answering another message
> by you, since this message had, as I saw on groups.Google.de,
> generated quite a debate, and I think that my answer should be here.
>
> I will add some observations on loops in general which had been
> discussed unter "Report enhancements" and then "Perform loop
> enhancements".
>
>
> . On 28.10.04
> wrote charles.stevens@unisys.com (Chuck Stevens)
> on /COMP/LANG/COBOL
> in clro7b$9sf$1@si05.rsvl.unisys.com
> about Re: Perform loop enhancements
>
>
> >> Too bad that ability isn't complete.
>
> CS> Which ability? The ability to do an EXIT PERFORM CYCLE in an
> CS> out-of-line PERFORM? Yeah, I think I'd argue for that, unless
> CS> (again) somebody can convince me it's a bad idea!
>
> I think it is a _very_ bad idea.
>
> A "PERFORM some-procedure UNTIL some-condition" is something which
> I would avoid, since the ripening of the condition which leads to the
> termination of the loop is not visible at that point. One should
> better PERFORM a sequence of local statements (which might be calls to
> remote procedures via PERFORM or CALL or INVOKE or FUNCTION) where the
> terminating condition is visible in that context.

However, this construct has been in COBOL since its earliest days and is in
no way deprecated in the standard. Inline PERFORM is of recent
introduction.

> To introduce a condition _within_ such a remote procedure being
> PERFORMed in a loop which terminates the loop under a _different_
> condition than the one formulated on that procedure call, i.e. PERFORM
> itself, is really obfuscating the flow of the program.

Well, I see your point, but I'd argue that having an inline PERFORM
statement occurring thousands of lines before its associated UNTIL, as well
as having an EXIT PERFORM and/or an EXIT PERFORM CYCLE buried somewhere in
the middle of those thousands of lines based on conditions that might have
nothing whatever to do with the UNTIL, is perfectly legitimate TODAY. What
isn't legitimate is turning those thousands of lines into a paragraph so
that the UNTIL is closer to the PERFORM, and having *that* work, because the
EXIT PERFORM and the EXIT PERFORM CYCLE wouldn't be legal.

> One would have a statement which calls a remote procedure in a
> loop, stating the conditions under which this looping execution is to
> be terminated (or not started at all), where we would normally expect
> that this remote procedure is somehow producing the condition which
> was named on the call-loop instruction, so that this loop terminates.
>
> You now want to allow this remote procedure, not visible to the
> looping-call statement, to simply terminate the loop, possibly
> _without_ the termination condition specified on the loop-call
> instruction, to terminate the loop. Normally one would assume that the
> terminating condition on the loop instruction is a valid assertion
> that the next statement following that loop-call instruction can rely
> on, but what you propose, makes that assertion invalid or dubious.

Again, because there's no practical limit to the size of
imperative-statement-1 in an inline PERFORM, I'd argue that the obfuscation
issues are not that different from those that obtain with current rules.

> I advise against such obfuscation of program flow, and I hope that
> my argument has been convincing.

I'm not convinced that either EXIT PERFORM or EXIT PERFORM CYCLE is somehow
inherently a Bad Thing in an out-of-line PERFORM given that the construct
has been recently introduced as a Good Thing in an in-line perform, and
given that at least one implementation has had EXIT PERFORM (or similar
functionality) in out-of-line PERFORMs in its COBOL, to the delight of its
customers, for the better part of three decades!

> Let me add that allowing to break a loop in a procedure being
> executed by a COBOL statement "PERFORM some-procedure UNTIL some-
> condition" in that remote procedure might have been seen as necessary
> in a pre-1985-COBOL, but not today, where COBOL provides the
> statements to formulate proper repetitions.
>
> I would instead recommend to do away with any "PERFORM some-
> procedure UNTIL some-condition" and replace it with either a call of
> that procedure by a simple PERFORM within a local loop (i.e. some
> "PERFORM imperative-statement END-PERFORM", or to organize that remote
> procedure as a loop. I think it is important to see how the
> terminating condition for the loop is coming into being right where
> the repetition and its terminating condition is being formulated, and
> not seperate the two by what may be pages or screenfuls of other
> statements.

Now you're talking about invalidating existing code. If you want PERFORM
<some-procedure> UNTIL <some-condition>" to be No Longer Valid COBOL, I
would ask whether you are personally willing and able to indemnify all
current users that they will incur no costs whatever when compilers no
longer support the constructs!

> There are three conditions which prompt to repeat a sequence of
> statements:
>
> 1. when one knows beforehand, how many repetitions are being done,
> e.g. when you know that the fairy queen offers three wishes, you will
> "PERFORM the wishing 3 TIMES";
>
> 2. when one knows that there is a finite number of occurences of a
> given object, then one formulates a termination condition like that
> there can no more objects be fetched for processing, and one will
> write in COBOL a "PERFORM UNTIL some-condition ... END-PERFORM".

Depending on what gets PERFORMed, it might be practical, appropriate, or
desirable to code what is PERFORMed in-line, or as one or more paragraphs,
or as one or more sections, and with THRU clauses which might or might not
consist of paragraphs consisting solely of EXIT. I don't believe it'd be
appropriate for the standard to reduce the number of such choices available
to the programmer.

> Both of the above can be accompanied by VARYING some counter.

Yes; I'm not sure why one would, though.

> 3. Only under condition that there is really an infinite number of
> events which have to be processed, like the queues in the operating
> system of a computer, or the cars arriving at some toll station, or
> any other steam of conceptually non-terminating stream of events would
> it be proper to write something like "PERFORM FOREVER some-action END-
> PEFORM", and then the "FOREVER" would really a best keyword to express
> this conceptually infinite stream.

It would, I agree. But I can't find it in the reserved word list in either
the current standard or in the working draft for 2008, and I am *always*
reluctant to introduce reserved words for such clauses unless *absolutely
necessary*. Are you willing to convince every programmer who has, or might
have, used FOREVER as a paragraph-name or section-name in a COBOL program
that the Needs of the Many far outweigh the Needs of the Few?

> ... The proper way is to organize a loop which begins with the valid
> assertion of an item being present, and ending with the attempt to
> fetch the next item, and to do a first attempt _outside_ and _before_
> that loop, which enables the program to determine very simply if the
> file contains any items at all.

There is not now, nor has there ever been, any conceptual linkage in
standard COBOL between what goes on within the PERFORM range and what
happens in the UNTIL clause. That includes file I/O, AT END, INVALID KEY,
or completely arbitrary terminating conditions like HELL-FREEZES-OVER,
PIGS-FLY or THE-COWS-COME-HOME.

In fact, I'd argue that the appropriate place to SET such conditionals for
use in the UNTIL clause is *within* the PERFORMed code, in which case I
think EXIT PERFORM is clearer, whether the perform range is inline or not.

    -Chuck Stevens

Relevant Pages

  • Re: Infinite Loops and Explicit Exits
    ... CS> One of these proposals relaxes the current restriction that an EXIT ... discussed unter "Report enhancements" and then "Perform loop ... terminating condition is visible in that context. ... One would have a statement which calls a remote procedure in a ...
    (comp.lang.cobol)
  • Re: Houston-related rants was Re: forced merges/inside lane merges/AASHTO "tapered merges"
    ... >> Are you sure about the North Loop and I-45? ... >> in particular the westbound exit for Fondren/Gessner. ... How could HCTRA put an exit ramp for eastbound ... and the West Houston Center Blvd exit still shows Old Westheimer ...
    (misc.transport.road)
  • Re: Exit Do
    ... I've been instructed by a dot net / asp programmer that Exit Do is ... I am using nested loops and need to exit out of one loop into ... Code Stage B ... likely to lead to bugs and readability problems. ...
    (microsoft.public.scripting.vbscript)
  • Re: Exit Do
    ... I've been instructed by a dot net / asp programmer that Exit Do is ... I am using nested loops and need to exit out of one loop into ... If Some Reason to stop loop then Exit Do ... Code Stage B ...
    (microsoft.public.scripting.vbscript)
  • Re: Infinite Loops and Explicit Exits
    ... CS> There are cases in which EXIT PERFORM is, I think, clearer than GO TO ... procedure-name-1 SECTION. ... repetition in the main loop statement is being overrun by some minor ... particularly when the requirements of elegance ...
    (comp.lang.cobol)