EXIT PARAGRAPH, PERFORM...THRU etc. (was: First COBOL compiler) 
Author Message
 EXIT PARAGRAPH, PERFORM...THRU etc. (was: First COBOL compiler)

An aside to this interesting debate is more of my folklore.

Programs in the 1950-60 period were written in machine, assembly, octal,
etc. As close to the machine as one could get was required because
coding tools of all kinds were very young. After half a decade of code
creation and documentation, nothing really existed to define
what the program did UNLESS you did something extra.  The tendency was
NOT to do the extra.

Bosses, being the same as they have always been were very frustrated
by the answers they got when they requested changes, and IT staff could
NOT shed any light on where, how, what, and when those changes could
occur.  Some of these bosses had come up through the unit record card
type systems, and had wired boards. Some asked to see the programs.
Guess what they were shown. As much as any other reason, COBOL was
and still is intended to help everyone KNOW what is going on including
the IT people. The fact that some of you have developed your own
preprocessors to enforce your own quality control seems to support the
need.

One more point. I prefer the use of ENGLISH rules. Not that I'm good
with them, but that it is easier to pick them apart. One of the very
nice improvements has been the introduction of the Evaluate statement.
It's ENGLISH, but easier to understand than nested IF statements, and in
similar to GO TO Depending on.  In ENGLISH new words are created all of
the time. However, seldom are they created in the form END-IF, etc.

Warren Simmons



Wed, 16 May 2001 03:00:00 GMT  
 EXIT PARAGRAPH, PERFORM...THRU etc. (was: First COBOL compiler)

Quote:
> A. Perform only single paragraphs. Do not use GO TO or sections.

...

Quote:
> The advocates of Style A are GO-TO-less programmers in the tradition of
> Dikstra and Hoare. The result is an easy-to-follow subroutine structure,
> but (IMHO) often awkward structures within subroutines. The
> EXIT-procedure statement will help, but an EXIT-structure statement
> would be better.

Or sometimes we are programmers who have seen maintenance done where
maintenance programmers put paragraphs places where they get performed
accidentally.  It isn't GO TO which bothers me, it is dropping into
paragraphs accidentally which causes trouble.  So I like to avoid
dropping into paragraphs at all.


Fri, 18 May 2001 03:00:00 GMT  
 EXIT PARAGRAPH, PERFORM...THRU etc. (was: First COBOL compiler)

Quote:
> In the absence of GO TO, I can look at a paragraph in isolation,
> knowing that it will always return control to whoever PERFORMed it.
> In the presence of GO TO I can't be sure.  When PERFORMed it returns
> control to the PERFORMer; otherwise it falls into the next paragraph.
> I can't look at a paragraph in isolation -- I must look at all the
> code which invokes it, and at the paragraph following it.

Or even worse, the paragraph never was PERFORMed, but ran because the
statement above finished and dropped down to that paragraph.

Always make it easy for entry level maintenance programmers to add a
paragraph without screwing up!



Fri, 18 May 2001 03:00:00 GMT  
 EXIT PARAGRAPH, PERFORM...THRU etc. (was: First COBOL compiler)

Quote:

> > In the absence of GO TO, I can look at a paragraph in isolation,
> > knowing that it will always return control to whoever PERFORMed it.
> > In the presence of GO TO I can't be sure.  When PERFORMed it returns
> > control to the PERFORMer; otherwise it falls into the next paragraph.
> > I can't look at a paragraph in isolation -- I must look at all the
> > code which invokes it, and at the paragraph following it.

> Or even worse, the paragraph never was PERFORMed, but ran because the
> statement above finished and dropped down to that paragraph.

> Always make it easy for entry level maintenance programmers to add a
> paragraph without screwing up!

Very true -- my summary was an oversimplification.  In order for
paragraphs to be understandable in isolation, it is not enough that
there be no GO TO.  There must also be no PERFORM THRU, and the first
paragraph must exit the program (directly or indirectly) before falling
into the next one.  If there are multiple entry points, the last
condition applies to each entry point.

The first two conditions, if true, can be quickly verified in any
reasonable editor.  The third may take a little longer, but usually
doesn't.

If these conditions are NOT true, then it can be a long, tedious,
and error prone exercise to reliably identify all the fall-through
code.  We skip this analysis at our peril.


http://home.swbell.net/mck9/cobol/cobol.html



