interesting use of NEXT SENTENCE vs. CONTINUE

With all the discussion of the differences between NEXT SENTENCE and
CONTINUE over the years I've been reading comp.lang.cobol I just could not
resist sharing with you some actual production code:

*     ****************************************
*********************
*    * PRODUCE EXCEPTION FOR ACCOUNTS THAT HAVE NOT HAD ANY    ***
*    * TRANSACTIONS, NO CASH RESERVE AND HAVE BEEN OPEN AT     ***
*    * LEAST SEVEN DAYS                                        ***
*     ****************************************
*********************
IF CURR-BAL = ZERO
AND DATE-LAST-TXN = ZERO
AND DATE-LAST-STMT = ZERO
AND DATE-OPEN < DATE-6-DAYS-AGO
AND NOT-IN-SWEEP-GRP
AND NOT MSTR-CLOSING-ACCT-OD
AND NOT MSTR-CHARGE-OFF-ACCT
AND NOT MSTR-OLD-CHG-OFF-ACCT
AND NOT MSTR-INTERNAL-BANK
AND RSRV-CURR-BAL = ZERO
AND RSRV-LIMIT = ZERO
AND NO-D13-GENERAL-MEMO
*     ****************************************
*********************
IF VPAY-CARD-SVC
IF DATE-OPEN < DATE-40-DAYS-AGO
CONTINUE
ELSE
NEXT SENTENCE
END-IF
END-IF
*     ****************************************
*********************
MOVE 'M'                TO REPORT-CODE
MOVE +058 TO REPORT-RSN
PERFORM 6200-EXCEPT-OUTPUT THRU
6200-EXCEPT-OUTPUT-EXIT
MOVE 'C'                MSTR-CODE-OVERDRAFT
GO TO PROCESS-LARGE-BAL-CHANGE.

The "interesting" code is between the last to lines of all asterisks.  It
was obviously added in after the original code, and was obviously done in
order to avoid adding a new GO TO such as:

IF VPAY-CARD-SVC
IF DATE-OPEN < DATE-40-DAYS-AGO
CONTINUE
ELSE
GO TO XXX-CONTINUE
END-IF
END-IF


Where XXX-CONTINUE is a label following the GO TO on the last line above.
But how someone thought this was actually a good idea is beyond me!  I
believe he could if just added another AND condition as follows:

AND (NOT VPAY-CARD-SVC OR DATE-OPEN <  DATE-40-DAYS-AGO)

(Basically, for VPAY card accounts this exception is generated after 41 days
instead of the 7 day period for all other account SVC types.)

Actually, now that I look at it that is somewhat hard to understand, so I
guess I can see why he chose a separate IF statement.  But the CONTINUE vs.
NEXT SENTENCE thing is just nutty.

Anyway, just found it amusing that someone thought it was clever to use NEXT
SENTENCE in this way.

Frank


---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO  USA

On  2-Jun-2005, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:

>          IF VPAY-CARD-SVC
>              IF DATE-OPEN < DATE-40-DAYS-AGO
>                  CONTINUE
>              ELSE
>                  NEXT SENTENCE
>              END-IF
>          END-IF

I have to say that if he's going to do that, it is far better that he includ
es
both the CONTINUE and the NEXT SENTENCE than if he restructured it so that t
he
CONTINUE was not needed.    At least this way a maintainer will stop and say
"huh?", and then figure out what was actually intended instead of making
assumptions.     But he should have included a commented out goto for a bit 
more
explanation.

Frank Swarbrick wrote:
> *     ****************************************
*********************
>          IF VPAY-CARD-SVC
>              IF DATE-OPEN < DATE-40-DAYS-AGO
>                  CONTINUE
>              ELSE
>                  NEXT SENTENCE
>              END-IF
>          END-IF
> *     ****************************************
*********************

This code is illegal under the '85 standard:

"""If the END-IF phrase is specified, the NEXT SENTENCE phrase must not
be specified."""

> The "interesting" code is between the last to lines of all asterisks.  It
> was obviously added in after the original code, and was obviously done in
> order to avoid adding a new GO TO such as:

There is no need at all to add any GO TO.

> Anyway, just found it amusing that someone thought it was clever to use NE
XT
> SENTENCE in this way.

There was a long discussion here many years ago where someone supported
the contrivence of using NEXT SENTENCE buried in a non-imperitive IF as
a way around the rules.

