Cobol - Avoiding Logic Error?

Author

Avoiding Logic Error?

William Bub

2004-05-13, 11:30 pm

I just made the same coding error I made about two years age. I coded
something like the following:
PROCESS-PARAG.
IF REC-TYPE = 1
PERFORM EDIT-REC
IF EDIT-ERR = 'Y'
PERFORM HANDLE-ERROR
END-IF
PERFORM MORESTUFF

James J. Gavan

2004-05-14, 12:30 am

William Bub wrote:

>I just made the same coding error I made about two years age. I coded
>something like the following:
>PROCESS-PARAG.
> IF REC-TYPE = 1
> PERFORM EDIT-REC
> IF EDIT-ERR = 'Y'
> PERFORM HANDLE-ERROR
> END-IF
> PERFORM MORESTUFF
> .
>Every time REC-TYPE is not 1, MORESTUFF is not executed, even if EDIT-ERR is
>not Y. Of course, I now see that I need a second END-IF after PERFORM
>HANDLE-ERROR. Does anyone know of a compiler option which will warn if IF is
>not terminated by END-IF? Are there any utilities which will scan for this
>condition? Does anyone know a coding style which would make this type of
>error more difficult to make? Note: this is IBM mainframe.
>
>
>
>
>
I wont guarantee it happens all the time, but Micro Focus Net Express
*does* pick up on non-matching pairs - but not certain if it would
always pick up on above. It's a question of style, but like a neatly
typed CV, layout is IMPORTANT.
An early VISUAL warning signal would be to indent so that you see pairs :-

PROCESS-PARAG.

if Rec-Type = 1
perform EDIT-REC

If Edit-Err = 'Y'
perform HANDLE-ERROR
End-if

End-if

perform MORESTUFF.

Now you could consider the EVALUATE as an alternative, but it
doesn't add much to your simple test above. I *hate* 'Alpha'
conditions "y" or "Y" (?) so I prefer, again style, :-

01 ErrorFlag pic 99 value 0.
88 ErrorsFound value 1.
88 ErrorNotFound value 0.

if Rec-Type = 1
set ErrorNotFound to true
perform EDIT-REC *> (this sets to ErrorsFound if applicable)

If ErrorsFound
perform HANDLE-ERROR
End-if

End-if

perform MORESTUFF.

Jimmy, Calgary AB

William M. Klein

2004-05-14, 1:30 am

If using any even RELATIVELY recent IBM compiler, there is a "nesting level"
number in your listing that should tell you what you need. It doesn't issue an
error (or even a warning) because you MIGHT mean what you code.

See:
http://publibz.boulder.ibm.com/cgi-...gy3pg20/2.6.3.2

and what it "points to" in footnote 4 of the example.

--
Bill Klein
wmklein <at> ix.netcom.com
"William Bub" <fathafluff@hotmail.com> wrote in message
news:rgWoc.249467$e17.171934@twister.nyroc.rr.com...
> I just made the same coding error I made about two years age. I coded
> something like the following:
> PROCESS-PARAG.
> IF REC-TYPE = 1
> PERFORM EDIT-REC
> IF EDIT-ERR = 'Y'
> PERFORM HANDLE-ERROR
> END-IF
> PERFORM MORESTUFF
> .
> Every time REC-TYPE is not 1, MORESTUFF is not executed, even if EDIT-ERR is
> not Y. Of course, I now see that I need a second END-IF after PERFORM
> HANDLE-ERROR. Does anyone know of a compiler option which will warn if IF is
> not terminated by END-IF? Are there any utilities which will scan for this
> condition? Does anyone know a coding style which would make this type of
> error more difficult to make? Note: this is IBM mainframe.
>
>
>

Hugh Candlin

2004-05-14, 3:30 am

William Bub <fathafluff@hotmail.com> wrote in message news:rgWoc.249467$e17.171934@twister.nyroc.rr.com...
> I just made the same coding error I made about two years age. I coded
> something like the following:
> PROCESS-PARAG.
> IF REC-TYPE = 1
> PERFORM EDIT-REC
> IF EDIT-ERR = 'Y'
> PERFORM HANDLE-ERROR
> END-IF
> PERFORM MORESTUFF
> .
> Every time REC-TYPE is not 1, MORESTUFF is not executed, even if EDIT-ERR is
> not Y. Of course, I now see that I need a second END-IF after PERFORM
> HANDLE-ERROR. Does anyone know of a compiler option which will warn if IF is
> not terminated by END-IF? Are there any utilities which will scan for this
> condition? Does anyone know a coding style which would make this type of
> error more difficult to make? Note: this is IBM mainframe.

The coding style that I use was adopted to help avoid such logic errors
(although that was not the main reason).

I use the ELSE clause in every IF statement as a reminder to myself
to consider and identify what needs to be executed within both logic paths.

If I have no need for a specific imperative statement, I use NEXT SENTENCE,
either before or after the ELSE, as appropriate.

I also use blank lines and column spacing to help with readability.

Using that style, your example would be coded as

PROCESS-PARAG.
IF REC-TYPE = 1
PERFORM EDIT-REC
IF EDIT-ERR = 'Y'
PERFORM HANDLE-ERROR
ELSE
NEXT SENTENCE
ELSE
NEXT SENTENCE.

PERFORM MORESTUFF.

docdwarf@panix.com

2004-05-14, 6:30 am

In article <rgWoc.249467$e17.171934@twister.nyroc.rr.com>,
William Bub <fathafluff@hotmail.com> wrote:
>I just made the same coding error I made about two years age. I coded
>something like the following:
>PROCESS-PARAG.
> IF REC-TYPE = 1
> PERFORM EDIT-REC
> IF EDIT-ERR = 'Y'
> PERFORM HANDLE-ERROR
> END-IF
> PERFORM MORESTUFF
> .

First, it might be helpful to pay *scrupulous* attention to lining up
conditionals and their scope-delimiters; indenting that second END-IF by
its appropriate two spaces might make the error more obvious.

Second, you might try alternating IFs with EVALUATEs... in the example
above it seems trivial but when more conditions are involved it may be
helpful.

DD

JerryMouse

2004-05-14, 8:30 am

Hugh Candlin wrote:
> The coding style that I use was adopted to help avoid such logic
> errors (although that was not the main reason).
>
> I use the ELSE clause in every IF statement as a reminder to myself
> to consider and identify what needs to be executed within both logic
> paths.
>
> If I have no need for a specific imperative statement, I use NEXT
> SENTENCE,
> either before or after the ELSE, as appropriate.
>
> I also use blank lines and column spacing to help with readability.
>
> Using that style, your example would be coded as
>
> PROCESS-PARAG.
> IF REC-TYPE = 1
> PERFORM EDIT-REC
> IF EDIT-ERR = 'Y'
> PERFORM HANDLE-ERROR
> ELSE
> NEXT SENTENCE
> ELSE
> NEXT SENTENCE.
>
> PERFORM MORESTUFF.

As you may know, NEXT SENTENCE is fraught and does not always behave as you
expect.

In other words, NEXT SENTENCE does NOT always act as an appendage for ELSE
and may transfer control to nether regions of your code. Better is CONTINUE.

docdwarf@panix.com

2004-05-14, 9:30 am

In article <XeOdneIwrMeCLjndRVn-vw@giganews.com>,
JerryMouse <nospam@bisusa.com> wrote:
>Hugh Candlin wrote:

[snip]

>
>As you may know, NEXT SENTENCE is fraught and does not always behave as you
>expect.

It is my expectation that NEXT SENTENCE will direct code execution to the
imperative statement immediately following the next period ('full stop,
for English-speakers) unless it would violate the boundaries established
by an invoking PERFORM.

Is something else the case?

DD

Howard Brazee

2004-05-14, 11:30 am

On 13-May-2004, "William Bub" <fathafluff@hotmail.com> wrote:

> Every time REC-TYPE is not 1, MORESTUFF is not executed, even if EDIT-ERR is
> not Y. Of course, I now see that I need a second END-IF after PERFORM
> HANDLE-ERROR. Does anyone know of a compiler option which will warn if IF is
> not terminated by END-IF? Are there any utilities which will scan for this
> condition? Does anyone know a coding style which would make this type of
> error more difficult to make? Note: this is IBM mainframe.

One controversial coding style is to include full stop periods.

Another coding style is to use more obvious indentations.

Another coding style is to put if logic within PERFORMs.

Howard Brazee

2004-05-14, 11:30 am

On 14-May-2004, "Hugh Candlin" <no@spam.com> wrote:

> Using that style, your example would be coded as
>
> PROCESS-PARAG.
> IF REC-TYPE = 1
> PERFORM EDIT-REC
> IF EDIT-ERR = 'Y'
> PERFORM HANDLE-ERROR
> ELSE
> NEXT SENTENCE
> ELSE
> NEXT SENTENCE.

You can use this same concept with CONTINUE and END-IF. And the code will be
more efficient as CONTINUE is a NOP, while NEXT SENTENCE is a GO TO.

And periods will be optional.

Chuck Stevens

2004-05-14, 11:30 am

No, you are correct, that is what it is supposed to do.