Fri, 18 May 2001 03:00:00 GMT  
 EXIT PARAGRAPH, PERFORM...THRU etc. (was: First COBOL compiler)

Quote:

>Very true -- my summary was an oversimplification.  In order for
>paragraphs to be understandable in isolation, it is not enough that
>there be no GO TO.  There must also be no PERFORM THRU, ... [snip]

I must protest! :-)  After some 20+ years of managing and teaching new
and experienced programmers, I can tell you that there is *no* problem
with newbies understanding and using PERFORM/THRU, as long as every
paragraph is paired with exactly one EXIT paragraph, and you never,
ever, never GO TO out of a paragraph (that's a firing offense with me).
Some programmers here don't like it for various reasons, but I have
never seen a single problem with a programmer misunderstanding it, or
finding it difficult to modify. :-)  Yes, without an automated checker
it presents opportunities for the PERFORM and THRU paragraphs to be
mismatched, but that is a keying problem, not an understanding problem.
--

Sun Valley Systems    http://personal.bhm.bellsouth.net/~judmc
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."


Sat, 19 May 2001 03:00:00 GMT  
 EXIT PARAGRAPH, PERFORM...THRU etc. (was: First COBOL compiler)

Quote:


> >Very true -- my summary was an oversimplification.  In order for
> >paragraphs to be understandable in isolation, it is not enough that
> >there be no GO TO.  There must also be no PERFORM THRU, ... [snip]

> I must protest! :-)  After some 20+ years of managing and teaching new
> and experienced programmers, I can tell you that there is *no* problem
> with newbies understanding and using PERFORM/THRU, as long as every
> paragraph is paired with exactly one EXIT paragraph, and you never,
> ever, never GO TO out of a paragraph (that's a firing offense with me).
> Some programmers here don't like it for various reasons, but I have
> never seen a single problem with a programmer misunderstanding it, or
> finding it difficult to modify. :-)  Yes, without an automated checker
> it presents opportunities for the PERFORM and THRU paragraphs to be
> mismatched, but that is a keying problem, not an understanding problem.

The key here is my use of the phrase "in isolation".

Even with a disciplined THRU...EXIT style, you can't understand a
paragraph in isolation, in a formal sense.  You can only understand
a real paragraph together with its matching EXIT paragraph.  You
have to understand, and either assume or confirm, that the target of
the GO TO is a trivial EXIT paragraph which does nothing substantive.

Any use of PERFORM THRU, by definition, involves fall-through logic,
even if it is of a trivial sort.  Whether such a style is desirable
is a different issue.  It remains true that in the presence of
fall-through logic you can't understand the program without
recognizing the fall-throughs, whether the recognition is performed
by a code checker or by your eyeballs.


http://home.swbell.net/mck9/cobol/cobol.html



Sat, 19 May 2001 03:00:00 GMT  
 EXIT PARAGRAPH, PERFORM...THRU etc. (was: First COBOL compiler)

Quote:


>>Very true -- my summary was an oversimplification.  In order for
>>paragraphs to be understandable in isolation, it is not enough that
>>there be no GO TO.  There must also be no PERFORM THRU, ... [snip]

>I must protest! :-)  After some 20+ years of managing and teaching new
>and experienced programmers, I can tell you that there is *no* problem
>with newbies understanding and using PERFORM/THRU, as long as every
>paragraph is paired with exactly one EXIT paragraph, and you never,
>ever, never GO TO out of a paragraph (that's a firing offense with me).
>Some programmers here don't like it for various reasons, but I have
>never seen a single problem with a programmer misunderstanding it, or
>finding it difficult to modify. :-)

Well, all good arguments get re-hashed every so often... and this argument
does, too.  Mr McClendon, I disagree with you on One Small Point; consider
the following:

 PROCEDURE DIVISION.
*
     PERFORM A100-HOUSEKEEPING THRU A100-EX.
     PERFORM M500-MAINLINE     THRU M500-EX
      UNTIL CONDITION-TO-END-PROCESSING.
     PERFORM Z900-EOJ          THRU Z900-EX.
     GOBACK.
*
 A100-HOUSEKEEPING.
*
     OPEN INPUT INFILE.
     IF NOT GOOD-INFILE-IO
         MOVE ' A100-HOUSEKEEPING '  TO WS-ABEND-PARA
         MOVE ' OPEN ERROR        '  TO WS-ABEND-REASON
         MOVE ' INFILE            '  TO WS-ABEND FILNAM
         MOVE INFILSTAT              TO WS-ABEND-FILSTAT
         GO TO Z999-ALL-FALL-DOWN.