The problem with NEXT SENTENCE, when combined with scope terminators,
is that it can be thought of a GO TO to an anonymous label formed by
the very next full stop.  There is no indication at that point that the
full stop is the target of a logic path, nor, more importantly, that an
inserted full stop would become a new target of the path.

In other words it is a bug trap.

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1117739584.053909.178940@g44g2000cwa.googlegroups.com...

> The problem with NEXT SENTENCE, when combined with scope terminators,
> is that it can be thought of a GO TO to an anonymous label formed by
> the very next full stop.

Actually, I think it's worse than that.  The most common problem with NEXT
SENTENCE in '85-and-later editions of COBOL is that it's erroneously thought
of as a GO TO to the next STATEMENT -- in the case of a delimited-scope
statement, to a point immediately after the ending scope delimiter --
basically synonymous with CONTINUE.

NEXT SENTENCE, where it is allowed, *does* transfer control to the statement
immediately following the next "separator period".   The problem is the
erroneous presumption that that's *not* where it's supposed to transfer
control.

This was a serious enough problem of misperception to warrant a mention in
the '02 standard (ISO/IEC 1989:2002 page 833) and the marking of NEXT
SENTENCE as an archaic element in standard COBOL therein.

-Chuck Stevens

Frank Swarbrick wrote:
> With all the discussion of the differences between NEXT SENTENCE and
> CONTINUE over the years I've been reading comp.lang.cobol I just
> could not resist sharing with you some actual production code:

[...]

> Actually, now that I look at it that is somewhat hard to understand,
> so I guess I can see why he chose a separate IF statement.  But the
> CONTINUE vs. NEXT SENTENCE thing is just nutty.
>
> Anyway, just found it amusing that someone thought it was clever to
> use NEXT SENTENCE in this way.
>

When asked whether he thought his career was due to luck, Ozzie Ozborne
replied "Well I sure as shit ain't clever!"

God save us from clever people.

In article <1117739584.053909.178940@g44g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:

[snip]

>The problem with NEXT SENTENCE, when combined with scope terminators,
>is that it can be thought of a GO TO to an anonymous label formed by
>the very next full stop.

That it can be thought of in this manner, Mr Plinston, does not change the
fact that all NEXT SENTENCE does is cause execution to be resumed after
the next period/full stop (paragraph control aside).

>There is no indication at that point that the
>full stop is the target of a logic path, nor, more importantly, that an
>inserted full stop would become a new target of the path.

Eh?  The NEXT SENTENCE is the indication, at that point, that the
period/full stop is the target... what else does NEXT SENTENCE accomplish?
As was posted previously, in
<http://groups-beta.google.com/group... />
urce&hl=en>

--begin quoted text:

As I was taught, lo, those many years ago: COBOL tries to be
'English-like'.  A statement in English (usually) ends with a period/full
stop.  NEXT SENTENCE, then, means 'skip everything between here and the
next period and start up again after it (paragraph control aside)'.

But, as noted, this is how it was taught years ago... in the Oldene Dayse,
when an instructor could instruct in COBOL such as *ten* instructors
cannot, today!

--end quoted text

DD

Richard<riplin@Azonic.co.nz> 6/2/2005 1:13:04 PM >>>
>Frank Swarbrick wrote: 
>
>This code is illegal under the '85 standard:
>
>"""If the END-IF phrase is specified, the NEXT SENTENCE phrase must not
>be specified."""

True enough, but it's an "extention" allowed by IBM COBOL for VSE/ESA (and
other compilers, I'm sure).  From my reference manual:
" Note:   END-IF can be specified with NEXT SENTENCE as an IBM extension."

Not that I think it's a good idea.  I don't.
 
It 
in 
>
>There is no need at all to add any GO TO.

Please clarify.  Of course I did show an example of how the entire
conditional could be modified to avoid GO TO, but I'm not sure what other
GOTO-less solution that you are referring to.
 
NEXT 
>
>There was a long discussion here many years ago where someone supported
>the contrivence of using NEXT SENTENCE buried in a non-imperitive IF as
>a way around the rules.
>
>The problem with NEXT SENTENCE, when combined with scope terminators,
>is that it can be thought of a GO TO to an anonymous label formed by
>the very next full stop.  There is no indication at that point that the
>full stop is the target of a logic path, nor, more importantly, that an
>inserted full stop would become a new target of the path.
>
>In other words it is a bug trap.

I am in no way advocating it's usage.  I was just giving an example of
someone actually using it.

