Recently, Frank Swarbrick and I have been discussing this down at the COBOL
Cafe (how cool does that sound when you say it out loud?).
The nub of the topic is the new Formats of the EXIT statement which have been
introduced to Enterprise COBOL with V5.2. These are EXIT PERFORM, EXIT PERFORM
CYCLE, EXIT PARAGRAPH and EXIT SECTION. These were introduced to the COBOL
Standard in 2002, now superseded by COBOL 2014.
On discovering these a few years ago, my first question was "why even more
overloading of EXIT?". EXIT, the original and without qualification, is a NOP.
All the other Formats of EXIT "do things". Answer from someone in the know was
"so we don't break existing code by picking a new word". To me that is a slack
reason, as we were always told "never use a single word for a name, because one
day they may want to use it for the compiler". If the unthinking had been
bitten, I don't really care. OK, some big companies may... can't fight City
Hall.
That aside, what do these new Formats of EXIT do?
In reverse order:
EXIT SECTION, if executed, branches to an implied CONTINUE (also a NOP) after
the code generated for the last source statement (which generates code) in the
SECTION. You don't have to be PERFORMing the SECTION at the time of execution.
EXIT PARAGRAPH, if executed, branches to an implied CONTINUE after the code
generated for the last source statement (which generates code) in the
paragraph. You don't have to be PERFORMing the paragraph at the time of
execution.
EXIT PERFORM CYCLE, branches to a the point (could be another implied CONTINUE,
but, seriously, since it is a NOP, there is no code (not even an Assembler NOP)
in an inline PERFORM which starts the next iteration.
EXIT PERFORM, branches to after the inline PERFORM (got tired of even pasting).
My concerns are: they are secret GO TOs - NEXT SENTENCE is bad enough, do we
need more?; they are not intuitive - EXIT PERFORM and its cousin clearly
operate within a PERFORM (although not so clear that it is only within an
inline PERFORM), EXIT PARAGRAPH and EXIT SECTION don't care whether or not a
PERFORM is active, they're just going to GO TO where they want, which isn't
always clear (no label); because they seem a bit "structured" someone can use
them for "spaghetti" and still claim to be writing "structured code, I never
use GO TO".
An example:
PERFORM A THRU C
A.
...
IF some-condition
EXIT PARAGRAPH
END-IF
...
B.
...
C.
EXIT *> old-style, NOP
Where does the EXIT PARAGRAPH "go to"? A point immediately before B. Is that
the desired and intended result? What happens if you want to insert another
paragraph between A and B (I wasn't very foresightful with my naming)?
An EXIT SECTION seems less problematic, but bear in mind that nothing stops you
having EXIT PARAGRAPH in a SECTION (perhaps Frank can confirm if it works even
without a paragraph name in the SECTION?). And whether the SECTION is
fallen-into, or GO TO'd, or PERFORMed, EXIT SECTION does the same thing,
perhaps not what people imagine. Same with EXIT PARAGRAPH, if you just pretend
I mentioned it back there.
On the one hand the above is "good", as it finally indicates that PERFORM ...
THRU ... is for the birds. At least with the PERFORM of a single paragraph,
there is no confusion about where EXIT PARAGRAPH "go tos".
On the other hand, all existing GO TOs in a program could be eliminated by
adding using EXIT PARAGRAPH, if the GO TO is going "downwards" and not going
more than one paragraph away. The program is still as "bad" as before, but now
has nice shiny instructions to be equally bad with.
I don't use GO TOs, unless the client insists, and unless they are needed for
extreme performance (with severe reduction in program-legibility), which
fortunately is not often needed.
I don't have a problem with people using GO TOs in sensible ways, which very
many experienced programmers do.
I do have a problem with the introduction of an ill-defined secret GO TO
disguised as a "structured" thing which I fear will be abused (as in used
incorrectly) if for no other reason than a lack of knowledge of what it does,
let alone the "one more hack and the program'll be working" school of
classroom-/self-taught programming.
I think we can wait for Frank to contribute a piece and then... Discuss...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