As ISO/IEC 1989:2004 points out in its reasons for marking NEXT SENTENCE
archaic in SEARCH and IF statements: "The phrase can be confusing,
especially when specified in a delimited-scope statement. It is a common
belief among users that control is transferred to a position after the scope
delimiter rather than to a separator period somewhere. ... "

I have also encountered *implementations* that incorrectly treated NEXT
SENTENCE as referring to the next imperative statement (i.e., the statement
after the current scope delimiter), as the users described above would
expect. Personally, I consider a failure of NEXT SENTENCE to transfer
control to a point immediately after the next separator period a serious
error.

-Chuck Stevens

<docdwarf@panix.com> wrote in message news:c82eb3$ali$1@panix5.panix.com...
> In article <XeOdneIwrMeCLjndRVn-vw@giganews.com>,
> JerryMouse <nospam@bisusa.com> wrote:
>
> [snip]
>
you[color=darkred]
>
> It is my expectation that NEXT SENTENCE will direct code execution to the
> imperative statement immediately following the next period ('full stop,
> for English-speakers) unless it would violate the boundaries established
> by an invoking PERFORM.
>
> Is something else the case?
>
> DD

Howard Brazee

2004-05-14, 11:30 am

On 14-May-2004, docdwarf@panix.com wrote:

> It is my expectation that NEXT SENTENCE will direct code execution to the
> imperative statement immediately following the next period ('full stop,
> for English-speakers) unless it would violate the boundaries established
> by an invoking PERFORM.

True. (but the original poster was missing END-IF's, he could just as likely
be missing periods).

> Is something else the case?

Slightly. In the original poster's environment (IBM Mainframes), NEXT SENTENCE
works as expected in code containing END-IF's. Migrate that code elsewhere and
he will find it non-conforming.

Another place where CONTINUE works nicely is in EXIT paragraphs. In fact,
Debugging code can be included even with the D option in column 7.

Donald Tees

2004-05-14, 11:30 am

Howard Brazee wrote:
> On 13-May-2004, "William Bub" <fathafluff@hotmail.com> wrote:
>
>
>
>
> One controversial coding style is to include full stop periods.
>
> Another coding style is to use more obvious indentations.
>
> Another coding style is to put if logic within PERFORMs.

It would seem to me that making periods illegal as part of a standard is
far more controversial than including them, I'll bet you cannot find a
single cobol program in use that does not have at least one full stop
period.

Donald

docdwarf@panix.com

2004-05-14, 12:30 pm

In article <c82kst$11ak$1@si05.rsvl.unisys.com>,
Chuck Stevens <charles.stevens@unisys.com> wrote:
>No, you are correct, that is what it is supposed to do.
>
>As ISO/IEC 1989:2004 points out in its reasons for marking NEXT SENTENCE
>archaic in SEARCH and IF statements: "The phrase can be confusing,
>especially when specified in a delimited-scope statement. It is a common
>belief among users that control is transferred to a position after the scope
>delimiter rather than to a separator period somewhere. ... "

Gah... it is a 'common belief' that a good way to keep Space Aliens from
stealing your brainwaves is to wear a tin-foil-and-egg-salad hat; are
Language Standards to be changed to reflecdt this, as well?

>
>I have also encountered *implementations* that incorrectly treated NEXT
>SENTENCE as referring to the next imperative statement (i.e., the statement
>after the current scope delimiter), as the users described above would
>expect. Personally, I consider a failure of NEXT SENTENCE to transfer
>control to a point immediately after the next separator period a serious
>error.

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!

DD

docdwarf@panix.com

2004-05-14, 12:30 pm

In article <c82lli$i1f$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 14-May-2004, docdwarf@panix.com wrote:
>
>
>True. (but the original poster was missing END-IF's, he could just as likely
>be missing periods).

Hmmmmm... was the original poster 'missing' END-IFs or rendering them
unnecessary by use of a period?

IF COND-1
IF COND-2
IF COND-3
DISPLAY ' AAAIIIEEEE!'
END-IF
END-IF
END-IF

.... is executionally identical to

IF COND-1
IF COND-2
IF COND-3
DISPLAY ' AAAIIIEEEE!'
END-IF
END-IF.

Does the latter have a missing END-IF... or an extra period?

>
>
>Slightly. In the original poster's environment (IBM Mainframes), NEXT SENTENCE
>works as expected in code containing END-IF's. Migrate that code elsewhere and
>he will find it non-conforming.

There's that question of 'expectation' again. I am not sure how to
interpret it; are you saying that on a non-IBM mainframe a NEXT SENTENCE
is not 'expected' to transfer execution to the imperative statement
following the next period (paragraph boundaries excepted)?

>
>
>Another place where CONTINUE works nicely is in EXIT paragraphs. In fact,
>Debugging code can be included even with the D option in column 7.

I like CONTINUE for inline PERFORMs to find things in tables/arrays.
Coding

PERFORM 9795-EXIT
VARYING SUB1 FROM 1 BY 1
UNTIL CUST-NO (SUB1) = INREC-CUST-NO
OR SUB1 > CUST-TBL-MAX.

.... was a good one to know, granted... but it seems less elegant, to my
jaundiced eye, than

PERFORM VARYING SUB1 FROM 1 BY 1
UNTIL CUST-NO (SUB1) = INREC-CUST-NO
OR SUB1 > CUST-TBL-MAX
CONTINUE
END-PERFORM.

dd

Warren Simmons

2004-05-14, 12:30 pm

docdwarf@panix.com wrote:
> In article <c82kst$11ak$1@si05.rsvl.unisys.com>,
> Chuck Stevens <charles.stevens@unisys.com> wrote:
>
>
>
> Gah... it is a 'common belief' that a good way to keep Space Aliens from
> stealing your brainwaves is to wear a tin-foil-and-egg-salad hat; are
> Language Standards to be changed to reflecdt this, as well?
>
>
>
>
> 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!
>
> DD
>

Thank you DOC. I wanted to say that, but it's
been so long since I understood all of current
COBOL.

In fact, I find several other changes to the format
distastefully. But, It's nice to see so many other
developments spelling things out. Although, I find
the swing to using formal terms as in PhD land
unhealthy to the concept of making the self
documenting feature continue to work.

Warren Simmons

Howard Brazee

2004-05-14, 1:30 pm

On 14-May-2004, docdwarf@panix.com wrote:

> Does the latter have a missing END-IF... or an extra period?

It doesn't matter. But he forgot to close the IF statement, so I prefer a
technique that helps someone prone to forgetting.

>
> There's that question of 'expectation' again. I am not sure how to
> interpret it; are you saying that on a non-IBM mainframe a NEXT SENTENCE
> is not 'expected' to transfer execution to the imperative statement
> following the next period (paragraph boundaries excepted)?

There are computers where NEXT SENTENCE END-IF won't compile. If it won't
compile, we can't expect it to do anything.

> PERFORM 9795-EXIT
> VARYING SUB1 FROM 1 BY 1
> UNTIL CUST-NO (SUB1) = INREC-CUST-NO
> OR SUB1 > CUST-TBL-MAX.
>
> ... was a good one to know, granted... but it seems less elegant, to my
> jaundiced eye, than
>
> PERFORM VARYING SUB1 FROM 1 BY 1
> UNTIL CUST-NO (SUB1) = INREC-CUST-NO
> OR SUB1 > CUST-TBL-MAX
> CONTINUE
> END-PERFORM.

Agreed. CONTINUE is free, so let it make things a bit more clear.

(In another thread I'm told that typing extra characters is NOT free, and that
they will keep me from going home on time. But I remain unconvinced).

Howard Brazee

2004-05-14, 1:30 pm

On 14-May-2004, Donald Tees <donald_tees@sympatico.ca> wrote:

>
> It would seem to me that making periods illegal as part of a standard is
> far more controversial than including them, I'll bet you cannot find a
> single cobol program in use that does not have at least one full stop
> period.

There has been at least one long discussion in this group in which I was in
favor of using full stop periods, and someone else wanted to get rid of them,
except where mandated (at the end of paragraphs). That led me to include
"controversial" in my recommendation - so we can avoid another style war right
now.

SkippyPB

2004-05-14, 1:30 pm

On Fri, 14 May 2004 06:53:04 -0500, "JerryMouse" <nospam@bisusa.com>
enlightened us:

>Hugh Candlin wrote:
>
>As you may know, NEXT SENTENCE is fraught and does not always behave as you
>expect.
>
>In other words, NEXT SENTENCE does NOT always act as an appendage for ELSE
>and may transfer control to nether regions of your code. Better is CONTINUE.
>

PLEASE!! What Cobol compiler does such a thing? For sure every Cobol
compiler I've ever worked on in the IBM mainframe world treats NEXT
SENTENCE the same way, i.e., it transfers control to the first command
after a period (full stop) or delimiter (END-IF). CONTINUE, on the
other hand, transfers control to the next STATEMENT which may or may
not be preceded by a period (full stop).

Regards,

////
(o o)
-oOO--(_)--OOo-

I saved $300 in taxes this year but am paying
$300 more for gas. Bush giveth and his oil buddies
taketh it away.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

Alistair Maclean

2004-05-14, 1:30 pm