Frank


---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO  USA

In article <1117765632.634020.104870@g49g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>docdwarf@panix.com wrote:
> 
> 
>
>If you follow the usual rules of english you should find that 'that
>point' refers to 'the very next full stop'.

Given the original construct of:

--begin quoted text:

The problem with NEXT SENTENCE, when combined with scope terminators,
is that it can be thought of a GO TO to an anonymous label formed by
the very next full stop.  There is no indication at that point that the
full stop is the target of a logic path, nor, more importantly, that an
inserted full stop would become a new target of the path.

--end quoted text

... it appears the phrase 'at that point' can have the preceding 'NEXT
SENTENCE' as its subject.  Consider:

The problem with putting your shoes on is that it can be thought of as a
decision based in insufficient dara regarding the day's activities.  There
is no indication at that point whether one will wind up doing (x), (y) or
(z).

But thanks for the clarification.

>
>When looking at a section of code that has a full stop in it there is
>no indication that this full stop is the target of a NEXT SENTENCE that
>is buried in the code at some point above this.

When you are looking at a paragraph there is no indication that the label
is the target of fall-through code, a PERFORM, a GO TO or a GO TO
DEPENDING ON; zealous advocating of these constructs has been called a
source for 'religious wars'.

My apologies if I have trodden unknowingly on your faith... but I,
personally, believe that code is to be read in context; I would say that
trying to fix code that is not read in context is more of a bug-trap than
any NEXT SENTENCE construction with which I am familiar... but I am, of
course, a man of limited experience.

>
>The only way to resolve how the logic works is to search the whole
>program, or at least all the program above the code you are examining.

See above about context.

>
>If an additional full-stop had been inserted in the code between 'that
>point' and the NEXT SENTENCE above it then there is no mechanism to
>resolve if this was an accidental change in logic or a deliberate one.

There is no mechanism of which I am aware that insures accurate repairs in
fractionally-understood code... or in completely-understood code, for that
matter.

DD

 

Am 02.06.05, 16:24:00, schrieb "Frank Swarbrick"=20
<Frank.Swarbrick@efirstbank.com> zum Thema interesting use of NEXT=20
SENTENCE vs. CONTINUE:

<snip>

> *     ****************************************
*********************
>          IF VPAY-CARD-SVC
>              IF DATE-OPEN < DATE-40-DAYS-AGO
>                  CONTINUE
>              ELSE
>                  NEXT SENTENCE
>              END-IF
>          END-IF
> *     ****************************************
*********************
>          MOVE 'M'                TO REPORT-CODE
>          MOVE +058 TO REPORT-RSN
>          PERFORM 6200-EXCEPT-OUTPUT THRU
>                  6200-EXCEPT-OUTPUT-EXIT
>          MOVE 'C'                MSTR-CODE-OVERDRAFT
>          GO TO PROCESS-LARGE-BAL-CHANGE.

<snip too>

Hello Frank

this is very tricky and expensive code - its FORBIDDEN - you found it=20=

and that is a good way to become good code.

Why forbidden: if you change the 'point' you can get an other=20
solution. So you must establish some instance, to get right code. It=20=

is garbage :-) Another hint is, you can not change the code before you=20=

think more than one time. It is destructive for a 'comercial rigth'=20
software development.

Oh oh if i can pronounce it in german :-( it come some times better

sowas ist absolute schei.... Nicht nur dass es Geld kostet. Es GEHOERT=20=

verboten!!!!


Einen schoenen Tag
Andreas Lerch

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:3gb7otFbeumaU1@individual.net...

> What about "AND DATE-OPEN NOT >= DATE-7-DAYS AGO".
> Nah, still confusing.

Also not standard COBOL.  ISO/IEC 1989:2002 (which is the standard in which
">=" and "<=" were introduced as relational operators) expressly prohibits
"NOT" before them.  ">=" is syntactically synonymous with "GREATER THAN OR
EQUAL TO" which is in turn logically synonymous with "NOT LESS THAN", and
"NOT NOT LESS THAN" is likewise prohibited.

The rules and syntax diagrams are clarified some in the proposed draft
standard (as part of the addition of "<>" as synonymous with "NOT =" and
"NOT EQUAL TO") by moving the "NOT <relational-operator>" combinations from
the "simple-relational-operator" category to the
"extended-relational-operator" category; NOT is precluded before the latter.

-Chuck Stevens