Re: Infinite Loops and Explicit Exits

From: Robert Wagner (spamblocker-robert_at_wagner.net)
Date: 11/04/04 

Date: Thu, 04 Nov 2004 01:23:59 GMT

On Wed, 3 Nov 2004 08:12:27 -0800, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
>news:qr6go0tqvutkqbtuji7q0919s8j22plnl2@4ax.com...

>> PERFORM FOREVER doesn't exist yet, and do-it-yourself methods are
>> uncommon.
>
>The methods are neither common nor uncommon. What is relevant is whether
>they exist today or not, and whether they are straightforward or not, and I
>believe the answer to both of those is "yes". Now, if what you meant by
>"uncommon" was "not commonly used", that's a matter of personal style and of
>your exposure to it. I suspect the most straightforward method -- an
>88-level item referencing an invariant filler -- isn't that common precisely
>because many practicing programmers seem to avoid 88-level items to begin
>with (despite the continued enhancement to the feature in the various
>standards).

I haven't noticed avoidance of 88s.

Use of PERFORM .. FOREVER is uncommon because the standard doesn't
provide a mechanism to stop iterations in an out-of-line perform.

>> There is no need for THRU A-EXIT *now*,
>
>Depends on whether The Person Paying Your Salary wants it there -- or wants
>it to stay there, even if it's for the simple reason that he wants it there
>and he wants it to stay there.

Wants and Pays do not speak with a single voice.

The Person Paying My Salary is an executive who knows nothing about
programming style. If asked, he'd champion the style with lowest
maintenance cost and highest reliability, without regard for shop
traditions.

The person enforcing shop standards is a supervisor whose motivation
is job security, not money.

>> and the terminating condition
>> belongs on UNTIL rather than embedded in the procedure.
>
>So the Dijkstra-inspired "DO FOREVER ... IF <condition> THEN UNDO ...END" is
>completely wrong-headed?

It's unfamiliar to Cobol programmers because the equivalent to UNDO --
EXIT PERFORM -- can only be used with in-line PERFORM. We want the
option to convert in-line to out-of-line when it becomes unwieldy. We
avoid EXIT PERFORM because it removes that option.

>So the appropriate response of a successful and profitable business, when
>some outsider says "your programming standards are hopelessly unfashionable"
>is "yessir, yessir, whatever you say sir. How many years of unprofitability
>are we going to have to go through to rectify this heinous crime?" ???

A straw man argument. You haven't shown there would be years of
unprofitability. I cited one case where savings were realized the
first year. I could have cited at least four others.

>> A properly structured program has no need for premature exits (except
>> to abort). The audience for EXIT PERFORM is programmers who don't know
>> how to do structured programming. For them, EXIT PERFORM is an
>> improvement over PERFORM A THRU A-EXIT.
>
>Again, Mr. Wagner: we just received a trouble report from a large customer
>that turns out to have been a problem with the ALTER verb. The bug was
>preventing this customer from upgrading to new system software because the
>program, which has clearly (from internal evidence) been performing to the
>customer's satisfaction for something on the order of twenty years or more,
>no longer works correctly.

I say EXIT PERFORM would be an improvement for unstructured programs;
your response talks about seriously unstructured code still in
production. How does the response disprove the assertion? It sounds
like an example supporting the assertion. If the customer upgrades to
2002, it will have to rewrite ALTER one way or another. EXIT PERFORM
might well be the least intrusive translation.

>It is not the business of the *standards* committee to decide whether a
>program is "properly structured" or not. Nor is it the business of the
>*compiler vendor* to decide that. It is the *customer's* job to decide
>that -- or to care, or not to care.

I agree that quality is not the concern of the standards committee nor
compiler vendor, but it is a valid concern of this forum. Posters here
can legitimately criticize ALTER, GO TO and PERFORM THRU. Readers who
care about quality might learn to program better. Reactionaries will
continue writing bad code.

Relevant Pages

  • Re: EXIT SECTION/PARAGRAPH
    ... one section for the body of the procedure division, ... that section as required by 2002, EXIT statement ... This will, in effect, transfer control to the ... Old School Cobol programmers have an almost genetic belief that the last ...
    (comp.lang.cobol)
  • Re: EXIT PERFORM Help, please [LONG response]
    ... > JJG> of verbiage! ... > which you presented as an example of how to use EXIT PERFORM. ... > not a matter of personal style, ... that programmers generally are sensitive to what they write. ...
    (comp.lang.cobol)
  • Re: Looking for a way to convert dec to bin
    ... Don't you know, Rick, 1337 programmers don't USE comments! ... POSSIBLE ways to avoid Exit For, which was originally deemed impossible to ... expect to see all termination conditions in the loop clause somewhere (at ...
    (microsoft.public.vb.general.discussion)
  • Re: [VB5) Faster way to read a text file?
    ... a proponent of the Dijkstra model (though I make exceptions for raising ... error conditions with "proper" use of On Error and/or Error.Raise in VB). ... Most programmers these days have moved on to the second methodology ... things like Exit For/Exit Do ...
    (microsoft.public.vb.general.discussion)
  • Re: No Cursors Please
    ... How do you know that he cannot alter the schema? ... All programmers had full ADMIN privileges. ... Oh, surprise, surprise, surprise the data was dirty -- items ... We then began working on the queries. ...
    (microsoft.public.sqlserver.programming)