I'm also going to post this in the IBM COBOL Cafe, but I'm not sure how many
people actually use that site...
So as you might know, I'm interested/excited about the new "EXIT" statements in
Enterprise COBOL. I just had a thought on a good use of EXIT SECTION.
We too often run in to issues where a developer will add a new paragraph for a
new process, and they will add it so that positionally it becomes part of a
SECTION within the procedure division, and this it is unintentionally performed
as the result of a PERFORM of that section.
For example, take this following simple code:
procedure division.
main section.
mainline.
perform one
perform two
goback.
one section.
[...do something...]
two section.
[...do something else...]
Let's say that a new developer wants to add a third process. They add the
following to the end of the program:
three.
[...do a third thing...]
They then add "perform three" after "perform two" in the "mainline" paragraph.
So what happens? The code within paragraph "three" gets executed twice; the
first time as part of "perform two", because "three" is part of the section
named "two", and then again as a result of the new "perform three".
Now in this example it would probably become obvious during testing that this
is occurring, so hopefully (!!) it would not make it to production. But some
times the "perform two" may only occur in certain edge cases, and so the
unintentional execution of "three" might not occur during the testing phases.
So many will agree that procedure division sections are a bad idea. Well
that's a fine opinion, and one I can get behind. But the fact is, they exist
in many programs, and to often they have this sort of bug. So what to do?
I had a thought that using an explicit "EXIT SECTION" to the end of all
procedure division sections would be a good first start. In the above example
there could be a "one-exit" paragraph at the end of "one section" that contains
just the "exit section" statement. And a "two-exit" paragraph at the end of
"two section" that did the same.
By doing this you have a "defense" against someone doing what happened here.
Now even if "three" is unintentionally made part of "two section" we will no
longer "drop through" to it. The EXIT SECTION (unlike the fairly useless
legacy EXIT statement, which is a NO-OP) will cause the flow to branch around
"three" (and anything following "three") to the "true" end of the section.
Of course there is nothing to enforce this standard. But perhaps there could
be! I'm thinking of an RFE to add a compiler option that would require all
sections to be terminated by a paragraph consisting of only the EXIT SECTION
statement. Could that catch all of these types of bugs? I'm thinking it
could. Take the example above, with this new rule in force:
procedure division.
main section.
mainline.
perform one
perform two
goback.
exit-mainline.
exit section.
one section.
[...do something...]
exit-one.
exit section.
two section.
[...do something else...]
exit-two.
exit section.
Now if someone adds something after exit-two it will violate the rule and give
a warning, or even an error. The developer would fix it by adding "three
section" instead of "three", as well as its own "exit-section" paragraph with
the "exit section" statement.
Obviously pretty much every existing COBOL program that uses procedure division
sections would violate the rule. But perhaps there could be a simple
"migration tool" that could update source code to conform to the rule. A more
advanced migration tool might even look for existing "exit-section" paragraphs
with just the "EXIT", which is truly how statement procedure division sections
currently should be "terminated", and if there is not a SECTION (or end of
source) following it, report an error. This assumes all sections are
terminated this way, which I'm sure is not the case, but it still seems
worthwhile.
Make any sense? I'm sure Bill W will have something to say about it!
Frank
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