In message <c82nfc$om2$1@panix5.panix.com>, docdwarf@panix.com writes
>In article <c82kst$11ak$1@si05.rsvl.unisys.com>,
>Chuck Stevens <charles.stevens@unisys.com> wrote:
>
>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!
>
>DD
>

I, naively, would have assumed that CONTINUE means carry on from this
point. Should we ask the standards bods to cater for my stupidity as
well? And can't they sort out the mess with the EVALUATE clauses?

--
Alistair Maclean

When women plan, God laughs.

docdwarf@panix.com

2004-05-14, 1:30 pm

In article <40A4E88E.4070204@optonline.net>,
Warren Simmons <wsimmons5@optonline.net> wrote:
>docdwarf@panix.com wrote:

[snip]

>
>
>Thank you DOC. I wanted to say that, but it's
>been so long since I understood all of current
>COBOL.

Mr Simmons, this compliment from you is one of the most meaningful I've
received in my professional career. Thank you.

>
>In fact, I find several other changes to the format
>distastefully. But, It's nice to see so many other
>developments spelling things out. Although, I find
>the swing to using formal terms as in PhD land
>unhealthy to the concept of making the self
>documenting feature continue to work.

Moderation in all things... moderation included. Inline PERFORMs? They
can make life a lot easier, I'd say. Scope-delimiters? Devices of the
Gods, especially for 2:am debugging. Mixed-case source-code? Eh... I
can take it or leave it... my habit of writing upper-case code is deeply
ingrained, as is evidenced by the samples I post, but if other folks want
to use it then fine, let them. Pointers? Pfui!...

.... but on platforms other than the one to which I'm most accustomed
pointers are invaluable and in the ABEND-handlers I'm researching they are
necessary. The swing towards PhD-speak you mention is understandable...
after all, how many degree-programs in computer-science existed at *any*
level - BS, MS or PhD - when The Ancients were using quill pens to write
FLOWMATIC?

DD

docdwarf@panix.com

2004-05-14, 1:30 pm

In article <c82q95$lls$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 14-May-2004, docdwarf@panix.com wrote:
>
>
>It doesn't matter. But he forgot to close the IF statement, so I prefer a
>technique that helps someone prone to forgetting.

I'd wonder, then, what is easier to remember than 'In COBOL, as in
English, a statement ends with a period. Don't forget your periods...
period.'

>
>
>
>There are computers where NEXT SENTENCE END-IF won't compile. If it won't
>compile, we can't expect it to do anything.

Thanks for the clarification... cross-platform migration is a curious
condition; I seem to recall that IF COMP-3-FLD NUMERIC was valid on an IBM
mainframe but not elsewhere, as well.

DD

Donald Tees

2004-05-14, 2:30 pm

Howard Brazee wrote:
> On 14-May-2004, Donald Tees <donald_tees@sympatico.ca> wrote:
>
>
>
>
> There has been at least one long discussion in this group in which I was in
> favor of using full stop periods, and someone else wanted to get rid of them,
> except where mandated (at the end of paragraphs). That led me to include
> "controversial" in my recommendation - so we can avoid another style war right
> now.

Howard, you have no sense of adventure ...

Donald

Richard

2004-05-14, 4:30 pm

"Hugh Candlin" <no@spam.com> wrote

> PROCESS-PARAG.
> IF REC-TYPE = 1
> PERFORM EDIT-REC
> IF EDIT-ERR = 'Y'
> PERFORM HANDLE-ERROR
> ELSE
> NEXT SENTENCE
> ELSE
> NEXT SENTENCE.
>
> PERFORM MORESTUFF.

I suppose that if you are stuck with an ANS'68 compiler then that may
be the best that can be done.

Chuck Stevens

2004-05-14, 5:30 pm

<docdwarf@panix.com> wrote in message news:c82t0r$33o$1@panix5.panix.com...

> Thanks for the clarification... cross-platform migration is a curious
> condition; I seem to recall that IF COMP-3-FLD NUMERIC was valid on an IBM
> mainframe but not elsewhere, as well.

The '85 standard says a NUMERIC test must reference a USAGE DISPLAY item;
I'm fairly certain that IBM is *not* the only compiler vendor who allows
NUMERIC tests of non-DISPLAY numeric items as an extension to '85 COBOL.

Note that the prohibition precludes the use of IF ... NUMERIC against a
USAGE PACKED-DECIMAL data item. Given that the standard specifies at least
a part of the representation for this usage, it should be possible (and
reasonable) for an implemementation to be able to verify when the data is
not in compliance with that representation.

The '02 standard explicitly allows a test for NUMERIC against any
category-numeric item (even when the test most likely always returns TRUE --
e.g., USAGE BINARY-CHAR). That makes a whole lot more sense to me.

Presuming COMP-3-FLD is described as USAGE COMP-3, whether vendors allow IF
COMP-3-FLD NUMERIC or not is moot, precisely because USAGE COMP-3 is and has
always been an implementor-defined extension to the standard to begin with.

-Chuck Stevens

Howard Brazee

2004-05-14, 6:30 pm

On 14-May-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> Note that the prohibition precludes the use of IF ... NUMERIC against a
> USAGE PACKED-DECIMAL data item. Given that the standard specifies at least
> a part of the representation for this usage, it should be possible (and
> reasonable) for an implemementation to be able to verify when the data is
> not in compliance with that representation.

The first time I worked with a compiler that didn't work this way, I was aghast.
What a terrible design!

The major problem (for me) with the design of CoBOL is that we can't put decent
error handling within the statement that throws the error. e.g. We have to
have a function to test to find out whether the NUMVAL function will fail.

We waste a lot of CPU time with IF NUMERIC statements.

Chuck Stevens

2004-05-14, 6:30 pm

"SkippyPB" <swiegand@neo.rr.NOSPAM.com> wrote in message
news:2lr9a092neoeo5tostdfl1o1edq6gvmhp3@
4ax.com...

ELSE[color=darkred]
CONTINUE.[color=darkred]
>
> PLEASE!! What Cobol compiler does such a thing? For sure every Cobol
> compiler I've ever worked on in the IBM mainframe world treats NEXT
> SENTENCE the same way, i.e., it transfers control to the first command
> after a period (full stop) or delimiter (END-IF).

