Re: Bad habits of GOTO-using programmers

On Nov 11, 2:28 am, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
"William M. Klein" <wmkl...@xxxxxxxxxxxxxxxxx> wrote in messagenews:hkNRk.145893$cU2.30642@xxxxxxxxxxxxxxxxxxxxxxxxx



Richard,
Not worth responding in detail. You use of "fall-thru" is NOT the same
as mine (or that of anyone that I can remember ever working with.)

In the case of
Perform Para1 thru Para3
with a structure of

Para1.
....
Para2.
...
Para3.

Then there IS a "fall-thru" (or fall into if you prefer) from Para1 to
Para2. There is NOT a fall thru from Para2 to Para3 as Para3 is part of
the explicit PERFORM statement.

I agree with Bill's interpretation and I'd go further... I'd say that in the
example above the execution of para2 is NOT a "fall thru" because it is part
of the specified scope of the PERFORM.

If I PERFORM a SECTION with several paragraphs in it (provided I don't do
any branching out of the section) then that SECTION is a defined scope and
it is arguable if paragraphs receiving control within that scope, are "fall
thrus".

The question was whether the paragraphs are 'dropped into', or putting
it another way, the labels are 'dropped through'.

In your case they _are_ dropped into from the last sentence of the
previous paragraph.

(More importantly, it is irrelevant if I am looking to debug a
roblem with control flow...)

Actually it is _NOT_ irrelevant. The presence of the labels means that
the code must be examined to see if there is any control flow that
will use these.

You may well just glance at the code and say: "I remember not using
that label, therefore it is irrelevant". The next programmer has no
such memory or your not doing that. He has to create his own memory of
it not being used by examining every line of code.


For example:

some section.
p000.

.....

p010.

....

p020.

if some-condition
go to p000
end-if
...

p999.
exit.
===============================

It seems pointless to me to argue whether control "falls thru" each of the
paragraphs...

The question was 'falls into'. The option was 'go to'. For every label
that you use the next programmer will have to dertermine whether this
is 'dropped into' or 'go toed'. If the label did not exist as a label
there would be no need to determine this.


it doesn't matter. The defined scope is the SECTION and that
is the "unit" of control transference that we need to be concerned with.

Similarly, PERFORM para1 thru para3 defines an explicitly scoped "unit" of
control transference, in fact, the scope of any PERFORM does this. What
happens inside the scope of that unit is of no consequence; problems of
control flow occur only when we jump out of this defined scope, or
inadvertently fall out of it, and that cannot happen if it has been
PERFORMed (and there are no GO TOs or ALTERED procedures within the scope.)

It really comes down to what you mean by "fall thru".

You can argue that all code execution is a "fall thru" to the next
sequential instruction, unless diverted by a branch or jump in which case
you have simply "fallen" into a different location... But what point does
such an argument serve?

The choice is 'fall into' or 'go to'. This choice only happens at
labels and is important to resolve in order to determine the flow of
the program.

The fewer labels the less problem in determining how the flow goes.


Like I said before, this whole discussion would be important if control flow
was problematic, but for the most part, it isn't. Checks and balances
already in place on most installations, plus programmer experience over
years, all combine to make it simply a storm in a teacup. Peter's survey
showed that at least the people who responded, all applied constraints to
code to prevent control flow issues (Minimal use of GO TO, one entry and one
exit to a performed scope, no ALTERs, etc.), most production problems are
caused by bad data or data that is outside the validation scope of the
program concerned, NOT with control flow branching out of a PERFORMED range,
or dropping inot places where it shouldn't.

The problem isn't at tightly controlled sites where there is peer
review. The problem is in code that you may be given with an unknown
history.

Actually the problem _is_ at tightly controlled sites because of the
_cost_ of developing Cobol. There is no automated checks, peer review
doubles development time. Sites switch to more productive languages.

What I am saying is that as long as code is written in archaic and un
productive styles (such as yours) the more likely that Cobol will be
discarded and replaced, as you have done, with Java, C# or others.


When's the last time you saw an endless loop in production, or S0C3/4 (NOT
caused by bad subscripting/indexing...)? And, if you can answer in the
affirmative, what percentage of ALL production errors was this?

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



I understand your (repeated) view that this isn't true, but that does NOT
mean that this is the common usage of "fall thru" (or fall into) as used
by those COBOL programmers that I have worked with.

I have certainly seen several others posting in this group who agree with
my understanding of this term. I would be curious if there are others
reading/participating in CLC who would think that in
Perform PARAx thru PARAy
that the "entrance" into PARAy is *ever* a "fall thru". (or fall into or
any other type of "fall").

