Cobol - Re: Infinite Loops and Explicit Exits

Author

Re: Infinite Loops and Explicit Exits

Lueko Willms

2004-11-16, 6:44 pm

.. On 01.11.04
wrote charles.stevens@unisys.com (Chuck Stevens)
on /COMP/LANG/COBOL
in cm63go$1780$1@si05.rsvl.unisys.com
about Re: Infinite Loops and Explicit Exits

CS> Those who suggest that GO TO, PERFORM THRU, and the use of SECTIONs
CS> in COBOL should be archaized in, marked obsolete in, or eliminated
CS> from the standard -- and these are the three steps in that process --
CS> are.

GOTO, PERFORM THRU yes, but SECTIONS no. The opposite makes sense.
The first step to clean up the code is to put a SECTION header on top
of that paragraph-thru-paragraph sentence and eliminate all the
paragraph labels inbetween, restructuring that section into proper
decision and repetition instructions.

So one can by and by change such a program into something readable
and maintainable.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Das ganze Zeitungs-All. -G.C.Lichtenberg

Chuck Stevens

2004-11-16, 6:44 pm

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9KErjo-eflB@jpberlin-l.willms.jpberlin.de...

> I would prefer to avoid such a task, and I guess anybody else also
> prefers not to touch this monster, and its fate will be to be replaced
> completely by a package bought or by a complete rewrite in another
> language and, probably, on another platform.

That may not be an option for a production program. That may in fact be the
*long-term* result, or it might not.

> But I would guess that this half-million-line monster can be melted
> down to at most half of those lines, if not even more, and be speeded
> up at the same time.

Maybe, maybe not! ;-)

> CS> There are cases in which EXIT PERFORM is, I think, clearer than GO TO
> CS> <some-arbitrary-paragraph-somewhere>.
>
> That's why it is in the current standard. But I took issue with your
> proposal to allow it to effect a statement like this:

> MAIN SECTION.
> LOOK-AT-THIS.
> PERFORM procedure-name-1 UNTIL condition-1
> PERFORM some-other-procedure
>
> where "procedure-name-1" is somewhere else in the source code, and
> might look like this:
>
> A)
> procedure-name-1 SECTION.
> BEGIN.
> do-something-here
> IF condition-2
> THEN
> EXIT PEFORM
> END-IF
> do-something-else

EXIT PERFORM in your example A would take you to immediately after the
currently-active PERFORM, which is the first one -- in other words, it would
take you to PERFORM some-other-procedure. You wouldn't execute
<do-something else> and you wouldn't test <condition-1>. You'd be done.

> instead of
>
> B)
> procedure-name-1 SECTION.
> BEGIN.
> do-something-here
> IF condition-2
> THEN
> GOTO ENDE OF procedure-name-1
> END-IF
> do-something-else
> .
> ENDE.
> EXIT.

EXIT PERFORM CYCLE would be functionally equivalent to GO TO ENDE OF
procedure-name-1 in this example, I think.

> But the EXIT PERFORM above does something completely different from
> the GOTO in the second example, or in the third example given here:
>
> C)
>
> procedure-name-1 SECTION.
> BEGIN.
> do-something-here
> IF condition-2
> THEN
> EXIT SECTION
> END-IF
> do-something-else
> .

That too is the equivalent of EXIT PERFORM CYCLE, not EXIT PERFORM, in my
proposal. So my response is "Yes, this is different, it doesn't do the same
thing. That's correct."

To get the analogous functionality to EXIT PERFORM, I think you'd need to do
one of two things:

MAIN SECTION.
LOOK-AT-THIS.
PERFORM procedure-name-1 UNTIL condition-1
PERFORM some-other-procedure
....
procedure-name-1 SECTION.
BEGIN.
do-something-here
IF condition-2
THEN
SET condition-1 TO TRUE
GOTO ENDE OF procedure-name-1
END-IF
do-something-else

Howard Brazee

2004-11-16, 6:44 pm

Do these proposals have a way to exit different levels of perform?

PERFORM AAA UNTIL READ-EOF.

AAAA.
PERFORM BBBB VARYING X-INDEX from 1 by 1 until X-INDEX > X-MAX
AFTER Y-INDEX from 1 by 1 until Y-INDEX > Y-MAX

BBBB.

EVALUATE MY-SWITCH
When "X"
EXIT PERFORM CYCLE ALL
When "Y"
EXIT PERFORM CYCLE
When Other
EXIT PERFORM
END-EVALUATE.

