Re: EXIT PERFORM Help, please [LONG response]

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9L4iCxfPflB@jpberlin-l.willms.jpberlin.de...
> .    On  18.11.04
>   wrote  jjgavan@shaw.ca (James J. Gavan)
>      on  /COMP/LANG/COBOL
>      in  K96nd.256010$Pl.117101@pd7tw1no
>   about  Re: EXIT PERFORM Help, please
>
>
<snip>>
> JJG> Small wonder Pete Dashwood says he 'hates posting code here' :-)
>
>   Did he? I think, it is much better to concretely discuss about real
> code than exchanging arguments in the abstract.
>

Jimmy is correct and I am on record as having said that.

However, when things are taken out of context the meaning is often changed.

The reason I hate posting code here (although I have actually posted
thousands of lines here over the years), is NOT because I fear peer review.
(I tend to agree that this is useful. Even if it doesn't change my mind, at
least it makes me re-examine things, and that is valuable.)

It is because, on many occasions here, people will not "see" what the code
snippet is attempting to portray. Instead, they will go off into a fierce
diatribe about style. (I have to admit, that as time has gone by, this
happens less often; I think everybody has come to realise that "Style Wars"
really achieve nothing.)

The other thing is that everyone is different. Some people need a practical
down-to-earth example provided by code, others are happy to discuss at a
conceptual level. Personally, I prefer the latter (mainly because I see
abstraction better than wading through someone else's code), but I accept
that many people will prefer to have a code sample and I don't think they
are wrong...

I like a generalised solution and abstraction is the first step towards
that.

>   I think that code review by peers is a very good, healthy and useful
> undertaking.
>

It depends on how it is done and the nature of the "peers". I would agree
that it CAN be...

> JJG> Even the thread "Infinite Loops' has itself become an infinite loop
> JJG> of verbiage !
>
>   Quite some amount of concrete code examples have been discussed.
>
>   I don't care too much about the unavoidable level of noise in such a
> discussion.
>
>   And I think, just that discussion has been quite useful.
>

There is no right or wrong here. People who find it tiresome (and I am
moving towards that camp...) simply don't have to read it. (Ctrl-T is your
friend.... <G> )

>
>   Coming back to those code snippets, let us just take the first one,
> which you presented as an example of how to use EXIT PERFORM. Well, it
> isn't an example for EXIT PERFORM, because that instruction will never
> be executed:
>
>
> JJG>>         perform varying c from 1 by 1 until c > MaxColumn
> JJG>>              after L from 1 by 1 until L > lnk-LinestoPrint
> JJG>>
> JJG>>                 if    L > lnk-LinestoPrint
> JJG>>                       Exit Perform
>
> LW>            *>  this EXIT PERFORM will never be executed, since
> LW>            *>  this loop will not be entered
> LW>            *>    when L > lnk-LinestoPrint
>
>    instead of EXIT PERFORM, one could as well have written STOP RUN,
> or CALL 'reboot-immediately-with-no-confirmation', or DISPLAY 'the
> boss is a XXXXing XXXXXXX', and nothing would have happend, since
> these instructions would _never_ had a chance to be executed. This is
> not a matter of personal style, it simply dead coding.
>
>    Or this other example which I dare to repeat here (with a little
> change by me, as explained in my previous post):
>
>             IF Materials-Stress (P) = Zeroes
>                  move P      to P2
> JJG>             move zeroes to P
> JJG>
> JJG>             perform varying P from P2 by -1 until P = zeroes
> JJG>
> JJG>               if Materials-Stress(P2) <> zeroes
> JJG>                  move P2 to P
>
>          *> P2 is not varied in this loop, only P is counted down
>          *> from the current value down to ZERO, without affecting
>          *> the above condition in any way.
>
>          *> this loop is just a waste of machine time
>          *> just doing a race counting doen P to zero.
>          *> One could as well just drop it, and even the IF
>
>          *> probably a SEARCH or SEARCH ALL would be clearer
>          *> and at any rate, more efficient
>
> JJG>                  EXIT PERFORM
> JJG>               End-if
> JJG>
> JJG>             End-perform
> JJG>        End-if
>
>     this is also not an example for EXIT PERFORM, since this EXIT
> PERFORM will never be executed -- the loop is only entered, when
> "Materials-Stress (P)" is Zero, and since P2 gets assigned the value
> of P before the loop, and is not varied in the loop, "Materials-Stress
> (P2)" will never become something else than zero.
>
>    The loop around it is just a waste of machine resources, and again,
> that is not a matter of personal style. That whole piece of code could
> be removed from that program without any effect at all except speeding
> up the execution a litte bit.
>
>    And please, do not see this as a personal attack or something like
> that.
>

