GoTo in Java

It is interesting that Java, where the word GOTO is reserved but not
used, it has a label and a GoTo equivalent to tell us how to exit a
multi-layer iteration (perform loop).

I wish we had an equivalent in CoBOL.

Howard Brazee wrote:
>
> It is interesting that Java, where the word GOTO is reserved but not
> used, it has a label and a GoTo equivalent to tell us how to exit a
> multi-layer iteration (perform loop).
>
> I wish we had an equivalent in CoBOL.

We do, dammit (if I undersrand what you're saying).  GOTO, GOTO
equivalent - what's the point?  GOTO works, does just what an equivalent
would do.  Stop being stubborn.

(Cancel this if you're trolling).

In the '02 Standard and some current implementations (but alas NOT IBM's).

Exit PERFORM (cycle)

--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message
 news:dnnqs1tjutcc64coojpi0k06g2jrlopf38@
4ax.com...
> It is interesting that Java, where the word GOTO is reserved but not
> used, it has a label and a GoTo equivalent to tell us how to exit a
> multi-layer iteration (perform loop).
>
> I wish we had an equivalent in CoBOL.
>
>

I think what he was looking for was exit from PERFORMs of any level,
analogous to Burroughs B1000 SDL/UPL (and almost certainly
Dijkstra-inspired)
..
DO <label-1> FOREVER;
DO <label-2> FOREVER;
DO <label-3 FOREVER;
..
IF <condition-1> THEN UNDO; % transfers control to just after
END <label-3>
IF <condition-2> THEN UNDO <label-2>; % control to after END
<label-2>
IF <condition-3> THEN UNDO *; % control to outermost DO within
procedure
END <label-3>;
END <label-2>;
END <label-1>;

You can certainly EXIT the "innermost" PERFORM in COBOL, but there's no
provision to EXIT, say, the fifth nested PERFORM level above you in the
hierarchy.

-Chuck Stevens

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:yBfzf.123644$Es3.36473@fe03.news.easynews.com...
> In the '02 Standard and some current implementations (but alas NOT IBM's).
>
> Exit PERFORM (cycle)
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Howard Brazee" <howard@brazee.net> wrote in message
>  news:dnnqs1tjutcc64coojpi0k06g2jrlopf38@
4ax.com... 
>
>

On Tue, 17 Jan 2006 17:53:34 -0600, Peter Lacey <lacey@mts.net> wrote:
 