Then every compiler you worked on in the IBM mainframe world was
non-compliant with the standards. There are three sorts of sentences
defined in the '85 standard, and each of them is always terminated by a
separator period. NEXT SENTENCE is defined in the syntax for IF and SEARCH
only, and in both cases, its execution causes control to pass to the next
executable *sentence*, not the *statement* following the scope delimiter for
the current IF or SEARCH (if they're not the same). The '85 standard is
clear on that point, but apparently some users (and perhaps some
implementations) weren't.

-Chuck Stevens

Chuck Stevens

2004-05-14, 6:30 pm

The exception handling feature of the 2002 specification helps some here, I
think, although it still relies heavily on DECLARATIVES.

-Chuck Stevens

"Howard Brazee" <howard@brazee.net> wrote in message
news:c83bin$dus$1@peabody.colorado.edu...
>
> On 14-May-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
least[color=darkred]
is[color=darkred]
>
> The first time I worked with a compiler that didn't work this way, I was
aghast.
> What a terrible design!
>
> The major problem (for me) with the design of CoBOL is that we can't put
decent
> error handling within the statement that throws the error. e.g. We have
to
> have a function to test to find out whether the NUMVAL function will fail.
>
> We waste a lot of CPU time with IF NUMERIC statements.

Rick Smith

2004-05-14, 6:30 pm

<docdwarf@panix.com> wrote in message news:c82o3p$pdk$1@panix5.panix.com...
[snip]
>
> I like CONTINUE for inline PERFORMs to find things in tables/arrays.
> Coding
>
> PERFORM 9795-EXIT
> VARYING SUB1 FROM 1 BY 1
> UNTIL CUST-NO (SUB1) = INREC-CUST-NO
> OR SUB1 > CUST-TBL-MAX.
>
> ... was a good one to know, granted... but it seems less elegant, to my
> jaundiced eye, than
>
> PERFORM VARYING SUB1 FROM 1 BY 1
> UNTIL CUST-NO (SUB1) = INREC-CUST-NO
> OR SUB1 > CUST-TBL-MAX
> CONTINUE
> END-PERFORM.

Speaking of Avoiding Logic Errors! While both of the above
will work when bounds checking is inactive, they will fail when
bounds checking is active. (I think it is SSRANGE on IBM.)
It is a logic error to refer to a non-existent 'CUST-NO'. To
avoid the logic error, check the limit first.

It is obvious to me that the above often works well on IBM,
but when 'CUST-NO (SUB1) = INREC-CUST-NO' is not true for
any SUB1, the error appears in Micro Focus as a fatal runtime
error 153, 'Subscript out of range'. The difference may be
understood in the value of default options for subscript range
(bounds) checking between IBM and Micro Focus (and others).

The following should work correctly with all implementations
with or without subscript range (bounds) checking.

PERFORM 9795-EXIT
VARYING SUB1 FROM 1 BY 1
UNTIL SUB1 > CUST-TBL-MAX
OR CUST-NO (SUB1) = INREC-CUST-NO.

and

PERFORM VARYING SUB1 FROM 1 BY 1
UNTIL SUB1 > CUST-TBL-MAX
OR CUST-NO (SUB1) = INREC-CUST-NO
CONTINUE
END-PERFORM.

Robert Wagner

2004-05-14, 7:30 pm

"William Bub" <fathafluff@hotmail.com> wrote:

>I just made the same coding error I made about two years age. I coded
>something like the following:
>PROCESS-PARAG.
> IF REC-TYPE = 1
> PERFORM EDIT-REC
> IF EDIT-ERR = 'Y'
> PERFORM HANDLE-ERROR
> END-IF
> PERFORM MORESTUFF
> .
>Every time REC-TYPE is not 1, MORESTUFF is not executed, even if EDIT-ERR is
>not Y. Of course, I now see that I need a second END-IF after PERFORM
>HANDLE-ERROR. Does anyone know of a compiler option which will warn if IF is
>not terminated by END-IF? Are there any utilities which will scan for this
>condition? Does anyone know a coding style which would make this type of
>error more difficult to make? Note: this is IBM mainframe.

C, Fortran and other languages have a program named 'lint' to catch such errors.
AFIK, there is no lint for Cobol. Why not write one?

Cobol makes it easy because it requires a period at the end of every paragraph.
The rule is 'issue a warning if you see a period that's not at nest level zero.'

It would have to know about implied terminators such as:

if rec-type = 1
call 'edit-rec' on exception
perform handle-error
end-if

In this case the call is not terminated by an end-call, but is implicitly by the
end-if.

Robert Wagner

2004-05-14, 7:30 pm

Donald Tees <donald_tees@sympatico.ca> wrote:

>It would seem to me that making periods illegal as part of a standard is
>far more controversial than including them, I'll bet you cannot find a
>single cobol program in use that does not have at least one full stop
>period.

That's easy.

--- begin complete Cobol program ---
procedure division.
display 'Hello world'
--- end complete Cobol program ---

Granted, it has a period after the division header. When you said "making
periods illegal", I assume you meant 'in the procedure division'.

Richard

2004-05-14, 8:30 pm

SkippyPB <swiegand@neo.rr.NOSPAM.com> wrote

> PLEASE!! What Cobol compiler does such a thing? For sure every Cobol
> compiler I've ever worked on in the IBM mainframe world treats NEXT
> SENTENCE the same way, i.e., it transfers control to the first command
> after a period (full stop) or delimiter (END-IF).

NO. WRONG. It obviously does not work as _you_ expect.

It should work, and almost certainly does work, by transferring
control to the statement following the next full stop.

However, having said that, there are some compilers that have an
obscure option that "Changes the behaviour of the NEXT SENTENCE
statement". You may also note that in ANS'85 NEXT SENTENCE is not a
statement at all, but is a clause of some formats of the IF and SEARCH
statements.

Combinations of NEXT SENTENCE and END-IF are not allowed by ANS'85
(argue about contrived ways to avoid the intent of the standard if you
dare) but if you do use this as a compiler extension, then it
_does_not_ transfer control to after this, but to some later arbitrary
point where there is a full stop.

> CONTINUE, on the
> other hand, transfers control to the next STATEMENT which may or may
> not be preceded by a period (full stop).

CONTINUE does _NOT_ 'transfer control to' anywhere at all. CONTINUE
does absolutely nothing, it is a null op and just a place holder where
the syntax requires a statement. This usually results execution
continuing at the next place that it correctly should do.

For example:

PERFORM VARYING .. UNTIL ...
CONTINUE
END-PERFORM

William M. Klein

2004-05-14, 8:30 pm

Ah, Doc - you have made EXACTLY the "mistake" that leads to the Standards people
making NEXT SENTENCE "archaic" (not yet OBSOLETE) when you say,

> I'd wonder, then, what is easier to remember than 'In COBOL, as in
> English, a statement ends with a period. Don't forget your periods...
> period.'

In "COBOL-eze" a period ends a SENTENCE. A statement is ended by
- a period
- another statement at the same "nesting" level
- an explicit scope-terminator

For example, the following '85 Standard conforming program (showing the
difference in logic flow between CONTINUE and Next Sentence

Para-1.
If A = "A"
If Y > "Y"
Next Sentence
Else
Continue
Else
Move "A" to A
End-If
Add 1 to Num-Field
On Size Error
Display "this"
Not On size Error
Display "that"
Display "still here"
End-Add

Donald Tees

2004-05-14, 9:30 pm

Rick Smith wrote:
> <docdwarf@panix.com> wrote in message news:c82o3p$pdk$1@panix5.panix.com...
> [snip]
>
>
>
> Speaking of Avoiding Logic Errors! While both of the above
> will work when bounds checking is inactive, they will fail when
> bounds checking is active. (I think it is SSRANGE on IBM.)
> It is a logic error to refer to a non-existent 'CUST-NO'. To
> avoid the logic error, check the limit first.
>
> It is obvious to me that the above often works well on IBM,
> but when 'CUST-NO (SUB1) = INREC-CUST-NO' is not true for
> any SUB1, the error appears in Micro Focus as a fatal runtime
> error 153, 'Subscript out of range'. The difference may be
> understood in the value of default options for subscript range
> (bounds) checking between IBM and Micro Focus (and others).
>
> The following should work correctly with all implementations
> with or without subscript range (bounds) checking.
>
> PERFORM 9795-EXIT
> VARYING SUB1 FROM 1 BY 1
> UNTIL SUB1 > CUST-TBL-MAX
> OR CUST-NO (SUB1) = INREC-CUST-NO.
>
> and
>
> PERFORM VARYING SUB1 FROM 1 BY 1
> UNTIL SUB1 > CUST-TBL-MAX
> OR CUST-NO (SUB1) = INREC-CUST-NO
> CONTINUE
> END-PERFORM.
>
>
>

I should certainly hope so. If there is a non-existant "cust-no(sub1)",
then you have a coding error that you *WANT* to fail, every last time.
Then you can define your table and table size parameter correctly, and
impliment the code.

The only possible reason for failure is that CUST-TBLE-MAX is set to the
incorrect value. Since this would be hard-coded, or set by the table
loading routine, the error 153 is *DESIRABLE*.

Donald.

Donald Tees

2004-05-14, 9:30 pm

Robert Wagner wrote:
> Donald Tees <donald_tees@sympatico.ca> wrote:
>
>
>
>
> That's easy.
>
> --- begin complete Cobol program ---
> procedure division.
> display 'Hello world'
> --- end complete Cobol program ---
>
> Granted, it has a period after the division header. When you said "making
> periods illegal", I assume you meant 'in the procedure division'.

No, I had wished to say "in the procedure divison" I would have. I said
exactly what I meant to say.

Donald

LX-i

2004-05-14, 10:30 pm

William Bub wrote:
> I just made the same coding error I made about two years age. I coded
> something like the following:
> PROCESS-PARAG.
> IF REC-TYPE = 1
> PERFORM EDIT-REC
> IF EDIT-ERR = 'Y'
> PERFORM HANDLE-ERROR
> END-IF
> PERFORM MORESTUFF
> .
> Every time REC-TYPE is not 1, MORESTUFF is not executed, even if EDIT-ERR is
> not Y. Of course, I now see that I need a second END-IF after PERFORM
> HANDLE-ERROR. Does anyone know of a compiler option which will warn if IF is
> not terminated by END-IF? Are there any utilities which will scan for this
> condition? Does anyone know a coding style which would make this type of
> error more difficult to make? Note: this is IBM mainframe.

I don't know of an option or anything. However, the editor we use at
work, Visual SlickEdit by MicroEdge Computing, has a "syntax expansion"
option, and if you've got "COBOL 2000" syntax (vs. "COBOL 74", the other
option), it will automatically include a scope delimiter for you. So,
if you type "i" "f" "[space]", what is placed in the code is

if x
end-if

where x is where the cursor is located. Personally, this option gets in
my way more than it helps, so I've turned it off. But, it's there. I'm
not sure how much VSlick costs, but it's a pretty sweet editor - has a
C-based scripting language, supports a plethora of languages, and
provides a mechanism to define color-coded data names in 4 different
user categories.

