Re: Infinite Loops and Explicit Exits

"Rick Smith" <ricksmith@mfi.net> wrote

> Standard COBOL provides no means, similar to
> EXIT PARAGRAPH and EXIT SECTION, to
> "short cycle" PERFORM ... THRU without using
> a GO TO statement. EXIT PERFORM CYCLE
> eliminates those GO TO statements.

There are other ways to eliminate the GO TOs.

> some-process.
>     ....
>     PERFORM some-other-process
>     IF exception-variable NOT = ZERO
>         EXIT PERFORM
>     END-IF
>     ...

So what is wrong with:

>     PERFORM some-other-process
>     IF exception-variable NOT = ZERO
CONTINUE
ELSE
..
>     END-IF

"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0410302009.c1781e9@posting.google.com...
> "Rick Smith" <ricksmith@mfi.net> wrote
> 
>
> There are other ways to eliminate the GO TOs.

Not with multiple paragraphs or sections in PERFORM ...
THRU.
 
>
> So what is wrong with:
> 
>           CONTINUE
>       ELSE
>           ... 

It won't work in all but the last paragraph of a
PERFORM ... THRU  or PERFORM section and will
not cause the PERFORM to terminate without a
test for the same condition.
 
>
> Possibly, but as I have never felt the need for any of them, or GO TO,
> then equally needful is about right.

On Tue, 2 Nov 2004 12:13:22 -0800, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
> news:r88do0hgoqarvib383eb5mr9i6dciheatv@
4ax.com... 
>In a 
>GO 
>
>Only partly true.  GO TO <perform-range-exit> is equivalent to EXIT PERFORM
>CYCLE only if <perform-range-exit> is a paragraph that contains only the
>EXIT statement (not a requirement), and EXIT PERFORM CYCLE is equivalent to
>EXIT PARAGRAPH only if both occur in the last or only paragraph in the
>PERFORM range.

In practice, both are true. Programmers don't perform a thru c, they
perform a thru a-exit.

The significant change is that EXIT PERFORM not only exits but also
stops iteration. There is no equivalent Cobol function to do that
under 2002.
 
>
>Yes, but again, that only works if <perform-range-exit> is a paragraph
>containing only EXIT.  I was thinking of the PERFORM FOREVER case, in which
>event I think they're pretty much equivalent.

PERFORM FOREVER doesn't exist yet, and do-it-yourself methods are
uncommon. Again, the common case is PERFORM A THRU A-EXIT UNTIL
<an-indicator-is-set>. EXIT PERFORM CYCLE would replace A-EXIT and
THRU A-EXIT. EXIT PERFORM would additionally replace the indicator.

There is no need for THRU A-EXIT *now*, and the terminating condition
belongs on UNTIL rather than embedded in the procedure. But there are
some who need an 'excuse' to change their obsolete style.

>The defense of an existing '70's shop standard so stating is that it exists
>and that most likely the owners of a company have spent a fair amount of
>money in programs that conform to it.  Because there may be no particular
>technical necessity for a construct in a given context does not mean it is
>valueless to those whose programs contain it.  "Because I'm used to it bein
g
>there" is not such a terrible thing!

It is terrible when it prompts outsiders to call Cobol a dinosaur and
abandon it for 'more modern' languages.

>Yes, I am well aware of the Holy Wars as to whether a GO TO to the single
>EXIT point of the paragraph you're in was a violation of Proper Structured
>Programming rules.

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.

"Rick Smith" <ricksmith@mfi.net> wrote
 

> To say "perform single paragraphs only"

And here is where I used this particular set of words:

"""The particular set of rules that I use are (there are exceptions of
course):

Only PERFORM single paragraphs (NOT sections, no THRU)

Never Drop Through a label

GO TOs are only used to the top of the current paragraph
(continue) or out to a common abandon-program
"""

You misrepresent my words as somehow insisting that others do this
when it quite clearly states that it is what _I_ do.

> and "GO TO is not needed" is to be firm.

I did find where I had said that, but you have taken it completely out
of the specific code sample context that it was used in, deliberately
probably:

"""GO TO is not needed to 'jump over the mess',"""

> To say the same unwaveringly is to be
> resolute. To say the same repetitively is to be emphatic.

And to take these and misrepresent them is disengenuous.

You appear to completely ignore that most of my discussion was
conditional:

"If it is your intent to eliminate the GO TOs then .."

You may also have seen while you were scanning my messages:

"""In my view there is actually nothing wrong with GO TOs.  They are
very clear in their intent and easy to follow."""