...

 Z999-ALL-FALL-DOWN.
*
     ACCEPT WS-ABEND-DATE   FROM DATE.
     ACCEPT WS-ABEND-TIME   FROM TIME.
     CALL ABEND-LOGGING-PGM USING WS-ABEND-AREA.
     DISPLAY ' ', WS-ABEND-AREA-LINE01.
     DISPLAY ' ', WS-ABEND-AREA-LINE02.
...
     GOBACK.

... and notice two things:

1) It is, one should hope, *eminently* readable code (not *strictly*
Y2K-compliant but Life is Tough); if one of the less-senior readers here
would like to point out ambiguities and/or difficulties then I would
appreciated being made aware of them.

2) It has not one but *two* 'firing offenses':  The GO TO outside a
paragraph's label or -EXIT paragraph *and* a second point of program exit
as well... two GOBACKs.

Yes, Mr McClendon, in general I would agree with your arguments BUT... I
find that a structure such as this reinforces the rule *precisely* because
it breaks it.

DD



Sat, 19 May 2001 03:00:00 GMT  
 EXIT PARAGRAPH, PERFORM...THRU etc. (was: First COBOL compiler)
I agree that it makes sense to GO TO ABORT-ROUTINE.  Some people PERFORM
ABORT-ROUTINE, but this is a silly fiction which everybody knows is a
lie.
Quote:
> >with newbies understanding and using PERFORM/THRU, as long as every
> >paragraph is paired with exactly one EXIT paragraph, and you never,
> >ever, never GO TO out of a paragraph (that's a firing offense with me).
> >Some programmers here don't like it for various reasons, but I have
> >never seen a single problem with a programmer misunderstanding it, or
> >finding it difficult to modify. :-)

> Well, all good arguments get re-hashed every so often... and this argument
> does, too.  Mr McClendon, I disagree with you on One Small Point; consider
> the following:

>  PROCEDURE DIVISION.
> *
>      PERFORM A100-HOUSEKEEPING THRU A100-EX.
>      PERFORM M500-MAINLINE     THRU M500-EX
>       UNTIL CONDITION-TO-END-PROCESSING.
>      PERFORM Z900-EOJ          THRU Z900-EX.
>      GOBACK.
> *
>  A100-HOUSEKEEPING.
> *
>      OPEN INPUT INFILE.
>      IF NOT GOOD-INFILE-IO
>          MOVE ' A100-HOUSEKEEPING '  TO WS-ABEND-PARA
>          MOVE ' OPEN ERROR        '  TO WS-ABEND-REASON
>          MOVE ' INFILE            '  TO WS-ABEND FILNAM
>          MOVE INFILSTAT              TO WS-ABEND-FILSTAT
>          GO TO Z999-ALL-FALL-DOWN.

> ...

>  Z999-ALL-FALL-DOWN.
> *
>      ACCEPT WS-ABEND-DATE   FROM DATE.
>      ACCEPT WS-ABEND-TIME   FROM TIME.
>      CALL ABEND-LOGGING-PGM USING WS-ABEND-AREA.
>      DISPLAY ' ', WS-ABEND-AREA-LINE01.
>      DISPLAY ' ', WS-ABEND-AREA-LINE02.
> ...
>      GOBACK.

> ... and notice two things:

> 1) It is, one should hope, *eminently* readable code (not *strictly*
> Y2K-compliant but Life is Tough); if one of the less-senior readers here
> would like to point out ambiguities and/or difficulties then I would
> appreciated being made aware of them.

> 2) It has not one but *two* 'firing offenses':  The GO TO outside a
> paragraph's label or -EXIT paragraph *and* a second point of program exit
> as well... two GOBACKs.

> Yes, Mr McClendon, in general I would agree with your arguments BUT... I
> find that a structure such as this reinforces the rule *precisely* because
> it breaks it.

> DD



Sat, 19 May 2001 03:00:00 GMT  
 EXIT PARAGRAPH, PERFORM...THRU etc. (was: First COBOL compiler)


Quote:
> I agree that it makes sense to GO TO ABORT-ROUTINE.  Some people PERFORM
> ABORT-ROUTINE, but this is a silly fiction which everybody knows is a
> lie.

I'm guilty of that --- but here' s my reasoning.