Absent that, the key is to keep things aligned. After you code a
paragraph (or make a change), re-read it from top to bottom, looking for
"alignment" errors. You may find something like that in a desk check
(as the compiler's not going to be a lot of help).

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

docdwarf@panix.com

2004-05-14, 10:30 pm

In article <xycpc.772$SZ4.515@newsread2.news.pas.earthlink.net>,
William M. Klein <wmklein@nospam.netcom.com> wrote:
>Ah, Doc - you have made EXACTLY the "mistake" that leads to the Standards people
>making NEXT SENTENCE "archaic" (not yet OBSOLETE) when you say,
>
>
>In "COBOL-eze" a period ends a SENTENCE. A statement is ended by
> - a period
> - another statement at the same "nesting" level
> - an explicit scope-terminator

My error and apologies, Mr Klein; I was taking the aspect of English-like
too far in that I was using 'statement' to indicate a sentence which was
not an exclamation or an interrogative... and thus ended with a period.
To correct myself:

'I'd wonder, then, what is easier to remember than 'In COBOL, as in
English, a sentence ends with a period (unless it is an exclamation or an
interrogative). Don't forget your peroids... period.

Doesn't have the... ring of the first formulation... and there are
probably similar holes to be found in it.

Write simple sentences. Use periods. Period.

DD

LX-i

2004-05-14, 10:30 pm

docdwarf@panix.com wrote:

> I like CONTINUE for inline PERFORMs to find things in tables/arrays.
> Coding
>
> PERFORM 9795-EXIT
> VARYING SUB1 FROM 1 BY 1
> UNTIL CUST-NO (SUB1) = INREC-CUST-NO
> OR SUB1 > CUST-TBL-MAX.
>
> ... was a good one to know, granted... but it seems less elegant, to my
> jaundiced eye, than
>
> PERFORM VARYING SUB1 FROM 1 BY 1
> UNTIL CUST-NO (SUB1) = INREC-CUST-NO
> OR SUB1 > CUST-TBL-MAX
> CONTINUE
> END-PERFORM.

True - but search would be even more elegant in this case... :) (IMO,
of course...)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

LX-i

2004-05-14, 10:30 pm

Howard Brazee wrote:

> On 14-May-2004, docdwarf@panix.com wrote:
>
>
> There are computers where NEXT SENTENCE END-IF won't compile. If it won't
> compile, we can't expect it to do anything.

like the Unisys 2200... :) That was one of the first "aaaaa!" moments
when we went to COBOL 85, and added some scope delimiters to existing
"next sentence" logic.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

docdwarf@panix.com

2004-05-14, 10:30 pm

In article <10aae7nho3los3d@corp.supernews.com>,
Rick Smith <ricksmith@mfi.net> wrote:
>
><docdwarf@panix.com> wrote in message news:c82o3p$pdk$1@panix5.panix.com...
>[snip]
>
>Speaking of Avoiding Logic Errors! While both of the above
>will work when bounds checking is inactive, they will fail when
>bounds checking is active. (I think it is SSRANGE on IBM.)

Old habits die hard, Mr Smith... keeping the last entry in a table
(CUST-TBL-MAX + 1) to HIGH-VALUES is one of them, manually checking
subscripts and not using SSRANGE (so that you can refer to tables > 32K)
is another...

.... but such things might not be obvious from a few lines of code,
certainly.

>It is a logic error to refer to a non-existent 'CUST-NO'.

That might depends on the rules one is using for 'logic', Mr Smith... I
have been instructed to have programs blow up if an input record does not
have a matching masterfile-record

DD

docdwarf@panix.com

2004-05-14, 10:30 pm

In article <10aasbrd3ii655a@corp.supernews.com>,
LX-i <lxi0007@netscape.net> wrote:
>docdwarf@panix.com wrote:
>
>
>True - but search would be even more elegant in this case... :) (IMO,
>of course...)

I've worked in shops where SEARCH was forbidden; in such places it would
have provided an inelegant way out the door.

DD

LX-i

2004-05-14, 10:30 pm

docdwarf@panix.com wrote:

>
>
> I've worked in shops where SEARCH was forbidden; in such places it would
> have provided an inelegant way out the door.

Why is that? They didn't like efficiency?

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

berlutte@sympatico.ca

2004-05-14, 11:30 pm

On 14 May 2004 21:33:38 -0400, docdwarf@panix.com wrote:

>That might depends on the rules one is using for 'logic', Mr Smith... I
>have been instructed to have programs blow up if an input record does not
>have a matching masterfile-record

http://www.macon.com/mld/macon/news/nation/8661136.htm

But for nearly four months afterward, the piece of bone lay in a
hospital freezer across town - and Lane had to wear a plastic street
hockey helmet - because of a standoff with Medicaid and the hospital
over who would cover the surgery to make her whole again.

The surgery finally came through after an excruciating wait, during
which she suffered extreme pain just bending down and would wake up in
the morning to find that her brain had shifted to one side during the
night.
========================================
====================
The input record did not have a matching masterfile-record it seems!

BWAHAHAHAHARRRGGGHHH!

Sickos-R-U$ ney?

Clark F. Morris, Jr.

2004-05-15, 12:30 am

SkippyPB wrote:

> On Fri, 14 May 2004 06:53:04 -0500, "JerryMouse" <nospam@bisusa.com>
> enlightened us:
>
>
>
>
> PLEASE!! What Cobol compiler does such a thing? For sure every Cobol
> compiler I've ever worked on in the IBM mainframe world treats NEXT
> SENTENCE the same way, i.e., it transfers control to the first command
> after a period (full stop) or delimiter (END-IF). CONTINUE, on the
> other hand, transfers control to the next STATEMENT which may or may
> not be preceded by a period (full stop).

What IBM COBOL compiler has NEXT SENTENCE transferring control to other
than the first statement following the period (full stop)? In the one
period per paragraph style, NEXT SENTENCE could be used as an EXIT
PARAGRAPH statement.
>
> Regards,
>
> ////
> (o o)
> -oOO--(_)--OOo-
>
>
> I saved $300 in taxes this year but am paying
> $300 more for gas. Bush giveth and his oil buddies
> taketh it away.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Remove nospam to email me.
>
> Steve

Richard

2004-05-15, 12:30 am

robert.deletethis@wagner.net (Robert Wagner) wrote

^^^^^^[color=darkred]
[color=darkred]
> --- begin complete Cobol program ---
> procedure division.
> display 'Hello world'
> --- end complete Cobol program ---

This fails the 'in use' clause. It also fails to be a 'Cobol program'
for a number of compilers, relying as it does on a several vendor
specific extensions.

> Granted, it has a period after the division header.

I am glad that you noticed this failure.

> When you said "making
> periods illegal", I assume you meant 'in the procedure division'.

Not only do you change what you meant, you also attempt to change what
other people meant too.

And my references have 'PROCEDURE DIVISION.' as being part of 'the
procedure division'.

Richard

2004-05-15, 12:30 am

robert.deletethis@wagner.net (Robert Wagner) wrote

> It would have to know about implied terminators such as:
>
> if rec-type = 1
> call 'edit-rec' on exception
> perform handle-error
> end-if
>
> In this case the call is not terminated by an end-call, but is implicitly by the
> end-if.

Which means that it cannot catch:

> if rec-type = 1
> call 'edit-rec' on exception
> perform handle-error
perform morestuff
> end-if

Rick Smith

2004-05-15, 12:30 am

Donald Tees <donald_tees@sympatico.ca> wrote in message
news:GAdpc.83064$FH5.1947017@news20.bellglobal.com...
> Rick Smith wrote:
news:c82o3p$pdk$1@panix5.panix.com...[color=darkred]
>
> I should certainly hope so. If there is a non-existant "cust-no(sub1)",
> then you have a coding error that you *WANT* to fail, every last time.
> Then you can define your table and table size parameter correctly, and
> impliment the code.

In the cases where I have used such code, what I wanted is an
indication of 'found' or 'not found'. That is, if 'sub1 > cust-tbl-max',
then the value for 'inrec-cust-no' was not found in the table.

> The only possible reason for failure is that CUST-TBLE-MAX is set to the
> incorrect value. Since this would be hard-coded, or set by the table
> loading routine, the error 153 is *DESIRABLE*.

In the programs I have written, runtime error 153 has never been
desirable. Where a limit may be exceeded, a text message is
provided.

Rick Smith

2004-05-15, 12:30 am

<docdwarf@panix.com> wrote in message news:c83s1i$g6b$1@panix5.panix.com...
> In article <10aae7nho3los3d@corp.supernews.com>,
> Rick Smith <ricksmith@mfi.net> wrote:
news:c82o3p$pdk$1@panix5.panix.com...[color=darkred]
>
> Old habits die hard, Mr Smith... keeping the last entry in a table
> (CUST-TBL-MAX + 1) to HIGH-VALUES is one of them, manually checking
> subscripts and not using SSRANGE (so that you can refer to tables > 32K)
> is another...
>
> ... but such things might not be obvious from a few lines of code,
> certainly.
>
>
> That might depends on the rules one is using for 'logic', Mr Smith... I
> have been instructed to have programs blow up if an input record does not
> have a matching masterfile-record

Quite right, Mr Dwarf. My cursory study of formal methods has
changed my old habits such that I more readily apply the label
'logic error' where code would violate certain conditions. And
that is true without regard to whether such code would actually
cause a program fault.

Arnold Trembley

2004-05-15, 4:30 am

LX-i wrote:
> docdwarf@panix.com wrote:
>
>
>
> Why is that? They didn't like efficiency?

Back in the days of IBM OS/VS COBOL and CICS 1.6.1 there were several
COBOL verbs that did not work correctly or efficiently in a CICS
environment. SEARCH may well have been one of them. EXAMINE/INSPECT
may have been another.

The story I was told at the time was that certain verbs generated
calls to the OS/VS COBOL runtime library routines, and those routines
were not built to run in the CICS quasi-reentrant environment.

In 1992 we switched to COBOL II, and I forgot all the old restrictions.