Chuck Stevens

2004-11-16, 6:44 pm

No, they don't; the proposal is only for the *innermost* active PERFORM. It
has neither the "UNDO <labelname>" nor the "UNDO *" of SDL/UPL, and I
haven't figured out a reasonable way to provide it using the EXIT PERFORM
syntax as yet. I'll have to think about your "EXIT PERFORM [CYCLE] ALL",
but my first reaction is that if we're going to expand beyond "innermost",
we'd need more granularity than just "innermost" and "outermost" , and "EXIT
PERFORM CYCLE 293 ALL" or, worse yet, EXIT PERFORM CYCLE <numeric dataname>
ALL", where the number is the mumber of nestings of PERFORM to back out of,
would be, I think, a perfectly terrible idea!

-Chuck Stevens

"Howard Brazee" <howard@brazee.net> wrote in message
news:cmoh2m$hq6$1@peabody.colorado.edu...
> Do these proposals have a way to exit different levels of perform?
>
> PERFORM AAA UNTIL READ-EOF.
>
>
> AAAA.
> PERFORM BBBB VARYING X-INDEX from 1 by 1 until X-INDEX > X-MAX
> AFTER Y-INDEX from 1 by 1 until Y-INDEX > Y-MAX
>
>
>
> BBBB.
>
> EVALUATE MY-SWITCH
> When "X"
> EXIT PERFORM CYCLE ALL
> When "Y"
> EXIT PERFORM CYCLE
> When Other
> EXIT PERFORM
> END-EVALUATE.
>

William M. Klein

2004-11-16, 6:44 pm

a (theoretical)

EXIT PERFORM [CYCLE] ALL

worries me - as I wonder how it would work when an inline PERFORM is nested in
the middle of an out-of-line PERFORM (a fairly common coding situation). Also
it would (might?) impact code that has an inline perform nested within another
inline perform. (Fairly common for '85 Standard code where "AFTER" wasn't valid
for inline performs - although this has been changed in the '02 Standard).

This MIGHT be a good idea, but how existing combinations would work with it
would (I THINK) require some pretty serious study.

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:cmoi8g$1mvg$1@si05.rsvl.unisys.com...
> No, they don't; the proposal is only for the *innermost* active PERFORM. It
> has neither the "UNDO <labelname>" nor the "UNDO *" of SDL/UPL, and I
> haven't figured out a reasonable way to provide it using the EXIT PERFORM
> syntax as yet. I'll have to think about your "EXIT PERFORM [CYCLE] ALL",
> but my first reaction is that if we're going to expand beyond "innermost",
> we'd need more granularity than just "innermost" and "outermost" , and "EXIT
> PERFORM CYCLE 293 ALL" or, worse yet, EXIT PERFORM CYCLE <numeric dataname>
> ALL", where the number is the mumber of nestings of PERFORM to back out of,
> would be, I think, a perfectly terrible idea!
>
> -Chuck Stevens
>
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:cmoh2m$hq6$1@peabody.colorado.edu...
>
>

Lueko Willms

2004-11-16, 6:44 pm

.. On 08.11.04
wrote charles.stevens@unisys.com (Chuck Stevens)
on /COMP/LANG/COBOL
in cmoc4m$1ilj$1@si05.rsvl.unisys.com
about Re: Infinite Loops and Explicit Exits

CS> "Lueko Willms" <l.willms@jpberlin.de> wrote in message
[color=darkred]

CS> That may not be an option for a production program. That may in fact
CS> be the *long-term* result, or it might not.

I'm lucky that I do not have to care for such a monster, I am
rather one of those who offer the alternative of replacing that mine
field with my database solutions.

But I would recommend any IT manager to take on those old monsters
and clean up the code, not a complete rewrite, but a stepwise
refinement.

Last night I happened to see the French-Swiss TV-news with a report
on the presentation of a new seismic map of Switzerland, which showed
Wallis as a endangered area. The last earthquake in Wallis had been in
1946, and many buildings erected since then have not taken the danger
of a new earthquake into account, an expert was quoted.

I recommend to do a proper calculation of the statics of the old
programs...
[color=darkred]

CS> Maybe, maybe not! ;-)

Sure, I can't know without having seen the patient, and without
having performed the operation.

But the ballpark guess that a large part of the lines spent in the
program are acually lines wasted would be my guideline for the work.

