Re: Code problems with Perform Thru Exit causes fall through


"Richard" <riplin@xxxxxxxxxxxx> wrote in message
news:1185694700.155282.17800@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jul 29, 3:19 pm, "Rick Smith" <ricksm...@xxxxxxx> wrote:
"Richard" <rip...@xxxxxxxxxxxx> wrote in message

You could accomplish exactly the same thing without the SECTION word
and without the EXIT SECTION. A comment line could indicate that this
was a group of related paragraphs.

Others, maybe; but not me! I would accomplish it in
exactly the same way because I am comfortable with
sections and EXIT SECTION.

So you do agree that they are equivalent and it is just a choice ?
That is the SECTION does not add anything that, for example, would
make the compiler do better checking.

No! In particular, paragraph-names need only be unique
within a section. Others may use paragraph-names that
are unique within the program (for example, a prefix on
every procedure-name) and thus obtain some degreee
of equivalence. Since I am not concerned, generally, with
paragraph-names outside the section, any attempt to
modify "my" programs to remove the section keyword
could result in paragraph-name conflicts.

I don't know that sections "would make the compiler do
better checking"; but I believe it helps me to do better
writing.

That is to say that it does not 'encapsulate' in any way, nor provide
any additional safety or other features beyond simply using paragraph
labels (and comments). It does however allow the use of a GO TO
within the scope of the PERFORM though you have replaced this with a
_slightly_ better EXIT SECTION.

Well, as previously discussed, one reason I use sections
is to allow the use of GO TO; but only within the section.
Thus the section exists as if it were a capsule; such that
GO TO statements occur only within that which is
encapsulated.

Yes, but there is no actual 'encapsulation' beyond what you manually
impose with no help from the language or compiler.

Except that the compiler will resolve conflicting
paragraph-names to the same section containing the
GO TO statement.

I like to move code from one place to another. For example taking it
out of a PERFORM VARYING into its own paragraph or vv. Or splitting
down a nested IF into small paragraphs. Any statement that does not
allow this or needs to be changed when moving code I do not use.

For example in your first paragraph if you had a nested IF that had an
EXIT SECTION it would be an error to move that code into a paragraph
(or another SECTION) and PERFORM it.

If I used EXIT SECTION in an IF, EVALUATE, or other
conditional statement, it would not likely be nested and,
therefore, would not need to moved.

IF condition
EXIT SECTION
END-IF

Whether it _needed_ to be moved is irrelevant. It can't be moved
without coding it differently. I prefer code that does not need such
manual intervention for what I see as trivial restructuring.

Perhaps there is some confusion concening EXIT SECTION
versus EXIT PARAGRAPH. As it applies to COBOL 2002,
EXIT SECTION may occur anywhere within the section to
the same effect. It is moving EXIT PARAGRAPH that may
create some problems; but EXIT PARAGRAPH is unrelated
to the use of sections.

I actually did this once, with a slight variation, to isolate
the code for a recursive quicksort.
-----
quick-sort section.
...
call "qsort" using i j
exit section
.
entry "qsort" using l r
...
exit program
.
[performed paragraphs]
[next section]
-----
The implementation does not allow recursive nested
programs.

[Incidentally, this is the same program, I had mentioned
some time ago, as having one section where only GO TO
statements were used for flow control within that section.]

And in what way does this make it 'more maintainable' ?

When sections are used as mini-programs, they have
a well-defined interface, thus all changes to the
mini-program are isolated from the rest of the code.
And, such mini-programs may be easier to re-use.

But is only a manually imposed so-called 'mini-program'. There is
nothing in the language that assists them. as for example is done with
sub-programs. They are not actually isolated, especially not the data
they use.

Paragraph-names are isolated. Isolation of local or
private data requires a naming convention.

When sections are used in the same manner as
paragraphs, they do not necessarily have what may
qualify as an interface and the lack of isolation allows
for the same ad hoc coupling that may exit with
paragraphs only.

Sticking the word SECTION on it makes zero difference, it is only your
self-imposed discipline that creates this alleged 'isolation' and lack
of 'ad hoc coupling'. There is no actual 'interface' in any real way,
merely the way you order the code.

Well, there is a difference in regard to paragraph-names.
And, ...

move data to section-interface-input
perform section-name
move section-interface-output to data

is as real an interface as the equivalent call to a separate
program. It is in the defining of the interface as actual
data description entries that makes the interface real
and, while I suppose some discipline may be required to
prevent ad hoc coupling, I see it as less of an imposition
when using sections. I think this is because procedural
programming is about procedures and using sections as
major procedures implemented by paragraphs as minor
procedures stands out better than paragraph groups.



.

Relevant Pages

  • 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)
  • Re: Infinite Loops and Explicit Exits
    ... Massive changes qualify as a 'redesign'. ... A perform of a section or a perform of a paragraph is no matter as both ... Afterwards they would reset the exit point back to what it ... > was a NULop. ...
    (comp.lang.cobol)
  • Re: Is it possible to use the value of the PROGRAM ID within the source code?
    ... The IBM 705 had an instruction pair something ... And once you were used to using such now known as bad practice ... Then what was EXIT intended for? ... >>a paragraph, how is one to reach an EXIT statement save through PERFORM ... ...
    (comp.lang.cobol)