Some shops may have simply forbidden SEARCH because they believed it
was too complicated for their programmers.

--
http://arnold.trembley.home.att.net/

JerryMouse

2004-05-15, 8:30 am

docdwarf@panix.com wrote:
>
> It is my expectation that NEXT SENTENCE will direct code execution to
> the imperative statement immediately following the next period ('full
> stop,
> for English-speakers) unless it would violate the boundaries
> established
> by an invoking PERFORM.
>
> Is something else the case?

Well, yes. First, there's your "unless" modifier.

Second, NEXT SENTENCE gets in the way for those who speak the COBOL dialect
of using one period per paragraph.

Third, NEXT SENTENCE is an artifact from a simpler time before scope
delimiters muddied its logic water.

My view is that the logic constructs of scope delimiters and NEXT SENTENCE
are fundamentally incompatible.

docdwarf@panix.com

2004-05-15, 9:30 am

In article <10ab49u7mtsigb5@corp.supernews.com>,
Rick Smith <ricksmith@mfi.net> wrote:
>
><docdwarf@panix.com> wrote in message news:c83s1i$g6b$1@panix5.panix.com...

[snip]
[color=darkred]
>
>Quite right, Mr Dwarf. My cursory study of formal methods has
>changed my old habits such that I more readily apply the label
>'logic error' where code would violate certain conditions.

Most gracious of you, Mr Smith... for some reason this reminds me of
something I read, long ago, which stated that getting *really* offended
about something was a Very Good Thing, as it showed what one considered
Really Important.

DD

docdwarf@panix.com

2004-05-15, 9:30 am

In article <10aatmaobtt01fc@corp.supernews.com>,
LX-i <lxi0007@netscape.net> wrote:
>docdwarf@panix.com wrote:
>
>
>Why is that? They didn't like efficiency?

I'm not sure about the 'efficiency' aspect... come Monday, if I remember
and have the time, I'll fire up ol' IKFCBL00 (the IBM mainframe ANSI '74
compiler that installations still have but try to keep very well hidden)
and code a few tests to see what kind of PMAPs they make. I'll do a
PERFORM of an -EXIT paragraph to compare fields of different lengths
(one-char vs. multi-char) and a couple of SEARCHes to do the same; I'll
report here about the code generated by both.

Now you might ask... why do I use OldBOL for this? I do so because the
guys in charge of the shops where SEARCHes were forbidden were trained in
OldBOL... and not very well, it seems, because while they would tell me
Very Very Seriously that SEARCHes were prone to efficiency issues...

.... the guys in the trenches would ask 'So, did Jonesie tell you how bad
SEARCHes were? Don't believe it... he just doesn't understand how they
work and they confuse him.'

DD

docdwarf@panix.com

2004-05-15, 9:30 am

In article <tjjpc.6742$hH.165434@bgtnsc04-news.ops.worldnet.att.net>,
Arnold Trembley <arnold.trembley@worldnet.att.net> wrote:

[snip]

>
>Back in the days of IBM OS/VS COBOL and CICS 1.6.1 there were several
>COBOL verbs that did not work correctly or efficiently in a CICS
>environment. SEARCH may well have been one of them. EXAMINE/INSPECT
>may have been another.

INSPECT was one, STRING/UNSTRING were others... I don't recall ever coding
a SEARCH for a CICS program, things were either in very small tables or
one would hit a file/table to get them.

[snip]

>In 1992 we switched to COBOL II, and I forgot all the old restrictions.

I'll never forget the 'holy excrement!' sensation when I first saw a
multi-item INSPECT's PMAP... errrr, LISTing under IGYCRCTL... I'll try to
remember that for Monday, as well; to code

INSPECT INPUT-REC REPLACING ALL 'a' BY 'A'
ALL 'b' BY 'B'
....
ALL 'z' BY 'Z'.

(or whatever the syntax is that'll compile... can't remember if each one
needs an ALL or not)

.... and compile it under IKFCBL00 and IGYCRCTL. The former will produce
what is technically called a 'God-Awful Ugly Mess' while the latter will
produces something like two or four statements... one of which is a TRT, I
know, but I forget the rest.

>
>Some shops may have simply forbidden SEARCH because they believed it
>was too complicated for their programmers.

.... or themselves, see my response earlier.

DD

docdwarf@panix.com

2004-05-15, 9:30 am

Xref: 127.0.0.1 comp.lang.cobol:5808

In article <4eydnSQ7cdsmmTvdRVn-jA@giganews.com>,
JerryMouse <nospam@bisusa.com> wrote:
>docdwarf@panix.com wrote:
>
>Well, yes. First, there's your "unless" modifier.

All right, consider it first... what about it? It states that the
boundaries of a NEXT SENTENCE are not to exceed the scope of the PERFORM
which invoked it.

>
>Second, NEXT SENTENCE gets in the way for those who speak the COBOL dialect
>of using one period per paragraph.

Not at all... in such a case that 'unless' you noticed above kicks in and
you have a de facto EXIT PARAGRAPH, how's *that* for convenience?

(It took me a while to come to that conclusion... my first response was
'Those who speak the dialect of one period per paragraph get in the way of
using NEXT SENTENCE; if the dialect one speaks restricts one's use of
Standard constructions then one might want to consider a speech-coach.')

>
>Third, NEXT SENTENCE is an artifact from a simpler time before scope
>delimiters muddied its logic water.

As Wittgenstein said, 'Logic is a game played by a particular series of
rules'... if those rules have changed it is up to the players to keep up
on them.

>
>My view is that the logic constructs of scope delimiters and NEXT SENTENCE
>are fundamentally incompatible.

A lovely view, some might think... but can it be supported by reasoned
argument? If not then it might well be relegated to the Realm of
Opinion... and long ago my Drill Sergeant taught me something about
opinions.

DD

docdwarf@panix.com

2004-05-15, 9:30 am

In article <c8412o$eg9$1@news.eusc.inter.net>,
Clark F. Morris, Jr. <cfmtech@istar.ca> wrote:

[snip]

>What IBM COBOL compiler has NEXT SENTENCE transferring control to other
>than the first statement following the period (full stop)? In the one
>period per paragraph style, NEXT SENTENCE could be used as an EXIT
>PARAGRAPH statement.

Mr Morris, you have my most solemn word that I did not read this before
coming to the exact same conclusion in my previous posting.

Small minds running in similar circles, it seems.

DD

Michael Mattias

2004-05-15, 1:30 pm

<docdwarf@panix.com> wrote in message news:c852gp$l0r$1@panix5.panix.com...
> In article <tjjpc.6742$hH.165434@bgtnsc04-news.ops.worldnet.att.net>,
> Arnold Trembley <arnold.trembley@worldnet.att.net> wrote:
>
> ... or themselves, see my response earlier.

Don't laugh.

True story:

First time I did some work for a particular client (IBM mainframe COBOL), it
was because their department's lead COBOL programmer, who had been doing
their COBOL work for nine (9) years, was not familiar with the application.

So I did my thing, and when completed the lead programmer wanted to inspect
the source code to ensure it was maintainable - an eminently sensible thing
to do, right?

Imagine my surprise when this lead programmer with nine years of experience
told me that in addition to my code being very maintainable, she was really
glad to have seen it, because it was the first time she had ever seen the
SEARCH verb used.

The lesson I learned was, never assume ANYTHING about a customer's skill or
experience level.....

MCM

Robert Wagner

2004-05-15, 2:30 pm

riplin@Azonic.co.nz (Richard) wrote:
[color=darkred]
>Which means that it cannot catch:
>
> perform morestuff

Not by syntax analysis. I will catch the error if the INDENTATION option is
turned on.

berlutte@sympatico.ca

2004-05-15, 3:30 pm

http://www.wishtv.com/Global/story.asp?S=1857668
The woman who blew the whistle on problems in the Marion County voting
system will now watch the situation from the outside.

You shouldn't know about Wendy Orange. She should be someone who
served behind the scenes to make our elections work. Orange became a
public figure when she revealed voting machine problems. She blamed
her employer, Election Systems and Software (ES&S).
========================================
=====================

Here is at least one gal with balls. Not like many other coders for
hire who would sell Ma fer a few dollahs.

On 15 May 2004 08:42:27 -0400, docdwarf@panix.com wrote:

>Small minds running in similar circles, it seems.

Good gracious old Janus, how pointed!

berlutte@sympatico.ca

2004-05-15, 3:30 pm

On 15 May 2004 08:42:27 -0400, docdwarf@panix.com wrote:

>Small minds running in similar circles, it seems.

AP (Associated Propaganda) then reported that "unnamed CIA officials"
said that Nick Berg's killer was Abu Musab al-Zarqawi, who was killed
months ago, according to public reports. CIA probably figures (and
rightly so) that clueless flag-waving Americans can't keep their Dead
Ragheads straight.

LOL

Them conspiracy theorists are way funnier than accident theorists,
nay?

Richard

2004-05-15, 4:30 pm

docdwarf@panix.com wrote

> All right, consider it first... what about it? It states that the
> boundaries of a NEXT SENTENCE are not to exceed the scope of the PERFORM
> which invoked it.

How could that occur ?

> Not at all... in such a case that 'unless' you noticed above kicks in and
> you have a de facto EXIT PARAGRAPH, how's *that* for convenience?

A convenient way of creating a bugtrap it certainly is.

>
> A lovely view, some might think... but can it be supported by reasoned
> argument? If not then it might well be relegated to the Realm of
> Opinion... and long ago my Drill Sergeant taught me something about
> opinions.

It certainly is the opinion of the Standards Committee (they are
disallowed in the same structure), and there are very reasoned
arguments to support the incompatability of these, mainly centred
about your 'discovery' of the convenient bugtrap.

LX-i

2004-05-15, 6:30 pm

Arnold Trembley wrote:
>
> LX-i wrote:
>
>
> Back in the days of IBM OS/VS COBOL and CICS 1.6.1 there were several
> COBOL verbs that did not work correctly or efficiently in a CICS
> environment. SEARCH may well have been one of them. EXAMINE/INSPECT
> may have been another.
>
> The story I was told at the time was that certain verbs generated calls
> to the OS/VS COBOL runtime library routines, and those routines were not
> built to run in the CICS quasi-reentrant environment.

I'd buy that. A lot of our old code has exit paragraphs on -every-
paragraph - I was told that this was to compensate for a long-ago-fixed
bug. :)