Sometimes you just HAVE to ABEND.  I PERFORM the ABEND routine.  Why?
If I GO TO it, it defeats the optimization (the compiler WILL NOT
optimize the program) and I lose runtime speed.  Using perform
accomplishes two things - I get optimization (CALL directive with
Realia), and I get rid of the GO TO <G>.



Sun, 20 May 2001 03:00:00 GMT  
 EXIT PARAGRAPH, PERFORM...THRU etc. (was: First COBOL compiler)

On 1 Dec 1998 15:23:29 GMT
posted a  pocedure that takes an exit stage left when a severe error is
encountered, which looks like this after heavy snipping
<<
...
A100-HOUSEKEEPING.
     OPEN INPUT INFILE.
     IF NOT GOOD-INFILE-IO
         ...
         GO TO Z999-ALL-FALL-DOWN.
...
the target procedure Z999-ALL-FALL-DOWN is outside of the PERFORM THRU range.
And the discussion that has followed is interesting. I would like to offer a
term for this topic, and have pirated the subject paradigmatically.

I suggest that we call this coding technique an 'Ersatz EXIT'. This is in fact
one of the most proven valid exceptions to the 'no goto out of' rule.

But notice that I do not recommend that we call it 'Ersatz GOTO'. I would not
recommend that we encourage people to use flow disruptive GOTOs in COBOL. But
as one postor commented, sometimes you HAVE TO abend.

The technique of GOING to an abend paragraph is very, very, very common. It is
a pedagogical error, I emphasize ERROR, to teach it not.

Furthermore, this ubiquitous coding technique, is exactly analogous to the use
of procedure vector table devices, such as CICS HANDLE CONDITION. A device that
many people depend on heavily.

COBOLers are not dumb. They are perfectly capable of understanding a procedur
vector table and an asynchronous engagement of it.  COBOLers ar perfectly
capable of understanding GO TO ABEND, that ain't rocket science.

But my notion would be to teach this as an EXIT technique.  Someday we could
enforce it with syntax in the compiler.  Rather than GOTO we should EXIT TO
Z999-ALL-FALL-DOWN.  Such syntax would be slightly more clear, but more
importantly the compiler could verify that that Z999- procedure contains
certain death, or your code fails compilation.

The need for Ersatz EXITs is clear, it is large, and there is no holding it
back, no matter what theory we profess. The code is out there and it works
quite well. But there are actually cases where you can get into trouble with
this.  Abend paragraphs don't always abend, for example.

I have seen CICS programs that had Ersatz EXITs, that worked for a while. There
were the GOTOs, and the paragraph actually abended in the begining.  But then
some one modified it to take a snap dump and return. The code went to
production.  The coding weakness was not recognized in test because the ideal
data conditions never triggered the Ersatz EXIT.  One night it happened, and
then the code blithely dropped into the next paragraph, and then the next.

The problem was that several of the fallen through paragraphs actually
functioned leaving many confusing side effects.  It was a bear to decipher.

So in the absence of compiler support for validation of the
certainty of the abend, Ersatz EXITs _are_ dangerous, and you could see how
structured programming adherents would rail against them.  But they are
efficient devices, as measured in programmer time.

I find Thane Hubbell comments on the possible use of PERFORM instead of GOTO in
these cases somewhat profoundly insightful:


Date: 2 Dec 98 00:15:27 GMT
L

<<
I'm guilty of that --- but here' s my reasoning.

Sometimes you just HAVE to ABEND.  I PERFORM the ABEND routine.  Why?
If I GO TO it, it defeats the optimization (the compiler WILL NOT
optimize the program) and I lose runtime speed.  Using perform
accomplishes two things - I get optimization (CALL directive with
Realia), and I get rid of the GO TO <G>.

Hope we can hear from other knowledgable folks about the other compilers and
the impact of the presence of GOTOs on the overall behaviour and quality of the
optimizer. As well as comments on the difficulty that the need to ABEND causes.