If I am in error in reading YOUR note (not Robert's) and you agree that
the entry into PARAy is NOT a "fall into/thru", then I apologize for my
misunderstanding.

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <rip...@xxxxxxxxxxxx> wrote in message
news:3890aac7-c251-4ac8-a2b9-4980735828c7@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Nov 7, 3:50 pm, "William M. Klein" <wmkl...@xxxxxxxxxxxxxxxxx>
wrote:
Richard,
The Standard (and all compilers that I know of) allow for:

Perform Para2 thru Para1
...
Para2.
Display "second".
Para1.
Display "first".

According to your logic below, this causes a "fall-thru" from Para1 to
Para2.
Is this really what you mean? If not, how does it differ from
Perform Para2 thru Para1

Please re-read your message and correct it.

I do not know why you got this backwards.

Please reread my message and understand it.

(Why is one a "fall-thru" and the other isn't)

Robert's questions referred to fall-INTO. Given:

PERFORM para-a thru para-z

para-a.
...
para-b.
...
...
...
para-z.
...

and no gotos then each para- label between the start of para-a and the
end of para-z will be fallen into and fallen-thru until the end of
para-z cause a return to the statement after the perform.

Note: "fall" is always in a downward direction.

If you do consider
Perform Para1 thru Para2
to be fall-thru, I think you find that many (possibly most) COBOL
programmers
disagree with your use of the term.

But then most cobol programmers wouldn't misunderstand so badly what I
actually wrote.

Falling thru is when you
change paragraphs with no command telling it to do that.

Even with perform para-a thru para-a-exit

para-a
(no goto)
para-a-exit
exit.

there is _NO_ command to tell the code to change to para-a-exit, it
simply falls off the end of para-a and falls (downwards) into para-a-
exit, or into any intermediate, and falls-thru until it reaches the
end of para-a-exit.

The only case where this example code wouldn't fall-tru is if there
was an explicit go to para-a-exit at the end of para-a.

--
Bill Klein
wmklein <at> ix.netcom.com"Richard" <rip...@xxxxxxxxxxxx> wrote in
message

news:7d19d384-fefa-44dc-ab59-b0319919f08b@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Nov 6, 6:23 am, billg...@xxxxxxxxxxx (Bill Gunshannon) wrote:

In article <5lk3h4d55e67bsvkftdtfqps3dmvip3...@xxxxxxx>,
Robert <n...@xxxxxx> writes:

On Wed, 05 Nov 2008 10:59:19 -0500, SkippyPB
<swieg...@xxxxxxxxxxxxxxxxx>
wrote:

On 5 Nov 2008 12:31:42 GMT, billg...@xxxxxxxxxxx (Bill Gunshannon)
wrote:

In article <fj12h4pe2rhi2veb7ibgop6i4l319vd...@xxxxxxx>,
Robert <n...@xxxxxx> writes:
On Tue, 04 Nov 2008 12:10:49 -0500, SkippyPB
<swieg...@xxxxxxxxxxxxxxxxx>
wrote:

2b - do you ever fall through a PERFORMed label?

Nope.

3c - do you always, or sometimes, or never, use PERFORM ...THRU
i.e., as
opposed to just PERFORM?

I always use PERFORM THRU.

Then you should have answered yes for 2b. You are falling into
and
performing the -exit
paragraph.

He is not "falling into and performing the -exit paragraph.". He is
explicitly telling it to perform the -exit. Falling thru is when
you
change paragraphs with no command telling it to do that.

bill

Bingo! Cha Ching!!

How are you entering the -exit paragraph?
a. always go to
b. always fall into ("no command")
c. usually fall into, sometimes go to

d. none of the above

PERFORM COUNT-PARA THRU COUNT-EXIT.

COUNT-PARA.
ADD 1 TO COUNT.

COUNT-EXIT.
EXIT.

Both Paragraphs are explicitly mentioned. No GOTO. No Fall-thru.

You misunderstand what 'fall into', or fall thru, means.

The actual answer, based on your example, is b. always fall into.

That is, after the ADD 1 the next thing that happens is that the
program 'falls into' the Count-Exit paragraph.

As clarification for Bill: this explanation is of the actual code
sample above where there are no intermediate paragraphs. If there were
paragraphs between COUNT-PARA and COUNT-EXIT then it would fall-thru
those too.

In fact the PERFORM a THRU z specifies exactly that the program should
start at a and (fall) thru until the end of z.

Your answer appeared to be as if your PERFORM was

PERFORM COUNT-PARA
PERFORM COUNT-EXIT

which is a completely different beast.

.

Relevant Pages

  • Re: Bad habits of GOTO-using programmers
    ... of the specified scope of the PERFORM. ... If I PERFORM a SECTION with several paragraphs in it (provided I don't do ... it is arguable if paragraphs receiving control within that scope, ... PERFORM para-a thru para-z ...
    (comp.lang.cobol)
  • General Board Current Monitoring on Scope
    ... For an analysis that I am doing I am trying to capture on the scope ... voltage mode control. ... Using a current probe and a current loop near the inductor. ... the VRM and the scope that messes up my scope capture. ...
    (sci.electronics.design)
  • Re: The math algorithm behind cutter compensation G codes
    ... >>of a copy of Computer Numerical Control by Warren S. Seams or something ... >CNC systems engineering book. ... IF the programmer needs circular interpolation about ... and NOT something for the control to randomly guess at ...
    (alt.machines.cnc)
  • Re: Java in Browser
    ... Note the "programmer" in the group name. ... What I want is something as simple as dowloading a .exe file, have the installer say "do you want to run this yadda yadda" and zap - all done. ... Next thing they know is that it opens in their browser tab and controls the universe. ... There's a whole slew of devices that would benefit from a uniform control shell ie a browser to package what are now disparate programs. ...
    (comp.lang.java.programmer)
  • Re: $HASP308 message
    ... It's also a productivity issue. ... How can you control batch elapsed on a busy system? ... The theory is that if the programmer even suspects that the job might ... If the elapsed time is>120 minutes (which it ...
    (bit.listserv.ibm-main)