> In 1992 we switched to COBOL II, and I forgot all the old restrictions.
>
> Some shops may have simply forbidden SEARCH because they believed it was
> too complicated for their programmers.

Too complicated? To me, it's simpler than an inline perform (and
cleaner - you don't have to "subtract 1" as you sometimes may with an
inline perform), plus the fact (well, it' s my experience, anyway) that
it's faster. There was a program that would take about 3 minutes to run
if it didn't find anything. I modified it to read the data into memory
in big chunks, and used SEARCH to find matching values - it takes about
5 seconds now. (Granted, some of that is in I/O improvement, but some
of it is due to SEARCH.)

It's just a training issue - I've never had it properly explained to me
outside this newsgroup. I've passed on the knowledge, though, and not
one person I've explained it to has had any trouble grasping it.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

LX-i

2004-05-15, 6:30 pm

docdwarf@panix.com wrote:

> In article <10aatmaobtt01fc@corp.supernews.com>,
> LX-i <lxi0007@netscape.net> wrote:
>
>
> I'm not sure about the 'efficiency' aspect... come Monday, if I remember
> and have the time, I'll fire up ol' IKFCBL00 (the IBM mainframe ANSI '74
> compiler that installations still have but try to keep very well hidden)
> and code a few tests to see what kind of PMAPs they make. I'll do a
> PERFORM of an -EXIT paragraph to compare fields of different lengths
> (one-char vs. multi-char) and a couple of SEARCHes to do the same; I'll
> report here about the code generated by both.

Cool - I look forward to that. :)

> Now you might ask... why do I use OldBOL for this? I do so because the
> guys in charge of the shops where SEARCHes were forbidden were trained in
> OldBOL... and not very well, it seems, because while they would tell me
> Very Very Seriously that SEARCHes were prone to efficiency issues...

That's fine - I've seen that in our code, even coded it some (though I
usually use an inline perform now, when the table is in a copybook that
I can't modify for "political" reasons).

> ... the guys in the trenches would ask 'So, did Jonesie tell you how bad
> SEARCHes were? Don't believe it... he just doesn't understand how they
> work and they confuse him.'

heh... Isn't fun working with folks whose minds are made up early?

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

LX-i

2004-05-15, 6:30 pm

docdwarf@panix.com wrote:

> In article <4eydnSQ7cdsmmTvdRVn-jA@giganews.com>,
> JerryMouse <nospam@bisusa.com> wrote:
>
>
> A lovely view, some might think... but can it be supported by reasoned
> argument? If not then it might well be relegated to the Realm of
> Opinion... and long ago my Drill Sergeant taught me something about
> opinions.

It can be supported by my compiler...

if mySwitchIsSet
perform additionalSwitchTests
if mySwitchIsSet
next sentence
else
display "Switch cleared by additional tests"
end-if
end-if

My compiler will not accept this code snippet (in proper context, of
course). And paragraph 3.6.16 of the compiler's manual, syntax rule 3,
states "If the END-IF phrase is specified, the NEXT SENTENCE phrase must
not be specified."

I agree with JerryMouse, if for no other reason than personal
experience. CONTINUE always goes to the scope delimiter (I know it
doesn't really "Go" anywhere, but that's the effect), and I've found it
an acceptable replacement for NEXT SENTENCE.

I really like the concept of NEXT SENTENCE working as a de facto EXIT
PARAGRAPH statement - it's a shame our compiler doesn't interpret it
that way.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

berlutte@sympatico.ca

2004-05-15, 7:30 pm

The New AngloZMerkan's Bunny:
http://uk.gamesdomain.yahoo.com/sli...017010&ssidx=11

Browsing the catalog is most tellin'.

Good to discover where the psycho programming industry come from!

On 15 May 2004 08:42:27 -0400, docdwarf@panix.com wrote:

>Small minds running in similar circles, it seems.

No artsy-fartsy commie fag pinko left librul games for the keedz here.

Evil coders nay?

William M. Klein

2004-05-15, 7:30 pm

So, I'll bet your compiler WILL accept the following (whether it is "good or
bad" is another question)

if mySwitchIsSet
perform additionalSwitchTests
if mySwitchIsSet
If mySwtichIsSet
next sentence
else
continue
else
display "Switch cleared by additional tests"
end-if
end-if

--
Bill Klein
wmklein <at> ix.netcom.com
"LX-i" <lxi0007@netscape.net> wrote in message
news:10ad4hhq68jdv01@corp.supernews.com...
> docdwarf@panix.com wrote:
>
>
> It can be supported by my compiler...
>
> if mySwitchIsSet
> perform additionalSwitchTests
> if mySwitchIsSet
> next sentence
> else
> display "Switch cleared by additional tests"
> end-if
> end-if
>
> My compiler will not accept this code snippet (in proper context, of
> course). And paragraph 3.6.16 of the compiler's manual, syntax rule 3,
> states "If the END-IF phrase is specified, the NEXT SENTENCE phrase must
> not be specified."
>
> I agree with JerryMouse, if for no other reason than personal
> experience. CONTINUE always goes to the scope delimiter (I know it
> doesn't really "Go" anywhere, but that's the effect), and I've found it
> an acceptable replacement for NEXT SENTENCE.
>
> I really like the concept of NEXT SENTENCE working as a de facto EXIT
> PARAGRAPH statement - it's a shame our compiler doesn't interpret it
> that way.
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
> ~ / \ / ~ Live from Montgomery, AL! ~
> ~ / \/ o ~ ~
> ~ / /\ - | ~ LXi0007@Netscape.net ~
> ~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> ~ I do not read e-mail at the above address ~
> ~ Please see website if you wish to contact me privately ~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
>

LX-i

2004-05-15, 9:30 pm

William M. Klein wrote:

> So, I'll bet your compiler WILL accept the following (whether it is "good or
> bad" is another question)
>
> if mySwitchIsSet
> perform additionalSwitchTests
> if mySwitchIsSet
> If mySwtichIsSet
> next sentence
> else
> continue
> else
> display "Switch cleared by additional tests"
> end-if
> end-if

I'll try it Monday and let you know... :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

docdwarf@panix.com

2004-05-15, 10:30 pm

In article <10ad40nic3seu58@corp.supernews.com>,
LX-i <lxi0007@netscape.net> wrote:
>docdwarf@panix.com wrote:

[snip]

>
>That's fine - I've seen that in our code, even coded it some (though I
>usually use an inline perform now, when the table is in a copybook that
>I can't modify for "political" reasons).
>
>
>heh... Isn't fun working with folks whose minds are made up early?

About as fund as it is working in a world where pure water at sea level
boils at more-or-less 100 degrees centigrade, sure.

DD

docdwarf@panix.com

2004-05-15, 10:30 pm

In article <217e491a.0405151136.61d97cb1@posting.google.com>,
Richard <riplin@Azonic.co.nz> wrote:
>docdwarf@panix.com wrote
>
>
>How could that occur ?

I am not certain what you are referring to as 'that', Mr Plinston... were
you to ask the question in a different I might be able to address it.

>
>
>A convenient way of creating a bugtrap it certainly is.

Some consider an EXIT PARAGRAPH to be a valuable thing, Mr Plinston, and
can hardly wait to see it implemented.

>
>
>It certainly is the opinion of the Standards Committee (they are
>disallowed in the same structure), and there are very reasoned
>arguments to support the incompatability of these, mainly centred
>about your 'discovery' of the convenient bugtrap.

Mr Plinston, when the Standards Committee post here then they can post
their own reasoned arguments, when you post here you are welcome to do the
same.

DD

Don Leahy

2004-05-15, 11:30 pm

Use the "HILITE COBOL" ISPF editor command, which makes it much easier to
spot this type of error.

"William Bub" <fathafluff@hotmail.com> wrote in message
news:rgWoc.249467$e17.171934@twister.nyroc.rr.com...
> I just made the same coding error I made about two years age. I coded
> something like the following:
> PROCESS-PARAG.
> IF REC-TYPE = 1
> PERFORM EDIT-REC
> IF EDIT-ERR = 'Y'
> PERFORM HANDLE-ERROR
> END-IF
> PERFORM MORESTUFF
> .
> Every time REC-TYPE is not 1, MORESTUFF is not executed, even if EDIT-ERR
is
> not Y. Of course, I now see that I need a second END-IF after PERFORM
> HANDLE-ERROR. Does anyone know of a compiler option which will warn if IF
is
> not terminated by END-IF? Are there any utilities which will scan for this
> condition? Does anyone know a coding style which would make this type of
> error more difficult to make? Note: this is IBM mainframe.
>
>
>

LX-i

2004-05-16, 2:30 am

docdwarf@panix.com wrote:

>
>
> About as fun as it is working in a world where pure water at sea level
> boils at more-or-less 100 degrees centigrade, sure.

So you don't enjoy working with people who understand that they may not
know everything, so they keep open minds just in case? I'd rather work
with a learner than a know-it-all... :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

docdwarf@panix.com

2004-05-16, 8:30 am

In article <10ae039lsp5lj8c@corp.supernews.com>,
LX-i <lxi0007@netscape.net> wrote:
>docdwarf@panix.com wrote:
>
>
>So you don't enjoy working with people who understand that they may not
>know everything, so they keep open minds just in case? I'd rather work
>with a learner than a know-it-all... :)

Ahhhhh, have you been taking lessons from Mr Wagner? Your original
question was 'isn't it fun working with folks whose minds are made up
early?'... whether it is 'fun' or not, that such folks exist are, in my
experience, a Fact o' Nature... no more and no less that Other Kinds of
Folks are.

DD

SkippyPB

2004-05-16, 12:30 pm

On Sat, 15 May 2004 00:00:16 -0300, "Clark F. Morris, Jr."
<cfmtech@istar.ca> enlightened us:
[color=darkred]
>SkippyPB wrote:
>
>
>What IBM COBOL compiler has NEXT SENTENCE transferring control to other
>than the first statement following the period (full stop)? In the one
>period per paragraph style, NEXT SENTENCE could be used as an EXIT
>PARAGRAPH statement.

Based on the responses here, maybe I wasn't understood or maybe I
don't understand. Either way, my point is (using an example this
time), if I have the following IBM mainframe Cobol code:

