Re: COBOL ain't quite dead - yet !



"Howard Brazee" <howard@xxxxxxxxxx> wrote in message
news:747hg4965hgegcuojhe10um7ic1f5lnccg@xxxxxxxxxx
I have seen

PERFORM AAA THRU AAA-EXIT.

AAA SECTION.
AAA-PARAGRAPH.
...
AAA-EXIT.
EXIT.


I hate that, but apparently it works. When I maintain this,
sometimes I will replace the EXIT. with CONTINUE, when I add debugging
statements.

Back in the late 60s as we started to evolve into "best practices", having
tried all the various permutations of PERFORM.. PERFORM.. THRU... SECTIONs
and paragraphs, the place where I was working decided (by general consensus)
that SECTIONs would be used. They would be structured as you showed above,
except that they could contain multiple paragraphs, the last of which would
be an EXIT. It was permitted to code GO TO as long as the target was within
the SECTION, but not outside of it, and any premature exit from the SECTION
was via the last paragraph.

The rule was you must ONLY PERFORM a SECTION, NOT a paragraph. You rightly
picked up that mixing PERFORMS of paragraphs AND SECTIONs just leads to
chaos. (The primary purpose of any paragraphs other then the first and last
one in the section was to aid documentation; most of the time SECTIONS did
not contain paragraphs other then the first and last one. Most of the time
the last paragraph was never referenced, but it served to tie up everything
and was there should you ever need it. It costs you nothing... This is very
similar conceptually to PERFORMing a single paragraph, but the SECTIONing of
code simply documents specific functionality better than a paragraph. A
series of paragraphs is just a program. A series of SECTIONS delineates
specific functions more visibly, in my opinion.)

Some of us who were fond of PERFORM... THROUGH grumbled a bit and pointed
out that the "range" of a SECTION was not specifc and things could be added
to the wrong SECTION, or a SECTION PERFORMED from different places might
sometimes need the new paragraph and other times not need it; with PERFORM
....THRU you always knew exactly what was being performed. However, we all
agreed to give the new idea a try.

After a few weeks of implementing the new standard we all agreed it was
excellent. It is simple, and clear. It avoided spaghetti code in a time when
most COBOL sites were like Italian restaurants.

To this day I code COBOL In that way and I don't apologise for it. With OO
COBOL each SECTION often becomes a METHOD and gets invoked on SELF, rather
than PERFORMED. This has the advantage that you can pass parameters to it
and keep data within the code that uses it, rather than everything having to
be global like it is if you PERFORM it. For "internal" (private) methods
like this I don't mind sending them parameters, but I don't generally do
this for public methods which are visible to the outside world, because that
complicates the interface and has knock on effects on general maintenance. I
use Properties, GETters and SETters for these instead.

Many people object to SECTIONing COBOL, seeing it as a relic from the days
of overlaying and segmentation. I don't. Certainly, I used it for
segmentation on different platforms and found it very useful, but I was
always keenly aware that the SECTIONing was not about overlaying, it was
about functionality.

In 35 years, since I adopted this approach, I have NEVER had a program go
out of control, and that applies on platforms where PERFORM is implemented
by returning on a modified address in memory, on a specific register, or on
a stack based architecure where the return address is POPped from the stack.

It works for me, YMMV.

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages