Yes, I with the "exited" I was forgetting that the compiler will excise code you can never get into, but is unable to know about code that theoretically (or even practically) you may/can never be able to get out of :-)
If you think a PERFORM is a GO TO, I think you've missed the point.
THE-LOOP.
perform until exited
display 'Enter command:' upon console
accept command from console
evaluate function lower-case(command)
when 'add'
perform add-entry
when 'del'
perform delete-entry
when 'chg'
perform change-entry
when 'end'
display 'exiting with no command performed'
upon console
move 4 to rc
GO TO LOOP-END
when other *> invalid command
display 'invalid command!' upon console
display space upon console
GO TO THE-LOOP
end-evaluate
display 'command complete' upon console
GO TO LOOP-END
end-perform
LOOP-END.
The "exit something" allows that code to work in a single paragraph, without having to create labels. The compile knows where ot "GO TO", but *does the reader always know* (which is more important than the compiler knowing, it always knows, accurately,it is just that there can be conflict with what the user, in error, expects).
However, there is no need for you to have used the initial PERFORM, you could have in-lined it yourself, then all the GO TOs work with no further changes.
For your PERFORM, there is never a "normal" cycle. If execution reaches the end of the block, the PERFORM is exited. There is only another iteration if the "current cycle" is interrupted.
I think this construct better represents what you have:
PERFORM
ACCEPT W-INPUT
IF NOT W-PROCESS-INPUT
CONTINUE
* EXIT PERFORM CYCLE
END-IF
PERFORM PROCESS-INPUT
END-PERFORM
(CONTINUE because I don't have access to V5.2 :-) ).
Of course, those are deficiencies of an artificial example.
What if someone adds a SECTION after your existing code, and uses EXIT SECTION to get to it? Or uses EXIT SECTION without adding a SECTION?
some-label.
do some stuff
do something else
do a third type of thing
At a site where the use of GO TO is "forbidden", someone who needs to avoid "do something else" does this:
some-label.
do some stuff
if some-condition
exit paragraph
end-if
do something else
some-other-label.
do a third type of thing
Someone later picks up the code, notices that "some-other-label" is not referenced (I'm assuming here that it is not noted as referenced in the compile listing simply due to the "exit paragraph") and removes it. The code still compiles, although the "some-other-lable" was absolutely 100% vital to the program "working".
We've noted the use of "exit paragraph" in a PERFORM ... THRU ... before. Sites that mandate the use of an "exit paragraph" (needing the THRU) and who don't forbid the use of more than two paragraphs in that range, are asking for trouble.
I apologise for assuming you wouldn't just fly directly out of an EVALUATE via "exit perform" or even "exit paragraph/section" :-)
Would you do that prior to V5.2 with GO TO? If not, why would you do that just because the GO TO is disguised?
Now, simply being able to use GO TO doesn't of itself lead to spaghetti code. It was the *way* that people, in practice, used GO TO. "exit something" is just a GO TO, without a label. There is nothing intrinsic which prevents its "abuse" ("well, if I just use an 'exit paragraph' here I don't have to even consider if the code could be restructured to make the program easier to understand now that it is doing something different").
A more subtle spaghetti, perhaps, but is that good?
Highlighting what would be "good practice" in using these "exit somethings", and what would be "bad practice", would perhaps help to favour the first over the second. But, you know when we get down to that in COBOL it is always difficult to get agreement on what is what.
By choice I don't use "GO TO". I therefore have no need of a disguised GO TO to make my programs "clearer". I have no "best practice" use for it.
So the people who do use GO TO have to set out the "best practice" for it. Leaving the people who don't think GO TO is good practice... if a GO TO is needed, then, for me, it is best as a GO TO. At least if someone removes the target label it won't compile. If someone is considering adding code/label in the vicinity, at least they can readily see what is affected.
So, for me, exit perform/exit perform cycle/exit paragraph/exit section are bad practice. If you find yourself "having" to use one, use a GO TO.
OK, exit perform cycle may be considered differently (in a more realistic example, a label prior to an in-line PERFORM isn't going to cut it). But I code happily without feeling the need of it, so why would that suddenly change because it is available? For example, would you encourage a multi-page in-line PERFORM with several "exit perform cycle"s in it?
I think if you can set out some "best practice for use of exit something" theory, so that it can be applied to general practical examples, the discussion becomes more useful. That will certainly be better than just letting its use develop "organically".
We may have to come up with a snappier name (there are other "exits" which is entirely separate from this particular discussion as well).
BillWoodger