If fldA = fldB
next sentence
else
move fldC to fldB.

Compute fldE = fldB + fldG.

As I've always understood Cobol, when the IF statement is true, next
sentece will send execution directly to the Compute statment.

If I had the following erroneous code:

If fldA = fldB
next sentence
else
move fldC to fldB

Compute fldE = fldB + fldG.

Move fldE to display-fldE.

When the IF statement is true, next sentence will send execution
directly to the Move statement.

Regards,

////
(o o)
-oOO--(_)--OOo-

I saved $300 in taxes this year but am paying
$300 more for gas. Bush giveth and his oil buddies
taketh it away.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

Richard

2004-05-16, 5:30 pm

docdwarf@panix.com wrote

[color=darkred]
> Mr Plinston, when the Standards Committee post here then they can post
> their own reasoned arguments, when you post here you are welcome to do the
> same.

If you wish.

The NEXT SENTENCE clause is not an EXIT PARAGRAPH, it is a transfer to
after the next full stop. Using END-IF allows for the reduction of
condition level without using a full stop. This combination allows
the execution of code at condition level zero (eg outside any IF) to
be controlled by the result of the IF.

In fact it can be considered to be a GO TO to an anonymous label at
the position of the next full stop. It is this complete anonymity
that is (one of) the problem with this contrived abuse of the
standard. Any full stop can be the target as long as it is the first
following the NEXT SENTENCE. This means that changing code outside
the scope of the IF statement(s) will affect the result of code inside
the IF.

Someone later maintaining the code can add a full stop knowing that
this is at lavel zero without noticing that they have fallen into the
bug trap.

This is especially a problem if the NEXT SENTENCE is contrived to
reach a point that is between the end of the IF and the end of the
paragraph, to an intermediate full stop. There is no indication, at
the full stop, that this is the case and so moving or removing, or
adding another, has no implicit restriction.

Richard

2004-05-16, 6:30 pm

SkippyPB <swiegand@neo.rr.NOSPAM.com> wrote

> Based on the responses here, maybe I wasn't understood or maybe I
> don't understand. Either way, my point is (using an example this
> time), if I have the following IBM mainframe Cobol code:

When code is written using ANS'74 standards (as your examples are)
then NEXT SENTENCE works unsurprisingly. The IF scope terminates at
the full stop which means that the next sentence starts at that same
point.

The issue is with the introduction of ANS'85 scope terminators the IF
can be terminated without using a full stop:

IF ( something )
PERFORM A
ELSE
PERFORM B
END-IF
PERFORM C

LX-i

2004-05-16, 7:30 pm

docdwarf@panix.com wrote:
> In article <10ae039lsp5lj8c@corp.supernews.com>,
> LX-i <lxi0007@netscape.net> wrote:
>
>
>
> Ahhhhh, have you been taking lessons from Mr Wagner? Your original
> question was 'isn't it fun working with folks whose minds are made up
> early?'... whether it is 'fun' or not, that such folks exist are, in my
> experience, a Fact o' Nature... no more and no less that Other Kinds of
> Folks are.

So you're saying that working with those folks is inevitable? That's
wasn't my question. :) I haven't changed what I asked - my original
question was "isn't it fun?" (of course, "fun" being a facetious
reference to the opposite...)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

LX-i

2004-05-16, 7:30 pm

SkippyPB wrote:

> I saved $300 in taxes this year but am paying
> $300 more for gas. Bush giveth and his oil buddies
> taketh it away.

Aren't you glad you saved that $300 in taxes? It would be a pain to be
out another $300...

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

docdwarf@panix.com

2004-05-16, 7:30 pm

In article <10afm7j5000n85f@corp.supernews.com>,
LX-i <lxi0007@netscape.net> wrote:
>docdwarf@panix.com wrote:
>
>So you're saying that working with those folks is inevitable?

No more or less than working with Other Kinds of Folks might be.

>That's
>wasn't my question. :)

Then perhaps that is why I did not answer that way.

>I haven't changed what I asked - my original
>question was "isn't it fun?" (of course, "fun" being a facetious
>reference to the opposite...)

Asked and answered above.

DD

docdwarf@panix.com

2004-05-16, 10:30 pm

In article <217e491a.0405161240.631d41d6@posting.google.com>,
Richard <riplin@Azonic.co.nz> wrote:
>docdwarf@panix.com wrote
>
>
>
>If you wish.

I stated what the Standards Committee can do when they post here, Mr
Plinston, and what you are welcome to do.

>
>The NEXT SENTENCE clause is not an EXIT PARAGRAPH, it is a transfer to
>after the next full stop.

When a paragraph is controlled via a PERFORM, Mr Plinston - as it might
well be when fall-through logic is avoided - and when there is only one
period per paragraph - as some folks code, for whatever reason they see
fit - then a NEXT SENTENCE executed control is passed back to the invoking
PERFORM, bypassing all further code in the paragraph.

When an EXIT PARAGRAPH is executed control is passed back to the invoking
PERFORM.

The fact of the NEXT SENTENCE's function under these conditions is that of
bypassing execution of subsequent code in the paragraph.

The fact of EXIT PARAGRAPH's function is to bypass execution of subsequent
code in the paragraph.

If the fact of NEXT SENTENCE's function under these conditions is
identical to an EXIT PARAGRAPH's function then the NEXT SENTENCE is 'being
such in effect' an EXIT PARAGRAPH.

'Being such in effect' is a definition of 'de facto'.

Under these conditions, then, a NEXT SENTENCE is a de facto EXIT
PARAGRAPH.

If there is an error in assumption, definition or logic in the above then
please, by all means, indicate it and demonstrate otherwise.

[snip]

>Someone later maintaining the code can add a full stop knowing that
>this is at lavel zero without noticing that they have fallen into the
>bug trap.

This seems, then, to be an argument against the 'one period/full stop per
pargraph' style.

DD

LX-i

2004-05-16, 11:30 pm

docdwarf@panix.com wrote:

> When an EXIT PARAGRAPH is executed control is passed back to the invoking
> PERFORM.
>
> The fact of the NEXT SENTENCE's function under these conditions is that of
> bypassing execution of subsequent code in the paragraph.
>
> The fact of EXIT PARAGRAPH's function is to bypass execution of subsequent
> code in the paragraph.
>
> If the fact of NEXT SENTENCE's function under these conditions is
> identical to an EXIT PARAGRAPH's function then the NEXT SENTENCE is 'being
> such in effect' an EXIT PARAGRAPH.
>
>
> This seems, then, to be an argument against the 'one period/full stop per
> pargraph' style.

It depends on how you look at it. To me, this is an argument for "EXIT
PARAGRAPH" as a valuable addition to the COBOL language. It would -not-
be broken by programmers of differing styles maintaining the same code,
whereas counting on NEXT SENTENCE to do the job would.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape