Re: COBOL ain't quite dead - yet !



"Richard" <riplin@xxxxxxxxxxxx> wrote in message
news:18e8bb27-c836-4a0e-b611-04c111a41ee8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.

But a comment is not visible from 10 pages on down the listing. The Section
name, on the other hand, is referenced in the PERFORM from ANYWHERE in the
program that the code is activated.



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.

I never found that. But I have little difficulty expressing myself... :-)

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

There is no "drop through" of a sectioned program written by me.

Sections (with the exception of the main one at the start, and this
terminates with a GOBACK, EXIT METHOD, or STOP RUN) can ONLY be PERFORMed,
and ONLY a section can be PERFORMed.

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.

If the site standard is that ONLY sections get PERFORMed, there won't be
erroneous PERFORMs of paragraphs. After working this way for a few weeks you
stop thinking about paragraphs altogether.


Having the section and first paragraph labels 'costs' the possibility
of the wrong one being performed.

In theory, maybe. In practise, at least in my experience, never.

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.

It has never happened.


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.


Fair enough.

It works for me. (And ,over the years, I have never had people complain
about maintaining my code.)

I am not advocating that everyone SHOULD code this way, I'm simply
documenting why I code this way.

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.

Obviously, I strongly disagree :-)

As I avoid the use of GO TO and most of the places where I've worked
discourage them too, your objection is simply academic.

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 ;-)

No, I'd rather fight my corner on it, as i am doing here... :-)

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.

Agreed. But remember thta applies to you equally as much as it does to me...
:-)


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.

Or didn't implement the site standards.

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



.

Relevant Pages

  • 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. ... Of course if it is 'structural' to the extent that the label and the ... 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)
  • Re: COBOL aint quite dead - yet !
    ... sometimes I will replace the EXIT. ... was via the last paragraph. ... In Cobol a label may be the target of a goto, a perform, a drop ...
    (comp.lang.cobol)