I would start with cleaning those sequences of paragraphs PERFORMED
.... THRU by putting a SECTION header on top of them, eliminating all
the paragraphs (instead of a first one) and changing it into a proper
structure with IFs and ELSEs ... under condition that there are not
overlapping PERFORM ... THRU ..., no drop through from previous
paragraphs, no ALTER or similar tricks.

The progressive transformation shown in my previous post shows how
wasted lines can be saved, and the code be cleaned.
[color=darkred]

CS> I agree absolutely. That's why *my* preference (with or without
CS> sections) is that the programmer be *allowed* to do this.

Programming in COBOL is like working in a sky-scraper construction
site, in the shell, whith no outer walls yet and no protection at the
edges of the floor, at staircases of elevator shafts. One wrong step,
and the worker falls dozens of floors deep into death.

Other languages have all those safeguards built in. It is simply not
possible to accidentally drop thru the end of a procedure or function.

COBOL has now provided similar means with the user-defined
functions, but which compiler already has implemented those?

It is certainly not practical to eliminate the unsafe elements from
the language specifications, but one should not create new ones, as
you do with your proposal.

Which is not necessary, as you can recommend to change according to
the transformation shown below:

CS> LOOK-AT-THIS.
CS> PERFORM procedure-name-1 UNTIL FALSE.
CS> PERFORM some-other-procedure
CS> ...
CS> procedure-name-1.
CS> do-something-here
CS> IF condition-2
CS> THEN
CS> EXIT PERFORM CYCLE
CS> END-IF
CS> do-something-else
CS> IF some-arbitrary-complex-set-of-conditions THEN
CS> EXIT PERFORM
CS> END-IF
CS> .

First, change it into an "inline PERFORM":

LOOK-AT-THIS.
PERFORM UNTIL FALSE.
do-something-here
IF condition-2
THEN
EXIT PERFORM CYCLE
END-IF
do-something-else
IF some-arbitrary-complex-set-of-conditions THEN
EXIT PERFORM
END-IF
END-PEFORM
PERFORM some-other-procedure
...

clean up the conditional execution:

LOOK-AT-THIS.
PERFORM UNTIL FALSE.
do-something-here
IF NOT condition-2
THEN
do-something-else
IF some-arbitrary-complex-set-of-conditions THEN
EXIT PERFORM
END-IF
END-IF
END-PEFORM
PERFORM some-other-procedure
...

Now one sees, that the some-arbitrary-complex-set-of-conditions is
actually at the edge of the loop, so that we can put it in the entry
of exit condition for the loop:

LOOK-AT-THIS.
PERFORM UNTIL some-arbitrary-complex-set-of-conditions
do-something-here
IF NOT condition-2
THEN
do-something-else
END-IF
END-PEFORM
PERFORM some-other-procedure

Now there is a difference with this code and your example, where
the some-arbitrary-complex-set-of-conditions is only tested when
condition-2 is false, while in this latest transformation is is tested
with each cycle. The semantics have to be checked.

But it shows that all those additional pitfalls are not needed.

Generally, I would look into the data structure and check, if the
loop exit has really to be in the middle of the loop, and if the loop
could not be restructured; like in the case of reading sequentially
thru a file or similar structure, where for n elements in the
collection n + 1 attempts to fetch such element have to be performed,
and the additional fetch attempt is done as the GetFirst immediately
before the loop with the presence of a record as entry condition.

PERFORM FOREVER would be rarely needed in a COBOL program, since an
unbounded loop should only be specified, when really the sequence of
events or objects worked on in that loop, is infinite. But commercial
data are rather finite.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Man stattete ihm sehr heißen, schon etwas verbrannten Dank ab. -G.C.Lichtenberg

Howard Brazee

2004-11-16, 6:44 pm

On 9-Nov-2004, l.willms@jpberlin.de (Lueko Willms) wrote:

> Programming in COBOL is like working in a sky-scraper construction
> site, in the shell, whith no outer walls yet and no protection at the
> edges of the floor, at staircases of elevator shafts. One wrong step,
> and the worker falls dozens of floors deep into death.
>
> Other languages have all those safeguards built in. It is simply not
> possible to accidentally drop thru the end of a procedure or function.

Some other languages. Other languages (C) leave you much more exposed.

And some of the languages keep you protected, sort-of. In a deep cave where
you can't fall, but you also can't see where the dangers are.

Peter Lacey

2004-11-16, 6:44 pm