Lueko, have you spent a lot of time managing programmers? <G>

It is VERY hard for people to separate themselves from their work.

Many years ago, I learned that you must never say "You" when talking about
someone's code...

"The code does this..."
"The code needn't do that..."

instead of

"You wrote this... when you should've done..."

Even this is not enough to keep the review calm and useful (but it
helps...).

I have examined your analysis of various code snippets in this forum and I
find as follows: <G>

1. Your comments are usually accurate and perceptive.
2. You have a genuine (and commendable) desire to help people improve their
COBOL.
3. Sometimes you are a bit too strong but that is simply the zeal of the
believer... <G> (there is no malice in you...)

Given all of the above, one would expect that your critique would be well
received.

But you are dealing with Human Beings. They come from different cultures and
they have thoughts and feelings.

"...which you presented as an example of how to use EXIT PERFORM."

First mistake, saying "you"...

Your comments were accurate but your personal zeal led to some unnecessary
labouring of the points... (If you make a point, there is no need to "rub
someone's nose in it" -     "...instead of EXIT PERFORM, one could as well
have written STOP RUN,  or CALL 'reboot-immediately-with-no-confirmation',
or DISPLAY 'the boss is a XXXXing XXXXXXX', " - unneccesary, and
unhelpful... the point is that the code was unexecutable).

This type of critique will not help you achieve your objectives. It is
unlikely Jimmy will change his code as a result of this review. What is far
more likely is that he will hesitate to post code samples here any more. If
that happens frequently, we will see less and less code posted here. As
mentioned above, personally, I would have no problem with that, but there
are others who will.

Think about his objectives in posting in the first place: He was trying to
help.

A number of people responded to my request for assistance (on the whole,
CLCers are decent sorts...). Some of these responses were of more use to me
than others, but I respect the fact that all of them were trying to help.

What has come out of it?

I now feel confident about using EXIT PERFORM but I won't be going near EXIT
PERFORM CYCLE or the Fujitsu equivalent you posted. (I like to try and keep
my  COBOL code vendor independent, but break this rule for encapsulated OO
components where it will never be maintained, and the Object is all that
matters.)

>    Code review by peers should be done more often.