>
>We do, dammit (if I undersrand what you're saying).  GOTO, GOTO
>equivalent - what's the point?  GOTO works, does just what an equivalent
>would do.  Stop being stubborn.
>
>(Cancel this if you're trolling).

There are two ways to have internal loops:

PERFORM VARYING.....
PERFORM VARYING....
IF I-AM-FINISHED
EXIT PERFORM
END-IF
END-PERFORM
END-PERFORM

I am not sure, but I think the EXIT PERFORM will have the ability to
pick which level is being exited from.    At any rate, I can't do this
now.


Let's say I want to go the GOTO route as you say.   I can't use the
existing code, but would need to rewrite the logic.
IF FOUND-SUBCODE
PERFORM SUBCODE-ROUTINE
PERFORM WRITE-RESULTS
END-IF
..
SUBCODE-ROUTINE.
..
IF FINISHED-SUBCODE
PERFORM CHECK-INVENTORY
PERFORM ADD-TO-BIN
END-IF.
...
CHECK-INVENTORY.
..
IF NEED-TO-EXIT
GO TO ??????
END-IF.
...

Let's say I want to go to PERFORM WRITE-RESULTS  at this case.    I
need to set up switches or rewrite the logic (which is frowned at with
working code).

Chuck Stevens wrote:

> I think what he was looking for was exit from PERFORMs of any level,
> analogous to Burroughs B1000 SDL/UPL (and almost certainly
> Dijkstra-inspired)
>     ...
>     DO <label-1> FOREVER;
>         DO <label-2> FOREVER;
>             DO <label-3 FOREVER;
>             ...
>             IF <condition-1> THEN UNDO; % transfers control to just after
> END <label-3>
>             IF <condition-2> THEN UNDO <label-2>; % control to after END
> <label-2>
>             IF <condition-3> THEN UNDO *; % control to outermost DO within
> procedure
>             END <label-3>;
>         END <label-2>;
>     END <label-1>;
>
> You can certainly EXIT the "innermost" PERFORM in COBOL, but there's no
> provision to EXIT, say, the fifth nested PERFORM level above you in the
> hierarchy.
>
>     -Chuck Stevens
>
>  "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:yBfzf.123644$Es3.36473@fe03.news.easynews.com... 

IMO this would be like ALTER---a facility that if used would lead to
unreadable spaghetti code.  I prefer to do PERFORMs out of line and provide
each with an exit mechanism by setting/unsetting a switch. See Murach, Noll
et al. for examples. It is not difficult to set several switches at once to
bounce up several levels e.g.,
IF (condition)
MOVE "Y" TO LEVEL-5-SWITCH LEVEL4-SWITCH LEVEL-3-SWITCH
ELSE
(rest of performed subroutine).
But I question the soundness of such logic.

Be careful what you ask for.
--
John Culleton
Able Indexers and Typesetters

Could be a possible solution for you?

Cheers,
Tibi

CODE-ROUTINE.
IF FOUND-SUBCODE
PERFORM SUBCODE-ROUTINE THRU EX-SUBCODE-ROUTINE
PERFORM WRITE-RESULTS THRU EX-WRITE-RESULTS
END-IF
EX-CODE-ROUTINE.
EXIT.
..
SUBCODE-ROUTINE.
..
IF FINISHED-SUBCODE
PERFORM CHECK-INVENTORY THRU EX-CHECK-INVENTORY
PERFORM ADD-TO-BIN
END-IF.
EX-SUBCODE-ROUTINE.
EXIT.
...
CHECK-INVENTORY.
..
IF NEED-TO-EXIT
GO TO EX-CHECK-INVENTORY
END-IF.
...
EX-CHECK-INVENTORY.
EXIT.

On 18 Jan 2006 08:31:11 -0800, "Tiberiu Gociu"
<tiberiu.gociu@gmail.com> wrote:

>Could be a possible solution for you?

The use of exit paragraphs (which I thought I was through with) is a
partial solution.  To pick the correct level of exits, I would need
switches.

A better solution would be a labeled EXIT PERFORM statement.

Top post; no more below.

As to the issue of "spaghetti" code resulting from PERFORM exits other than
from the most immediate one, I'd have to agree; I wasn't arguing for such a
mechanism in COBOL, only pointing out that there are languages that have
them.

Note that the *only* "loop control" mechanism available in Burroughs B1000
SDL/UPL were the procedure call and the DO FOREVER / UNDO / END mechanism.
There was no GO TO in the language at all.  In that environment, "spaghetti
code" is a non-issue.

-Chuck Stevens


"John Culleton" <john@wexfordpress.com> wrote in message
news:6qqdncqi749t-VPenZ2dnUVZ_tadnZ2d@adelphia.com...
> Chuck Stevens wrote:
> 
>
> IMO this would be like ALTER---a facility that if used would lead to
> unreadable spaghetti code.  I prefer to do PERFORMs out of line and
> provide
> each with an exit mechanism by setting/unsetting a switch. See Murach,
> Noll
> et al. for examples. It is not difficult to set several switches at once
> to
> bounce up several levels e.g.,
> IF (condition)
> MOVE "Y" TO LEVEL-5-SWITCH LEVEL4-SWITCH LEVEL-3-SWITCH
> ELSE
> (rest of performed subroutine).
> But I question the soundness of such logic.
>
> Be careful what you ask for.
> --
> John Culleton
> Able Indexers and Typesetters

"Howard Brazee" <howard@brazee.net> wrote in message
 news:p0sss1p31ovm46qj1mkt43erl1etal90jk@
4ax.com...
>
> The use of exit paragraphs (which I thought I was through with) is a
> partial solution.  To pick the correct level of exits, I would need
> switches.
>
> A better solution would be a labeled EXIT PERFORM statement.

First off, EXIT PERFORM is usable only with an "inline" PERFORM.  J4
discussed the idea of extending it to out-of-line PERFORMs in the 2008 draft
and rejected the idea as too risky amd too much like GO TO.

But let's presume the standard did allow an EXIT PERFORM outside the context
of PERFORM ... END-PERFORM (our COBOL74 compiler, lacking inline PERFORMs,
has exactly this capability).

Because PERFORM ... THRU is still valid COBOL, the syntax for a "labelled
EXIT PERFORM" would have to allow the specification of both the start and
the end of the PERFORM range.  That's starting to look really clumsy.  And
beyond that, implementors would need to provide a mechanism to maintain some
encoded identification of both the start and end points of every active
PERFORM so that the specified range could be checked against EXIT PERFORMs
encountered at execution time.

If a labelled EXIT PERFORM statement were executed, and the end-points
specified don't match any of the PERFORMs that are currently "active", what
is the appropriate result?   Other EXITs are treated as CONTINUE if they
appear "out of context", but that leads to a nightmarish risk of unexpected
results at execution time.

Personally, I think labelled EXIT PERFORM would raise more problems than it
would solve.  Even EXIT PERFORM <integer>, where <integer> is the number of
levels to "exit", might be easier to define and less prone to errors , but
I'd be *really* surprised if very many people on this forum thought that
would be a fundamental improvement to COBOL's syntax!

-Chuck Stevens