"""There is actually nothing wrong with a GO TO statement.  It is
perfectly
what its action is and, where the GO TO occurs, there is no confusion
over the logic flow."""

"""In fact there is nothing wrong with a GO TO at all.  It is a very
clear
statement that is unambiguous and always does what is required."""

> Mr Plinston, you may not see anyone "insisting;" but I have
> seen you "insisting" for years and, a quick search of Google
> groups, confirms at least ten years of being emphatic, firm,
> and resolute on the matters of single paragraph perform and
> GO TO.

Now find somewhere where this wasn't clearly stated as: what _I_ do,
or my opinion, or one option among others, or conditional

In other words find where I actually 'insist' on some one doing it
just one way.

> Mr Plinston, I said "implying ... archaic, the first step toward
> elimination."

Given that it was Chuck that brought up 'archaic', perhaps you could
indicate where exactly you found me saying this.

> To say "perform single paragraphs only" is to imply that THRU
> is not needed.

It certainly isn't needed in my code.  Now, did that tell that you
shouldn't use it ?

> To say "GO TO is not needed" is to say so directly.

and yet more recently you stated:

RS>>> EXIT PERFORM CYCLE eliminates those GO TO statements.


> To say these things with the knowledge that THRU
> and GO TO have been part of the language since the
> beginning is to imply "no longer needed" and, therefore, old or
> outmoded; thus anitquated and archaic.

Are you using "no longer needed" as a direct quote of something that I
actually said, or did you just make this up ?

For example I did use that phrase in:

"""and I found I no longer needed -Exit paragraphs"""

Which seems to be somewhat different than your invention.

> The sense of "imply" that I use is: to involve or require as a
> necessary condition.

So find an actual case where I _require_ something.

Robert Wagner <spamblocker-robert@wagner.net> wrote

> Consider the Hawks movies Rio Bravo and El Dorado. They had the same
> characters and story line. The second was truly a rewrite of the
> first.

A small number do get remade, ususlly the result is much worse than
the original.
 
>
> The black-and-white fallacy, again. Why not both?

Because 'both' cost twice as much as doing one. In any case, at most
sites there is likely to be a backlog of systems that are required to
be developed.  In most cases these new system are cost justified on
the basis that the result will be a cost saving overall.

Existing systems which already do their task reliably will not do it
any better if rewritten, in fact it may well introduce bugs.  There is
no cost savings to be had, so the rewrite is entirely unjustified
cost.

Given a particular staffing level they can be allocated to work that
will save money or work that will save nothing and may cause
additional cost and problems.

> I advocate rewrite as a by-product of required maintenance.

And what if there is no 'required maintenance'.  The system has been
stable, there are no additional functions required, it does the job.

> At the
> supermarket company I cited, nearly all programs were modified within
> a year.

Was that the system that you said was rewritten at 3 programs per
man/day or somesuch and didn't need anything other than regression
testing ?  Now they all get modified.

> If there had been programs, or better whole systems, that were
> untouched, I would have left them alone. Other places I managed had
> untouched systems.

Well, there yer go then.  Many sites have systems and programs that
aren't touched for years.

> I'd rather CALL action unconditionally and let it make the decision.
> That way, the 'business rules' are complete within a single program.

That would depend on what 'condition' is and whether it is part of the
'business rule' of the current code or of the code being called.

On  5-Nov-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:

> How do I abend under Unix?
> RW: Abends are mainframe culture. Under Unix, you log the error and
> keep running.

That implies that you don't have dependencies.

Xref: newsfeed-west.nntpserver.com comp.lang.cobol:100267

"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0411032201.329878f8@posting.google.com...
> "Chuck Stevens" <charles.stevens@unisys.com> wrote
> 
my 
>
> But some seemed to be  by what would be equivalent.
> 
of 
>
> I do hope you mean the last _active_ PERFORM.
>
>        PERFORM A
>        here
>        ...
>     A.
>         PERFORM B
>         EXIT PERFORM
>         ...
>         .
>
> The 'PERFORM B' is the 'last PERFORM executed', 'here' is where you want
to get to.

Yes; at this point I'm mostly worried about getting "agreement in principle"
on what it's supposed to do; I have no doubt the wording will be thoroughly
hashed over before it gets into the standard!  ;-)

The *current* such rule for EXIT PERFORM reads "The execution of an EXIT
PERFORM statement without the CYCLE phrase causes control to be passed to an
implicit CONTINUE statement following the END-PERFORM phrase that matches
the most closely preceding, and as yet unterminated, inline PERFORM
statement".  (ISO/IEC 1989:2002 Page 449, 14.8.13.3, EXIT statement, general
rule 9).