Only if it makes a difference...<G> If it simply makes people feel bad, it
is best avoided. (Unless, of course, the code doesn't work...)

>
>    Finally, the way PERFORM VARYING is being used in those code
> snippets could nurture the suspicion that the UNTIL condition
> specified with an PERFORM VARYING is only seen to be related to the
> variable being varyied. But it isn't. It is the general condition for
> entering the loop, and does not need to have any relationship
> whatsoever with the varyied variable. One could well write
>
>    PERFORM read-infile VARYING record-count UNTIL has-reached-EOF
>

Now you are talking programming philosophy and it is arguable. While your
description is accurate, some people would disagree with whether you should
use the PERFORM condition in that way.

Please continue with your posts, observations, and critiques, but remember
that programmers generally are sensitive to what they write. No-one comes to
work in the morning and logs on with: "I think I'll write some really crap
code today..." <G>

And yet crap code exists. Many people here have to deal with it every day.

This forum is one place where we can do something about it and I know that
is your intention.

Pete.
(more below)
>
> Yours,
> Lüko Willms                                     http://www.willms-edv.de
> /--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
> Die gefährlichsten Unwahrheiten sind Wahrheiten mäßig
entstellt. -G.C.Lichtenberg
>
I couldn't get this: "The most dangerous lies are truths ...something or
other" Could you translate, please?

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9L8l2Si9flB@jpberlin-l.willms.jpberlin.de...
> .    On  19.11.04
>   wrote  dashwood@enternet.co.nz (Pete Dashwood)
>      on  /COMP/LANG/COBOL
>      in  304t18F2r157pU1@uni-berlin.de
>   about  Re: EXIT PERFORM Help, please [LONG response]
>
>
>    Thank you about your kind words. I try to eliminate possibly
> offensive formulations as much as possible, but I have to struggle to
> do it. :-(( But I think that I have achieved some progress thru my
> experience in this forum.
>
>    I also like to discuss concepts in the abstract, but these also
> need to be illustrated by concrete examples, and for that code review
> is a good thing. I think we should do more of that in this forum
> instead of bickering about concepts.
>
>
>    Now to this concrete question about PERFORM VARYING ... UNTIL,
> COBOL's version of the FOR loop:
> 
>
> PD> Now you are talking programming philosophy and it is arguable.
>
>    Well no, first I ask if the syntax of that statement may have been
> misunderstood as saying that the UNTIL condition in a PERFORM VARYING
> is only to specify a limit to this variation.

The word "UNTIL" by definition, requires a condition to follow it. That
condition does not have be concerned with the variables being manipulated by
the PERFORM (it can be ANY condition detectable by the program code). This
is where the "philosophy" (as documented in the site standards) comes in. I
don't believe that people "misunderstand" this (at least, native English
speakers would be unlikely to...), it is simply a matter of control. I have
worked on sites where VARYING was banned (too complex... <G> ) and I have
worked on sites where it was allowed ONLY PROVIDED that the condition
following UNTIL was related to the variables under control of the VARYING.
(Exactly the case you describe).

For myself, I do not proscribe it in any way, but I have the luxury of
deciding my own "site standards".

I don't think it is "right or wrong" any more than ANY site standard is
"right or wrong". We all see standards we strongly disagree with (or
strongly agree with...), it  really comes down to how you approach COBOL
programming.  And that is a matter of "philosophy".

>And I state that the
> published COBOL syntax does not say so, and compilers have implemented
> the UNTIL condition as the general condition to enter the loop,
> independently of the value of the VARYING data-item. The
> misunderstanding may arise from the fact that an UNTIL condition is
> required for every nested VARYING or AFTER.

I don't believe there is any such "misunderstanding". People either
investigate PERFORM...VARYING ...[AFTER ] and find out how it works, or they
simply leave it alone. However, I would accept that people whose first
language is not English, COULD have some different concepts about what UNTIL
means...
>
>    And I think, that when there are other limiting conditions for the
> loop besides a possible limit, this should be specified in the UNTIL
> condition on the loop, er, PERFORM statement. Let's be clear and to
> the point, and not distribute bounds to the loop over several places.
>

That is a perfectly valid philosophy. You could encapsulate it in a site
standard.

 
> PD> entstellt. -G.C.Lichtenberg 
> PD> I couldn't get this: "The most dangerous lies are truths ...something
> PD> or other" Could you translate, please?
>
>    The verb "entstellen" means disfigure, deform, distort, or
> misrepresent. So one might translate the above aphorism as:
>
>   "the most dangerous lies are truths slightly distorted".
>
>    BTW, there are also sites on the Web on Lichtenberg in English. I
> googled for his name when you first indicated your interest, and found
> some, but unfortunately did not report back, for fear of carrying owls
> to Athens...
>
Thank you very much for that, Lueko. (I could have searched or used a
dictionary, but your explanation has added value to what I would have
found.)
>
Pete.