Lueko Willms wrote:

> But the ballpark guess that a large part of the lines spent in the
> program are acually lines wasted would be my guideline for the work.

There are those who claim that comments are wasted lines. Yet, at the
same time Dijkstra came out with his thunderbolts there were articles
(in Computerworld, Datamation, other publications of the time, and I
deeply regret not keeping them) that stated that comments were equally
as effective in making programs easy to write, maintain and follow but
(approximate quote) "comments aren't intellectually exciting enough".
>
> I would start with cleaning those sequences of paragraphs PERFORMED
> ... THRU by putting a SECTION header on top of them, eliminating all
> the paragraphs (instead of a first one) and changing it into a proper
> structure with IFs and ELSEs ... under condition that there are not
> overlapping PERFORM ... THRU ..., no drop through from previous
> paragraphs, no ALTER or similar tricks.
>

There's a saying, originating in this continent but I'm sure you're
familiar with it: "if it ain't broke, don't fix it". What you're
proposing here is not simply maintenance enhancements but a rewrite of
the procedure division. I don't see how you can consider that replacing
a host of paragraphs with "a proper structure of IF's and ELSE's" is
straightforward: you're implying a lot of skull sweat to be expended for
the sole purpose of arriving where you were at to begin with. Now if,
as Robert W. suggested, a program needs fixing 2 or 3 times a w

, then
it assuredly needs to be rewritten. But to take a suite of programs
which functions imperturbably and needs attention only occasionally and
rewrite it purely for ideological reasons is just plain - nuts.

I'm surprised that ALTER's continue to show up for discussion purposes.
That would seem to state that the programs in question have been
functioning for a VERY long time. Whether or not they have needed lots
of maintenance is of course a different matter.

PL

Lueko Willms

2004-11-16, 6:44 pm

.. Am 09.11.04
schrieb howard@brazee.net (Howard Brazee)
bei /COMP/LANG/COBOL
in cmqmfa$52r$1@peabody.colorado.edu
ueber Re: Infinite Loops and Explicit Exits
[color=darkred]

HB> Some other languages.

With different advantages and di

vantages.

HB> Other languages (C) leave you much more exposed.

Not in the area of program flow, but thow by the possibility to
create new variables on the fly hidden somewhere between procedural
statements, what is not possible in COBOL.

But there is no chance to fall through the end of a function
declared in C, and accidentally start executing the next function.

Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Es sind nicht die Generäle und Könige, die die Geschichte machen,
sondern die breiten Massen des Volkes" - Nelson Mandela

Lueko Willms

2004-11-16, 6:44 pm

.. Am 09.11.04
schrieb lacey@mb.sympatico.ca (Peter Lacey)
bei /COMP/LANG/COBOL
in 4190FCCD.93B737DE@mb.sympatico.ca
ueber Re: Infinite Loops and Explicit Exits

I want to emphasize that this is a very speculative discourse; we
are talking about hypothetical programs which we don't know.
[color=darkred]

PL> There are those who claim that comments are wasted lines.

I did not think of comments in the source code, only of those lines
relevant for the generation of the executable program.

But sure, I think the program text itself should be self-
documenting, i.e. a) clear enough structured; b) sensible data- and
procedure names which do not require guesswork or additional
documentation to explain their meaning.

For comments on the side of the actual source code, my rule is: as
few as possible, as much as necessary.

And, also think of Gershwin's law of documentation:
"It ain't necessarily so".

Quite often it happens that the program is changed, but the
documentation is not brought up to date, to conform with the actual
program.

[color=darkred]

PL> There's a saying, originating in this continent but I'm sure you're
PL> familiar with it: "if it ain't broke, don't fix it".

Sure, but when I know that a building is structurally weak, I
prefer to reinforce the building's structure in anticipation of
earthquakes which can strike without warning.

What I propose is to prepare those monster-programs for change, to
clean up and reinforce their structure so that they can easily be
changed in their actual effect.

Think of it as preventive maintenance.

PL> What you're proposing here is not simply maintenance enhancements
PL> but a rewrite of the procedure division.

Yes.

But not necessarily in one sweep, but in steps.

PL> I don't see how you can consider that replacing a host of
PL> paragraphs with "a proper structure of IF's and ELSE's" is
PL> straightforward: you're implying a lot of skull sweat to
PL> be expended for the sole purpose of arriving where you were at to
PL> begin with.