What is very hard to say in a few words is that if you do not have Ersatz
EXITs, then your top level structure becomes greatly burdened with artificial
material.  In a certain sense I advocate that, and I am close to Judson
McClendon view (except I don't like THRU and its retinue of wimpy GOTOs).

I have dealt with code that really does switch back and forth between PERFORM
and GOTO invocations of some paragraph sequences. It can be quite difficult to
modify it reliably, especially when adding procedures.

But truth is I have learned to be accepting of the Ersatz EXITs. Even in the
midst of code that is mangled, the Ersatz EXITs are not frequently a source of
problems.

Part of what we are dealing with is that a number of programs are not planned
well.  You really need a very good map ahead of time to get procedures
organized according to I/O status codes and severe exception conditions.  I am
not advocating inadequate planning, but I know that it is there frequently.

We frequently hand major programming responsibilities to individuals that do
not know how many exceptions can occur.  And we also make major revisions to
programs. The biggest source of difficulty here is a new file to be accessed in
the middle of a structure that was originally smooth.  A person is usually not
given permission to reorganize the program, they are just told to
open/read/close, "get it done, you don't have much time."

"What if, what if, what if," they will protest. And we frequently tell them,
don't worry, just GOTO the abend routine with a few identifying flags set.

Naturally there are many ways it can happen. But the field experience is that
in a very large set of cases the Ersatz EXIT in the form of a GOTO a reliable
abender, is valid when we do it at the surface level in source code or when we
allow engagement of error handling procedure vectors by default within major
support packages from vendors.

The stuff works, and I think we should teach it without condemnation so that we
might more successfully limit it.

Best Wishes,

Robert Rayhawk



Sun, 20 May 2001 03:00:00 GMT  
 EXIT PARAGRAPH, PERFORM...THRU etc. (was: First COBOL compiler)

Quote:



>> >Very true -- my summary was an oversimplification.  In order for
>> >paragraphs to be understandable in isolation, it is not enough that
>> >there be no GO TO.  There must also be no PERFORM THRU, ... [snip]

>> I must protest! :-)  After some 20+ years of managing and teaching new
>> and experienced programmers, I can tell you that there is *no* problem
>> with newbies understanding and using PERFORM/THRU, as long as every
>> paragraph is paired with exactly one EXIT paragraph, and you never,
>> ever, never GO TO out of a paragraph (that's a firing offense with me).
>> Some programmers here don't like it for various reasons, but I have
>> never seen a single problem with a programmer misunderstanding it, or
>> finding it difficult to modify. :-)  Yes, without an automated checker
>> it presents opportunities for the PERFORM and THRU paragraphs to be
>> mismatched, but that is a keying problem, not an understanding problem.

>The key here is my use of the phrase "in isolation".

>Even with a disciplined THRU...EXIT style, you can't understand a
>paragraph in isolation, in a formal sense.  You can only understand
>a real paragraph together with its matching EXIT paragraph.  You
>have to understand, and either assume or confirm, that the target of
>the GO TO is a trivial EXIT paragraph which does nothing substantive.

From a strictly narrow theoretical sense, perhaps.  But that is
stretching the point a bit, don't you think?  In practice, nobody is
going to be examining a single paragraph entirely absent from any
program context, particularly a PERFORM/THRU paragraph without the
matching exit. :-)

Quote:
>Any use of PERFORM THRU, by definition, involves fall-through logic,
>even if it is of a trivial sort.  Whether such a style is desirable
>is a different issue.  It remains true that in the presence of
>fall-through logic you can't understand the program without
>recognizing the fall-throughs, whether the recognition is performed
>by a code checker or by your eyeballs.

But when the style is specifically to code all paragraphs such that
every paragraph has exactly one EXIT paragraph, there is no real
'fall through' logic, because the EXIT paragraph is exactly that,
an exit point.  It is precisely as understandable as a paragraph
with no EXIT, because the paragraph and exit are one entity.  When
a programmer sees:

PROCEDURE DIVISION.

000000-CONTROL.
    PERFORM 000100-INITIALIZE
       THRU 000100-EXIT.
    PERFORM 000200-PROCESS
       THRU 000200-EXIT
        UNTIL (WS-END-FLAG = 1).
    PERFORM 000300-TERMINATE
       THRU 000300-EXIT.
000000-EXIT.
    STOP RUN.

000100-INITIALIZE.
    ...
000100-EXIT.
    EXIT.

000200-PROCESS.
    ...
000200-EXIT.
    EXIT.

000300-TERMINATE.
    ...
000300-EXIT.
    EXIT.

And every single paragraph in the program has the same pattern: a
paragraph always with one exact same numbered -EXIT, there is no
ambiguity.  Considerations of whether it is a good practice for
other reasons aside, even someone totally unfamiliar with the
practice would recognize that pattern in a program after only a
few seconds inspection.  Just the fact that every single PERFORM
was matched with a THRU -EXIT would tell anyone with even an ounce
of analytical ability that there were no GO TO's outside the
paragraph/exit. :-)
--