Perhaps "... control is passed to an implicit CONTINUE statement following
the most recently executed, and as yet unterminated, out-of-line PERFORM
statement."?

Simply changing "last PERFORM" to "last such PERFORM" might also work; the
EXIT PERFORM does not appear, to me, to be in the perform range of PERFORM
B.

But again, *at this stage* what I'm more concerned about is whether or not
the basic idea would be accepted by J4 (and WG4), not whether we've got all
the serifs right in the rules.  If the whole idea gets shot down, all the
energy and time spent worrying about whether I covered all the cases or not
in the early drafts of the rules is wasted, and I have some rather weightier
issues to consider!

-Chuck Stevens

Robert Wagner <spamblocker-robert@wagner.net> wrote

> A before-and-after test with full production volume will insure new
> code is doing the same as old.

It will only 'insure' that for the particular items that are in that
test. There will be many things that a 'full production volume' may
not test.  Many times I have looked at a 'full production volume' and
seen that the actual data is only a subset of all possible data types
and would fail to excersize all the program.

In any case each individual program will still need testing before
reaching the point that it can be system tested.

"Howard Brazee" <howard@brazee.net> wrote in message
news:cme29k$prg$1@peabody.colorado.edu...
>
> On  4-Nov-2004, "Rick Smith" <ricksmith@mfi.net> wrote:
> 
that 
>
> One can recommend without insisting.   One can discuss techniques without
> insisting.

When a comment is specific to a problem, I would suggest
it is a recommendation without insisting. When the comment
does not address the problem, I see it as insisting on something.
For example, a poster provides code to print a report; the code
is written using sections; and the problem is with control breaks.
A recommendation solving the problem does not insist; a
recommendation to use Report Writer does insist; and a
recommendation to use paragraphs, not sections, also insists.

>   I don't believe the world consists only of dictators and sheep, nor
> should it.   I infer that you believe differently.

I think dictators and sheep might have that opinion. I don't.
 
>
> No, I cannot.

Well, I can't argue with that. But if your use of "lead" is not
in the sense of current practice, then different implications
arise.

> 
>
> However to say "I program this way", or even "I find this way of
programming to
> be desirable", does not imply "I want other ways of programming to be
> proscribed" - even if that is what you infer.

Mr Brazee, those statements are ambiguous. I can't tell if, by
"this way," you mean standing on your head, standing on your
feet, sitting in a chair, sitting on the floor, or something else.
To imply, in the sense used, requires a clear statement from
which to draw the necessary consequences or conditions.
The implications arise with the specifics of "this way" and
"this way of programming to be desirable."

Having said that, my dictionary provides a definition of
"desirable" as "advisable; recommendable." It is not a big
leap to conclude that the inadvisable and practice not
recommended is to be proscribed; but it does depend on the
specifics.

"Howard Brazee" <howard@brazee.net> wrote in message
news:cmdjf2$gmi$1@peabody.colorado.edu...
>
> On  3-Nov-2004, "Rick Smith" <ricksmith@mfi.net> wrote:
> 
>
> They make huge differences.

Not with the repetition shown.

Consider the qualification "in this case." This seems to limit
the consequences of the statement, but when repeated with
different cases (posters), it approaches "in no case." There
is a point at which the qualification must be discarded.
 
>
> I agree that it doesn't take much of an observer to observe things that
aren't
> said.   What Mr. Plinston does and what I like are in no way insisting
that
> others follow our lead.

Mr Brazee, by saying that you have a "lead" that may be
followed, and to express repeatedly the concept that makes
it "lead[ing]," is to insist that others "follow [y]our lead;" else
why say it?

Can you not see that, by using "lead," you are implying that
what others do, different from that "lead," is outmoded, thus
archaic?

> 
>
> And I have repeatedly disagreed with your point.   Not only is it based
upon a
> false assumption, the conclusion does not follow.   The whole argument is
> entirely in your head.   Your inferences are completely unrelated to what
I
> actually said.
>
> There's a big difference between what you infer and what I imply.

There are different senses for the definition of "imply." Either of
these fits the use I relied on.
( www.m-w.com )
2 : to involve or indicate by inference, association, or necessary
consequence rather than by direct statement <rights imply
obligations>
( "The Random House College Dictionary" )
2. to involve or require as a necessary condition.

These are not related to intent of the speaker. For one to say
"At 6 PM, I was stuck in a snow drift outside Chicago." implies
"I was not on a beach at Maui when it was 6 PM in Chicago."
[It seems likely that the importance of this particular implication
would require more information.]