That may well be, but the amount of work depends on the size of the
task, i.e. the how well the program is done. But the result may well
be worth the sweat and effort.

I'm still working on a project (not COBOL based) which I had taken
over from somebody else, and where originally my job was only to add
more tables to the database and create some forms and procedures to
work comfortably with these additional features.

I decided to leave the original modules as much unchanged as
possible, but that was an error which had costed me not months, but
years of additional time. If I had cleaned up the code from my
predecessors right away, I would have been able to advance faster.

As to these presumed COBOL monster programs, the proposal to clean
them up will not only be rejected with the argument you are bringing
up "If it ain't broke, don't fix it", but also by a "don't waste time
on that old stuff, we are thinking about replacing it completely".

But in a concrete situation, it might be alltogether different.

Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Ohne Pressefreiheit, Vereins- und Versammlungsrecht ist keine
Arbeiterbewegung möglich" - Friedrich Engels (Februar 1865)

Robert Wagner

2004-11-16, 6:44 pm

On 02 Nov 2004 19:57:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

> My style is to only use SECTIONs which all have only one paragraph,
>named ANFANG (German for "BEGIN").

Why do you put an unreferenced paragraph name -- ANFANG -- at the
beginning of each section? The Standard does not require a paragraph
name.

"A paragraph consists of a paragraph-name followed by a period and a
space and by zero, one, or more successive sentences or, if the
paragraph-name is omitted, one or more successive sentences following
the procedure division header or a section header. A paragraph ends
immediately before the next paragraph-name or section-name"

Deleting the word SECTION would produce the same result.

Peter Lacey

2004-11-16, 6:44 pm

Lueko Willms wrote:
>
> . Am 09.11.04
> schrieb lacey@mb.sympatico.ca (Peter Lacey)
> relevant for the generation of the executable program.
>
> But sure, I think the program text itself should be self-
> documenting, i.e. a) clear enough structured; b) sensible data- and
> procedure names which do not require guesswork or additional
> documentation to explain their meaning.

The code can be clear as a bell, properly structured, meaningful data
names etc., and still be incomprehensible. If you don't know what the
program is supposed to be doing - let's say it's implementing some
encrypting method which you don't know exists - you will NEVER be able
to understand the code. At the very least, comments indicating where
the problem statement is to be found are an absolute requirement.
>
> For comments on the side of the actual source code, my rule is: as
> few as possible, as much as necessary.

Mine is the same as taking photos when on a trip: better too many than
too few.
>
> And, also think of Gershwin's law of documentation:
> "It ain't necessarily so".

Hee hee! Good point.
>
> Quite often it happens that the program is changed, but the
> documentation is not brought up to date, to conform with the actual
> program.

Then the comments are REALLY needed! I'd upgrade "quite often" to
"nearly always".

>
> I'm still working on a project (not COBOL based) which I had taken
> over from somebody else, and where originally my job was only to add
> more tables to the database and create some forms and procedures to
> work comfortably with these additional features.
>
> I decided to leave the original modules as much unchanged as
> possible, but that was an error which had costed me not months, but
> years of additional time. If I had cleaned up the code from my
> predecessors right away, I would have been able to advance faster.

Not to disparage your experience, but another saying applies: "one
swallow does not make a summer".

