Re: COBOL ain't quite dead - yet !

On Oct 31, 11:34 am, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
"Richard" <rip...@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.

Your claim was: "(The primary purpose of any paragraphs other then the
first and last one in the section was to aid documentation;". This was
what I directly answered by asking if this was any more useful than
the exactly the same label made into a comment. It has nothing to do
with section name or being performed.

Do try and keep up.


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.

Your claim was: "(The primary purpose of any paragraphs other then the
first and last one in the section was to aid documentation;". These
are the 'unreferenced labels' that _ARE_ dropped thru.

Do try and keep up.

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.

Of course if the word 'SECTION' is omitted by mistake then the
compiler won't care, or warn you. There is also no check that every
label referenced by a PERFORM _is_ a section label.

OTOH is is simple to verify the reverse. A grep will confirm that
there are no SECTION words in the procedure division and thus performs
are _only_ of paragraph labels. A grep will confirm there is no use of
THRU. What do you have ?


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.

What mechanism guarantees this, other than visusal inspection of every
perform and the label it references ?

Oh, wait. You just trust other programmers assurances that they never
make mistakes ?


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.

Or maybe you never noticed because performing the first paragraph
gives identical results in testing so the program is 'bug free' -
until someone adds a goto exit or exit section or a 'commentary'
paragraph label.

The issue isn't whether programmers are perfect, not even I am that,
but whether the code can be verified to match the standard.

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.

Well, OK, you _are_ perfect then. But others may not be so.


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.

And I am saying why I progressed beyond that.

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.

If you eliminate the use of goto then there is never any need to have
the clutter of the exit paragraph. A simple line of hyphens or equals
is what I use to separate parts of the program.

If you eliminate the exit paragraphs and have already stated that the
'first paragraph' is unreferenced then you can eliminate that and, by
removing all the SECTION words you have an actual assurance that all
the performs _are_ consistent.


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

Well I was 'used to' using sections, exactly as you said. Then I
realised the steps as above and noticed that I had several less things
that needed checking to make the program work correctly.

For example when coding using your style I noticed that every time I
did a perform I checked it was the section name, that there was an
exit paragraph, that the following label was indeed a section header.
Everytime I split a section I went through the same checks and had to
key in the clutter.

As soon as I changed to paragraphs only I immediately noticed that
there was almost nothing that needed checking. What I did
automatically and treated as a normal part of all programming simply
was not needed. This sped up my programming and resulted in less
testing and correction being required.




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 !
    ... 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. ... 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: 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)
Quantcast