Re: COBOL ain't quite dead - yet !

On Oct 30, 10:12 am, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
"Howard Brazee" <how...@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;

In what way did this 'aid documentation' that would not occur if the
label had an asterisk placed in column 7 ?

Making it as a comment indicates that it _is_ documentation and not
structural.

Of course if it is 'structural' to the extent that the label and the
following code is a specific type of processing that is subsiduary to
the main part of the section then make it so. Make it separate and
perform it.

The problem with that it that breaking down the sections in a logical
way is too much effort. Putting in a paragraph label is a lightweight
solution that makes you feel that the code is properly structured when
it is not. The style of having 3 labels and an EXIT for everything
makes it too laborious to properly compose, the style gets in the way
of expression.

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...

Yes it does. It 'costs' the potential for errors being made.
Unreferenced paragraph labels (ie drop-through) causes additional time
for the next programmer who has to check whether this would cause a
logic change. For example if the PERFORM had been done in error to the
first paragraph name instead of the section name then the spurious
paragraph label would end the perform while a comment line would not.

Having the section and first paragraph labels 'costs' the possibility
of the wrong one being performed. Having an exit label 'costs' the
possibility of errors such as goto the wrong one, or having a goto
added when the paragraph was performed in error.

Some of those errors would still have the program perform perfectly
_until_, for example, a goto exit was added.

As the only validation for the correctness of the style is by visual
inspection of the whole program then it is not a style that I would
use.


This is very
similar conceptually to PERFORMing a single paragraph,

No it isn't. It is a cluttered and error prone version that is only
used to allow unstructured gotos when it is too arduous to construct
logic that does not require gotos.

Of course the gotos are allowed because the sections become large and
unwieldy because of the overhead of the excessive labels. With simple
paragraphs the 'cost' of breaking down the code into smaller parts and
is trivial, so the logic can be used to avoid the need for goto
_without_ deep indending.


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.

Well you should do ;-)

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.

What is 'easy' is entirely what you are used to. When one writes code
in a particular style one knows exactly the idiom and thus makes no
(or fewer) mistakes. I have worked on code that is as you describe
that had many errors and bug-traps. It was obvious that some other
programmer had later worked on the code and didn't understand the
idiom, or didn't adhere to the style correctly.

.

Relevant Pages

  • Re: COBOL aint quite dead - yet !
    ... Putting in a paragraph label is a lightweight ... The style of having 3 labels and an EXIT for everything ... paragraph label would end the perform while a comment line would not. ... said "the correctness of the program in following the style". ...
    (comp.lang.cobol)
  • Re: COBOL aint quite dead - yet !
    ... The point about goto is that there is nothing at all wrong with a goto ... For example the use of an exit paragraph signals ... loops - which was all about replacing a GOTO with something that did the ...
    (comp.lang.cobol)
  • Re: COBOL aint quite dead - yet !
    ... sometimes I will replace the EXIT. ... The rule was you must ONLY PERFORM a SECTION, NOT a paragraph. ... paragraph label would end the perform while a comment line would not. ... possibility of errors such as goto the wrong one, ...
    (comp.lang.cobol)
  • Re: Para1 THRU Para2
    ... HB>>> The best way to exit a paragraph this way is with an EXIT ... r> putting everything in one sentence makes the nesting too deep. ... One has to look at this logically, and create a transformation ...
    (comp.lang.cobol)
  • Re: COBOL aint quite dead - yet !
    ... sometimes I will replace the EXIT. ... the exactly the same label made into a comment. ... Putting in a paragraph label is a lightweight ... possibility of errors such as goto the wrong one, ...
    (comp.lang.cobol)