I can cite an example where a colleague tried to "structure/clean up"
(as you're using the concept) a program of mine, 2000 lines long, with 8
goto's. Took him three days! The program was working perfectly well -
had been for three years - but his brain seized when he saw the goto's.
He had to ask me for help. Resoundingly not worth his trouble.

>
> As to these presumed COBOL monster programs, the proposal to clean
> them up will not only be rejected with the argument you are bringing
> up "If it ain't broke, don't fix it", but also by a "don't waste time
> on that old stuff, we are thinking about replacing it completely".
>
> But in a concrete situation, it might be alltogether different.
>

So it might. But, as a manager, I'd want a guaranteed positive and
significant ROI on such a conversion proposal.

PL

Richard

2004-11-16, 6:44 pm

Peter Lacey <lacey@mb.sympatico.ca> wrote

> There are those who claim that comments are wasted lines.

I try to remember to write comments that can be used as the user
documentation. Comment in blocks that are tagged with *<html> to
*</html> are extracted to form the html pages for the program.

The introduction comment block is up in the IDENTIFICATION DIVISION,
this describes the function of the program, details are in the PD
describing, for example, each input field when they are accepted or
processed, the processing actions, setup options. If I've used a
screen generator or SP2, I can process those to make a <pre> block of
the screen.

Sometimes I have to reorder the code to make the documentation flow
correctly, but that is not a problem with the style that I use.

This does mean that the user documentation gets updated whenever the
program is changed, or at least it is right there so that I can do
that, rather than having to change to some other set of files.

Lueko Willms

2004-11-16, 6:44 pm

.. Am 09.11.04
schrieb lacey@mb.sympatico.ca (Peter Lacey)
bei /COMP/LANG/COBOL
in 419192C2.4B3A7292@mb.sympatico.ca
ueber Re: Infinite Loops and Explicit Exits

PL> The code can be clear as a bell, properly structured, meaningful data
PL> names etc., and still be incomprehensible. If you don't know what
PL> the program is supposed to be doing - let's say it's implementing
PL> some encrypting method which you don't know exists - you will NEVER
PL> be able to understand the code. At the very least, comments
PL> indicating where the problem statement is to be found are an absolute
PL> requirement.

That's the kind of comment I had in mind as the necessary comments.
To explain what is not obvious from the code. But also, as DocDwarf so
efficiently explained, "obvious is in the mind of the beholder".

But one should assume that the reader knows COBOL and knows about
the task being solved.
[color=darkred]

PL> Then the comments are REALLY needed! I'd upgrade "quite often" to
PL> "nearly always".

And I was thinking of the part of documentation which is the
comments in the program text.

Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Es sind nicht die Generäle und Könige, die die Geschichte machen,
sondern die breiten Massen des Volkes" - Nelson Mandela

Lueko Willms

2004-11-16, 6:44 pm

.. On 02.11.04
wrote charles.stevens@unisys.com (Chuck Stevens)
on /COMP/LANG/COBOL
in cm8rqo$1mg$1@si05.rsvl.unisys.com
about Re: Infinite Loops and Explicit Exits

LW>> So one can by and by change such a program into something
LW>> readable and maintainable.

CS> Yes, you can. But do you wanna take on restructuring a 500,000-line
CS> monolithic COBOL program to make that happen?

I would prefer to avoid such a task, and I guess anybody else also
prefers not to touch this monster, and its fate will be to be replaced
completely by a package bought or by a complete rewrite in another
language and, probably, on another platform.

But I would guess that this half-million-line monster can be melted
down to at most half of those lines, if not even more, and be speeded
up at the same time.

CS> There are cases in which EXIT PERFORM is, I think, clearer than GO TO
CS> <some-arbitrary-paragraph-somewhere>.

That's why it is in the current standard. But I took issue with your
proposal to allow it to effect a statement like this:

MAIN SECTION.
LOOK-AT-THIS.
PERFORM procedure-name-1 UNTIL condition-1
PERFORM some-other-procedure

where "procedure-name-1" is somewhere else in the source code, and
might look like this:

A)
procedure-name-1 SECTION.
BEGIN.
do-something-here
IF condition-2
THEN
EXIT PEFORM
END-IF
do-something-else

Chuck Stevens

2004-11-16, 6:44 pm

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9KccN$euflB@jpberlin-l.willms.jpberlin.de...

> That's the kind of comment I had in mind as the necessary comments.
> To explain what is not obvious from the code. But also, as DocDwarf so
> efficiently explained, "obvious is in the mind of the beholder".

Amen to that one, brother!

I think I've mentioned this example in this newsgroup before. I was trying
to locate a problem -- I can't even remember what the problem was -- and
finally narrowed it down to somewhere in about a thousand lines of
incomprehensible gobbledygook that looked a lot like APL, guarded by a
really elaborate IF statement with lots of parentheses that ran some fifteen
lines all told. Buried way down in the middle of this morass of the
operational code was the lone comment for the entire thousand-line process:
"Yes, this is what you think it is."

Took me something like three w

s to figure out what "this" was, and it
turns out that it was an optimization for which there was no concievable
real-world purpose except to show in a benchmark that the performance of a
construct nobody would ever use performed better than it used to. I ripped
out the fifteen-line guarding test and the thousand lines of code, and my
problem went away.

Point being, it was entirely obvious *to the author* what this code did.

-Chuck Stevens

Howard Brazee

2004-11-16, 6:44 pm

Chuck Stevens

2004-11-16, 6:44 pm

Howard Brazee

2004-11-16, 6:44 pm

Peter Lacey

2004-11-16, 6:44 pm

Sponsored Links