Sun Valley Systems    http://personal.bhm.bellsouth.net/~judmc
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."



Sun, 20 May 2001 03:00:00 GMT  
 EXIT PARAGRAPH, PERFORM...THRU etc. (was: First COBOL compiler)

Quote:


>> I agree that it makes sense to GO TO ABORT-ROUTINE.  Some people PERFORM
>> ABORT-ROUTINE, but this is a silly fiction which everybody knows is a
>> lie.

>I'm guilty of that --- but here' s my reasoning.

>Sometimes you just HAVE to ABEND.  I PERFORM the ABEND routine.  Why?
>If I GO TO it, it defeats the optimization (the compiler WILL NOT
>optimize the program) and I lose runtime speed.  Using perform
>accomplishes two things - I get optimization (CALL directive with
>Realia), and I get rid of the GO TO <G>.

Not only that, but on machines where PERFORMS are stack CALLs, it gives
a clear trail of where the PERFORM came from in a dump by examining the
stack.  By all means, use PERFORM. :-)
--

Sun Valley Systems    http://personal.bhm.bellsouth.net/~judmc
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."


Sun, 20 May 2001 03:00:00 GMT  
 EXIT PARAGRAPH, PERFORM...THRU etc. (was: First COBOL compiler)

Quote:


>>I must protest! :-)  After some 20+ years of managing and teaching new
>>and experienced programmers, I can tell you that there is *no* problem
>>with newbies understanding and using PERFORM/THRU, as long as every
>>paragraph is paired with exactly one EXIT paragraph, and you never,
>>ever, never GO TO out of a paragraph (that's a firing offense with me).
>>Some programmers here don't like it for various reasons, but I have
>>never seen a single problem with a programmer misunderstanding it, or
>>finding it difficult to modify. :-)

>Well, all good arguments get re-hashed every so often... and this argument
>does, too.  Mr McClendon, I disagree with you on One Small Point; consider
>the following:

> PROCEDURE DIVISION.
>*
>     PERFORM A100-HOUSEKEEPING THRU A100-EX.
>     PERFORM M500-MAINLINE     THRU M500-EX
>      UNTIL CONDITION-TO-END-PROCESSING.
>     PERFORM Z900-EOJ          THRU Z900-EX.
>     GOBACK.
>*
> A100-HOUSEKEEPING.
>*
>     OPEN INPUT INFILE.
>     IF NOT GOOD-INFILE-IO
>         MOVE ' A100-HOUSEKEEPING '  TO WS-ABEND-PARA
>         MOVE ' OPEN ERROR        '  TO WS-ABEND-REASON
>         MOVE ' INFILE            '  TO WS-ABEND FILNAM
>         MOVE INFILSTAT              TO WS-ABEND-FILSTAT
>         GO TO Z999-ALL-FALL-DOWN.

>...

> Z999-ALL-FALL-DOWN.
>*
>     ACCEPT WS-ABEND-DATE   FROM DATE.
>     ACCEPT WS-ABEND-TIME   FROM TIME.
>     CALL ABEND-LOGGING-PGM USING WS-ABEND-AREA.
>     DISPLAY ' ', WS-ABEND-AREA-LINE01.
>     DISPLAY ' ', WS-ABEND-AREA-LINE02.
>...
>     GOBACK.

>... and notice two things:

>1) It is, one should hope, *eminently* readable code (not *strictly*
>Y2K-compliant but Life is Tough); if one of the less-senior readers here
>would like to point out ambiguities and/or difficulties then I would
>appreciated being made aware of them.

>2) It has not one but *two* 'firing offenses':  The GO TO outside a
>paragraph's label or -EXIT paragraph *and* a second point of program exit
>as well... two GOBACKs.

>Yes, Mr McClendon, in general I would agree with your arguments BUT... I
>find that a structure such as this reinforces the rule *precisely* because
>it breaks it.

Well, my protest was toward Michael's comments about PERFORM/THRU having
a negative effect on understanding the logic.  But could not paragraph
Z999-ALL-FALL-DOWN have been performed just as easily as using GO TO? :-)
--

Sun Valley Systems    http://personal.bhm.bellsouth.net/~judmc
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."


Sun, 20 May 2001 03:00:00 GMT  
 
 [ 427 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software