Home > Archive > Cobol > June 2005 > interesting use of NEXT SENTENCE vs. CONTINUE
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
interesting use of NEXT SENTENCE vs. CONTINUE
|
|
| Frank Swarbrick 2005-06-02, 3:55 pm |
| 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
| |
| Howard Brazee 2005-06-02, 3:55 pm |
|
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 includes
both the CONTINUE and the NEXT SENTENCE than if he restructured it so that the
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.
| |
| Richard 2005-06-02, 8:55 pm |
|
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 NEXT
> 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.
| |
| Chuck Stevens 2005-06-02, 8:55 pm |
|
"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
| |
| HeyBub 2005-06-02, 8:55 pm |
| 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.
| |
| docdwarf@panix.com 2005-06-02, 8:55 pm |
| 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...de=source&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
| |
| Frank Swarbrick 2005-06-03, 3:55 am |
| 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[color=darkred]
in[color=darkred]
>
>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[color=darkred]
>
>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
| |
| docdwarf@panix.com 2005-06-03, 8:55 am |
| 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
| |
| Frank Swarbrick 2005-06-03, 3:55 pm |
| Ah. I thought you were implying that there was some other way, considering
I had already pointed out there was one other way.
Any way... :-)
Frank
[color=darkred]
> Please clarify.
There is _never_ any need at all to add any GO TO.
As your example showed the code can be done by structuring.
| |
| Howard Brazee 2005-06-03, 3:55 pm |
|
On 2-Jun-2005, "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
> it's because....
>
> 1. I use EITHER scope delimiters OR full stops; never both. (OK, COBOL
> requires a full stop before a section or paragraph header but I see that as
> syntax rather than logic...). Mixing 'old' and 'new' COBOL does a disservice
> to both.
I use both. I don't consider full stops to be "mixed styles". But I use a
pre-compiler that puts in some if/else logic and like to make it very clear to
maintenance programmers that full stops are there.
> 2. I optimize logic before coding it and use whatever Booleans help me
> achieve that.
I do this too - except I also believe in the concept of maintaining code with
minimal changes. Often this results in logic that isn't the way I would code
that paragraph if I were starting from scratch.
| |
| Frank Swarbrick 2005-06-03, 3:55 pm |
| Top post only (my newsreader sucks)...
I do indeed like your solution! Although at first glance a NOT of a NOT
could be confusing. In fact, I'd probably make one additional change:
IF VPAY-CARD-SVC AND
DATE-OPEN >= DATE-40-DAYS-AGO
One big problem I had when looking at this is getting straight in my mind
just exactly what "IF DATE-OPEN < DATE-6-DAYS-AGO" means in "English". It
means "If the account was opened *more* than seven days ago, but it
*appears* at first glance to mean "If the account was opened less than six
days ago".
Of course changing the 7-day ago log to "AND (NOT DATE-OPEN >=
DATE-7-DAYS-AGO)" doesn't look right either.
What about "AND DATE-OPEN NOT >= DATE-7-DAYS AGO".
Nah, still confusing.
Anyway, beside the point...
As for our installation standards, while negated conditions are somewhat
discouraged, they are not forbidden, and they are used when the programmer
decides it makes the "cleanest" looking and easiest to understand code. As
for what this particular programmer was thinking at the time he did this
particular coding, I have no idea.
I personally don't like to use full-stops except where they are required.
But this applies only to new programs, or at least new paragraphs within an
existing program. If I'm modifying an existing paragraph I try to add code
in the same "style" as the existing code. I've seen people who don't follow
that rule screw things up too many times.
Oh, and that final GO TO? Good luck getting rid of that guy. Take a look
at these labels:
1000-PROCESS-DDA-MST.
1350-RSRV-FEE.
1350-INCREMENT-RSRV-FEE-DATE.
1350-RSRV-FEE-EXIT.
1400-PROCESS-DDA-STAT-FIELDS.
1400-PROC-DDA-STAT-FIELD-EXIT.
1405-CALC-WIRE-FEES-WAIVED.
1405-CALC-PCB-WIRE-FEES-WAIVED.
1405-CALC-PHN-WIRE-FEES-WAIVED.
1406-ACCUM-WAIVED-WIRE-FEES.
1406-EXIT-SECTION-1405.
1500-SWEEP-CASH-RESERVES-PMTS.
1500-SWEEP-CASH-RSRV-PMTS-EXIT.
1600-PROCESS-DDA-MST-RADV.
1601-CONTINUE-RSRV-INT.
1602-CONTINUE-RSRV-INT.
1610-PROC-DDA-M-RSRV-AUTO-PAY.
1612-PROCESS-NON-ACCRUALS.
1612-PROCESS-NON-ACCRUALS-EXIT.
1615-PROCESS-FINANCE-CHARGE.
1620-PROCESS-DDA-MST-SERVCG.
1630-PROCESS-DDA-MST-STMT1.
1640-PROCESS-DDA-MST-STMT2.
1640-AFTER-DEFERRED.
1640-CONTINUE.
1641-PDN-LOAD-LOOP.
1642-CONTINUE.
1650-PROCESS-DDA-MST-UPDATE.
1655-CONTINUE.
1660-PROCESS-DDA-MST-UPDATE.
1700-PROCESS-LARGE-BAL-CHANGE.
1800-PROCESS-ENDING-TOTALS-ADD.
1800-RSRV-FIXED-RATE-EXPIRE.
1800-CHECK-FOR-CHARGE-BACKS.
1800-ROTATE-CASH-OUT-2-3.
1800-CHECK-END-OF-MONTH.
1900-WRITE-1419-FILE.
1900-CONTINUE-WRITE-1419.
1000-PROCESS-DDA-MST-EXIT.
Basically, there are several places (outside of these labels) that do
PERFORM 1000-PROCESS-DDA-MST THRU 1000-PROCESS-DDA-MST-EXIT.
And within this huge set of paragraphs there are GO TO's to downstream
labels, there are PERFORM...THRU's of paragraphs imbedded within (for
example: "PERFORM 1400-PROCESS-DDA-STAT-FIELDS THRU
1400-PROC-DDA-STAT-FIELD-EXIT."), and there are PERFORM...THRU's of many
paragraphs that are outside of the 1000- start to 1000- exit labels.
There are 4533 lines in this huge section of paragraphs (and the entire
procedure division is 26855 lines, not including a few procedure division
copybooks). Now keep in mind this program was first implemented in 1978 and
possibly based on a predecessor version that was written in RPG-II, so I
tend to give it some leeway... :-)
All that being said, the program is still relatively simple to understand,
for the most part. At least the paragraph labels generally describe what
the code that follows is doing (at least to some extent).
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:3g8q52Fb2itjU1@individual.net...[color=darkred]
> 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.
>
Thanks for posting this, Frank.
It has generated some lively interest and, for myself, it made me stop and
think.
I couldn't understand why it left a bad taste in my mouth (in more than 20
years programming, all over the world, I've seen many different COBOL
'cultures' , but never this) and then I realised (after about 20 minutes)
why this has been considered necessary...
It isn't just about obviating a GO TO.
It is because two different styles have been MIXED.
And because installation standards have probably prohibited the use of
negated conditions.
I wondered why it is that, if given the same logical requirement, I
WOULDN'T
code it that way.
it's because....
1. I use EITHER scope delimiters OR full stops; never both. (OK, COBOL
requires a full stop before a section or paragraph header but I see that
as
syntax rather than logic...). Mixing 'old' and 'new' COBOL does a
disservice
to both.
2. I optimize logic before coding it and use whatever Booleans help me
achieve that.
Here's what I would do with the above...
* ****************************************
*********************
* * PRODUCE EXCEPTION FOR ACCOUNTS THAT HAVE NOT HAD ANY ***
* * TRANSACTIONS, NO CASH RESERVE AND HAVE BEEN OPEN AT ***
* * LEAST SEVEN DAYS ***
* ****************************************
*********************
IF NOT (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)
CONTINUE
ELSE
* ****************************************
*********************
IF VPAY-CARD-SVC AND
NOT (DATE-OPEN < DATE-40-DAYS-AGO)
CONTINUE
ELSE
* ****************************************
*********************
MOVE 'M' TO REPORT-CODE
+058 TO REPORT-RSN
PERFORM 6200-EXCEPT-OUTPUT THRU
6200-EXCEPT-OUTPUT-EXIT
MOVE 'C' TO MSTR-CODE-OVERDRAFT
GO TO PROCESS-LARGE-BAL-CHANGE *> I'd probably find a
way to remove this...
END-IF
END-IF
I believe this achieves the same logic as the original (obviously, I can't
check it, so I could be wrong) but it is simpler, and it should be COBOL
compliant.
Pete.
| |
| Andreas Lerch 2005-06-03, 3:55 pm |
|
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>
[color=darkred]
> * ****************************************
*********************
> 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
| |
| Chuck Stevens 2005-06-03, 3:55 pm |
|
"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
| |
| Frank Swarbrick 2005-06-03, 8:55 pm |
| Interesting. Did not know that. Don't think I would have ever actually
used it anyway, but...
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:3gb7otFbeumaU1@individual.net...
[color=darkred]
> 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
| |
| Richard 2005-06-03, 8:55 pm |
| > 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;
When looking at a paragraph label one can be sure that it _is_ the
target of one of: fall-through, goto, or perform, or else it is
unreachable code.
The actuality of the label triggers the need to determine which of
these potential constructs are actual paths.
>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...
Exactly, but the next programmer to work on this must either examine
the code using every possible context that can be constructed using
Cobol or will do so using a subset of contexts that: he is familar
with; are the site standard; he has seen before.
If someone is not familiar with the abuse that may be done to a NEXT
SENTENCE in the way shown then it will not be in his list of 'contexts
I need to look for'. OTOH if he is to examine every possible context
then each full stop will require a scan for a next sentence above, and
every GOTO will require a scan for an alter.
In a similar way the elimination of GO TO and THRU is a mechanism to
reduce the number of contexts so that the program can be more easily
understood in smaller pieces.
| |
| docdwarf@panix.com 2005-06-03, 8:55 pm |
| In article <1117828199.855793.254140@z14g2000cwz.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>When looking at a paragraph label one can be sure that it _is_ the
>target of one of: fall-through, goto, or perform, or else it is
>unreachable code.
>
>The actuality of the label triggers the need to determine which of
>these potential constructs are actual paths.
Midsentence interruption does not, in my experience, promote clarity...
but be that as it may the existence of a period/full stop appears to have
the same actuality; either one gets to it by previous execution or one
gets around it by a NEXT SENTENCE.
>
>
>Exactly, but the next programmer to work on this must either examine
>the code using every possible context that can be constructed using
>Cobol or will do so using a subset of contexts that: he is familar
>with; are the site standard; he has seen before.
All human beings I have met are limited by their experiences, yes.
>
>If someone is not familiar with the abuse that may be done to a NEXT
>SENTENCE in the way shown then it will not be in his list of 'contexts
>I need to look for'.
I do not understand what you are calling 'abuse'; a NEXT SENTENCE, in my
experience, does what the Standards say it should do and what every
textbook I have ever read say it should do.
>OTOH if he is to examine every possible context
>then each full stop will require a scan for a next sentence above, and
>every GOTO will require a scan for an alter.
Perhaps my education was different but I was taught that this is part and
parcel of writing and maintaining code; from the very first compile I was
taught 'allow for the possibility of the mistake being in the line before
the one that says it is giving trouble.' Have things changed so very
much?
>
>In a similar way the elimination of GO TO and THRU is a mechanism to
>reduce the number of contexts so that the program can be more easily
>understood in smaller pieces.
In an earlier sentence I stated ' 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'... but without
any indication of editing you saw fit to snip out the clause following the
semicolon.
My apologies, once again, if I have trodden unknowingly on your faith.
DD
| |
| Richard 2005-06-04, 3:55 am |
| > I do not understand what you are calling 'abuse'; a NEXT SENTENCE, in my
> experience, does what the Standards say it should do and what every
> textbook I have ever read say it should do.
A NEXT SENTENCE in the same IF as an END-IF is abuse because the
standard specifically disallows it.
> if I have trodden unknowingly on your faith.
'Faith' is a belief in something in spite of the evidence. Knowledge is
a belief in something _because_ of the evidence.
My stance is entirely that code can be determined by evidence, no faith
is required. I don't assume that there may be or may not be a next
sentence, an alter, or even a GO TO, I can do a text search to
determine absence. Once absence is established then the contexts that
can only occur when these constructs exist can be ignored.
OTOH if those constructs do exist then the contexts that can occur are
much more varied and complex.
| |
| William M. Klein 2005-06-04, 3:55 am |
| "Richard" <riplin@Azonic.co.nz> wrote in message
news:1117851012.574197.212860@g47g2000cwa.googlegroups.com...
>
> A NEXT SENTENCE in the same IF as an END-IF is abuse because the
> standard specifically disallows it.
>
The "Standard" also disallows GoBack - and if you asked (IBM) mainframe people
to "give that up" because it was "abuse" - you would be in REAL trouble.
Also, COMP-5 (and COMP-3 and COMP-4) are all "abuse" by this definition.
So is POINTER (in the '85 Standard) and "SET ADDRESS OF" a data-item WITHOUT the
"BASED" clause.
So is REDEFINES of the "non-original" data item.
So is CALL using of a "group-item" that isn't an 01-level (until the '02
Standard).
Should I go on?
***
I understand the "claim" that many (possibly even MOST) COBOLprogrammers don't
understand the difference between a CONTINUE and a NEXT SENTENCE. Furthermore,
I understand that having a NEXT SENTENCE in the *same* IF as an END-IF (or
SEARCH with END-SEARCH) may not be portable.
HOWEVER, for shops that "suipport" both NEXT SENTENCE (with END-IF) and
CONTINUE, the difference IS "well understood" - and maintainable.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| William M. Klein 2005-06-04, 3:55 am |
| No, I can't.
ANYTHING can be introduced as an EXTENSION to the Standard - that the
implementor wants AND they remain "conforming".
Richard,
I think you do (or have) used Micro Focus compilers. Open *any* Micro Focus
LRM and look for the text,
"This rule" and " enforced" or "relaxed" or "removed"
and you will find many, MANY cases where text such as:
"This rule is not enforced."
It will always (usuall?) have an "MF" bubble - and often have various other
dialect bubbles.
To be a "valid" extension to the ANSI/ISO Standard it must:
A) be documented
B) must be "flagged" when the (optional) flagging mechanism (FLAGSTD for both
IBM and MF) is turned on
***
A clasic example - from the '85 Standard (ignored - as an extension - by most
'85 Standard compilers that I know of) is the fact that one *MUST* specify
(implicit or explicitly) either a "declarative" or a "file-status field" for
every file.
Another medium "common" extension is the rule (again '85 Standard) that one MUST
have a procedure-header at the beginning of the Procedure Division.
Again, there are LOTS of rules of what you "must" and "must not" do in the
Standard - and almost (not quite) all of them are ignored, removed, not
enforced, or whatever as EXTENSIONS by one or more vendor.
--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1117863336.941688.184770@f14g2000cwb.googlegroups.com...
>
> As far as I can tell the standard never mentions GOBACK (until '02 when
> it allows it).
>
>
> Is _explicitly_ disallowed.
>
> Perhaps you cannot tell the difference between between never mentioning
> something and specifying it is not to be used.
>
| |
| Richard 2005-06-04, 8:55 am |
| > No, I can't.
Well come back when you can.
> A clasic example - from the '85 Standard (ignored - as an extension - by most
> '85 Standard compilers that I know of) is the fact that one *MUST* specify
> (implicit or explicitly) either a "declarative" or a "file-status field" for
> every file.
I don't believe that is actually part of the standard.
[rant deleted]
If I wish to call any particular construct an 'abuse' then I will do
so, and I will not put up with censorship telling me that I cannot say
that.
I think that you are  . A READ statement, for example, must
specify AT END or INVALID KEY if no USE procedure is specified, but if
these are included on each READ there is no requirement to have a
file-status or a use procedure.
| |
| Jeff York 2005-06-04, 8:55 am |
| Lots and lots and lots of debate deleted....
When one reads long and increasingly abstruse arguments over
"interpretation" of the action of a verb - as so wondrously rehearsed
in this thread - one is forced to the realisation that: "love it or
hate it, and whatever the late Dr Djikstra said about it, 'GO TO' at
least has the attribute of being unambiguous!". :-)
--
Jeff. Ironbridge, Shrops, U.K.
jeff@xjackfieldx.org (remove the x..x round jackfield for return address)
and don't bother with ralf4, it's a spamtrap and I never go there.. :)
.... "There are few hours in life more agreeable
than the hour dedicated to the ceremony
known as afternoon tea.."
Henry James, (1843 - 1916).
| |
| docdwarf@panix.com 2005-06-04, 3:55 pm |
| In article <1117851012.574197.212860@g47g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>A NEXT SENTENCE in the same IF as an END-IF is abuse because the
>standard specifically disallows it.
Are you saying, then, that extensions beyond the standard - such as
allowing NUMERIC checks against other than alphanumeric or display-numeric
fields - are abuse?
>
>
>'Faith' is a belief in something in spite of the evidence. Knowledge is
>a belief in something _because_ of the evidence.
Really? I was using
http://m-w.com/cgi-bin/dictionary?b...ionary&va=faith as my source,
specifically 2 b (1) : firm belief in something for which there is no
proof (2): complete trust. What is the source of the definitions you are
using above, please?
DD
| |
| docdwarf@panix.com 2005-06-04, 3:55 pm |
| In article <1117874000.565517.100420@g44g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
[snip]
>If I wish to call any particular construct an 'abuse' then I will do
>so, and I will not put up with censorship telling me that I cannot say
>that.
From http://www.bartleby.com/66/25/10625.html :
--begin quoted text:
"When I use a word," Humpty Dumpty said, in a rather scornful tone, "it
means just what I choose it to mean - neither more nor less."
--end quoted text
DD
| |
| William M. Klein 2005-06-04, 3:55 pm |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1117874000.565517.100420@g44g2000cwa.googlegroups.com...
>
> Well come back when you can.
>
>
> I don't believe that is actually part of the standard.
>
You're right, I was thinking of the text,
"If the AT END phrase is not specified, a USE AFTER STANDARD EXCEPTION procedure
must be associated with this file-name-l, and that procedure is executed."
It was so commonly "violated" as an extension, that I forgot what the "real"
rule was.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| William M. Klein 2005-06-04, 3:55 pm |
| "Richard" <riplin@Azonic.co.nz> wrote in message
news:1117874000.565517.100420@g44g2000cwa.googlegroups.com...
>
<snip>
>
> If I wish to call any particular construct an 'abuse' then I will do
> so, and I will not put up with censorship telling me that I cannot say
> that.
>
Certainly, you may call anything "abuse" that you want to call abuse. HOWEVER,
when you (not I) state,
"A NEXT SENTENCE in the same IF as an END-IF is abuse because the standard
specifically disallows it."
The I will continue to question THIS definition (and its applicability) because
of all the (many) other things the standard specifically disallows" and which I
*question* that you consider "abuse". This is not "censorship" - this is
questioning term and definition.
****
I used to say (in the days of the NIST certificaiton tests) that some PL/I
compilers with their built-in macro/preprocessor COULD pass the COBOL
certification tests. However, if I had stated that this made them a "COBOL
compiler" - I think people would have been right to question my use of the term
and its definition.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Richard 2005-06-04, 3:55 pm |
| > I will continue to question THIS definition (and its applicability) because
> of all the (many) other things the standard specifically disallows"
None of which you have shown as an example, even though you claimed it.
Show me where it states that "COMP-5 must not be used" or any of the
other items you claimed.
| |
| Richard 2005-06-04, 3:55 pm |
| >> A NEXT SENTENCE in the same IF as an END-IF is abuse because the
[color=darkred]
> Are you saying, then, that extensions beyond the standard - such as
> allowing NUMERIC checks against other than alphanumeric or display-numeric
> fields - are abuse?
Does the standard state that this "must not be specified" ?
Or does it states that it cannot be used only because a sign may give a
false result ?
| |
| docdwarf@panix.com 2005-06-04, 3:55 pm |
| In article <1117897222.358113.249260@g49g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>
>Does the standard state that this "must not be specified" ?
Answering a question with a question, Mr Plinston, is no answer at all.
>
>Or does it states that it cannot be used only because a sign may give a
>false result ?
See above about answering a question with a question.
DD
| |
| Richard 2005-06-04, 8:55 pm |
| > Answering a question with a question, Mr Plinston, is no answer at all.
Then, if you cannot work out the answer to your questions from my
response then you do not deserve an answer at all.
| |
| Richard 2005-06-04, 8:55 pm |
| >> 'Faith' is a belief in something in spite of the evidence.
>: firm belief in something for which there is no proof
What distinction are you attempting to draw here ? Do you think that
there can be 'proof' without 'evidence' ? That would sound like 'faith'
to me.
| |
| William M. Klein 2005-06-04, 8:55 pm |
| the exact words from the '85 Standard are:
"The NUMERIC test cannot be used with an item whose data description describes
the item as alphabetic or as a group item composed of elementary items whose
data description indicates the presence of operational sign(s)."
So, to me that means "must not be specified"
For an example of where the Standard uses those EXACT words and Micro Focus (for
example) has an extension, see:
"The clauses SYNCHRONIZED, ... must not be specified except for an elementary
data item."
(MF allows it at a group level)
***
also:
"The OCCURS clause must not be specified in a data description entry that: ..."
MF allows it at the 01-level. MF and IBM allows them to be "nested" (See MF
ODOSLIDE directive)
***
Also,
"The VALUE clause must not be specified in the Linkage Section"
Allowed by MF, IBM, and many other compilers.
--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1117897222.358113.249260@g49g2000cwa.googlegroups.com...
>
>
> Does the standard state that this "must not be specified" ?
>
> Or does it states that it cannot be used only because a sign may give a
> false result ?
>
| |
| docdwarf@panix.com 2005-06-04, 8:55 pm |
| In article <1117911602.925392.24120@f14g2000cwb.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>Then, if you cannot work out the answer to your questions from my
>response then you do not deserve an answer at all.
When you give no answer at all, Mr Plinston, then I will accept it as your
having given no answer; to do otherwise might be manufacturing my own
responses and that is not, usually, a motivating factor in my attempts at
communications with others.
DD
| |
| docdwarf@panix.com 2005-06-04, 8:55 pm |
| In article <1117911763.892819.16850@g14g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>
>What distinction are you attempting to draw here ?
The one which might be most readily apparent, Mr Plinston; 'in spite of
evidence' does not equal, last I looked, 'for which there is no proof'...
you might wish to spend some time pondering the difference between the
two, it might be fruitful.
DD
| |
| Peter Lacey 2005-06-04, 8:55 pm |
| Jeff York wrote:
>
> Lots and lots and lots of debate deleted....
>
> When one reads long and increasingly abstruse arguments over
> "interpretation" of the action of a verb - as so wondrously rehearsed
> in this thread - one is forced to the realisation that: "love it or
> hate it, and whatever the late Dr Djikstra said about it, 'GO TO' at
> least has the attribute of being unambiguous!". :-)
>
> --
> Jeff. Ironbridge, Shrops, U.K.
> jeff@xjackfieldx.org (remove the x..x round jackfield for return address)
> and don't bother with ralf4, it's a spamtrap and I never go there.. :)
>
> ... "There are few hours in life more agreeable
> than the hour dedicated to the ceremony
> known as afternoon tea.."
>
> Henry James, (1843 - 1916).
>
>
Hear, hear, that Jeff York!
"The hours a man spends fishing are not deducted from his allotted
lifespan". Thoreau? Henry Ford? A. Nonymous?
PL
| |
| Richard 2005-06-04, 8:55 pm |
| > So, to me that means "must not be specified"
I cannot be held responsible for how you misinterpret particular
statements. In fact I insist that I _must_not_ be held responsible.
I, for example _can_ see that there is a distinction between:
"You can not walk on water".
"You must not walk on the grass".
"You should not walk barefoot on broken glass".
If you think that they convey the same imperitive, then try switching
the phrases around and see if they still make sense. If you cannot see
the distinction, then you cannot.
> an example of where the Standard uses those EXACT words
At last you have stopped just making things up.
> "The clauses SYNCHRONIZED, ... must not be specified ...
> "The OCCURS clause must not be specified ...
> "The VALUE clause must not be ...
Thank you for pointing those out, I will take these particular issues
into consideration should I ever be bothered to make up a new list of
things that I think abuse the language.
| |
| Richard 2005-06-04, 8:55 pm |
| > you might wish to spend some time pondering the difference between the two,
Only after you have proven that you can have proof without evidence, or
proof contrary to evidence, then there may actually be something to
ponder.
| |
| Richard 2005-06-04, 8:55 pm |
| > to do otherwise might be manufacturing my own responses
Yes, that would require thoughtful consideration of why I questioned
your precepts, it is probably best that you don't attempt that.
| |
| docdwarf@panix.com 2005-06-05, 3:55 am |
| In article <1117919941.178527.96020@o13g2000cwo.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>Yes, that would require thoughtful consideration of why I questioned
>your precepts, it is probably best that you don't attempt that.
You did not 'question my precepts', Mr Plinston, you answered a question
with a question, which is no answer at all... but is that how you see it?
How very interesting... good that you revealed it, it might help clarify
much.
DD
| |
| docdwarf@panix.com 2005-06-05, 3:55 am |
| In article <1117919556.970722.110140@g43g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>Only after you have proven that you can have proof without evidence, or
>proof contrary to evidence, then there may actually be something to
>ponder.
When I make either of those assertions, Mr Plinston, I shall do my best to
document how I came to them... but I did not realise that I had so much
control over your actions, that you would predicate what you do based on
what I did.
DD
| |
| Pete Dashwood 2005-06-05, 8:55 am |
|
<docdwarf@panix.com> wrote in message news:d7s7o9$6ol$1@panix5.panix.com...
> In article <1117874000.565517.100420@g44g2000cwa.googlegroups.com>,
> Richard <riplin@Azonic.co.nz> wrote:
>
> [snip]
>
>
> From http://www.bartleby.com/66/25/10625.html :
>
> --begin quoted text:
>
> "When I use a word," Humpty Dumpty said, in a rather scornful tone, "it
> means just what I choose it to mean - neither more nor less."
>
> --end quoted text
From memory... (might be slightly off; I stored it when I was a child...)
"The question is", replied Alice, "whether you CAN use words that way."
"The question is", said Humpty Dumpty, "who is to be the master, that is
all."
Richard has a perfect right to call something he considers 'abuse' ....
'abuse'.
Bill has a perfect right to say, "No, it isn't."
Both can present their arguments and the Doc has a perfect right to point
out that it is purely a semantic argument.
I have a perfect right to comment on the whole process.
And you, gentle reader, have a perfect right to ignore the whole tedious
thread. Or not...
My advice: Don't use NEXT SENTENCE.... ever. It is a stupid and unnecessary
inclusion in the COBOL language. It is NEVER required, UNLESS you (or your
installation) forbids the use of negated conditions.
If you are a poor unfortunate who works on a site where they force you to
work with blunt tools in this way (usually because the Management can't get
their heads around Boolean Algebra), look for another job...
If you are a 'programmer' who believes that Boolean operators (specifically,
NOT) in conditionals are a bad thing; look for another job...you are not
REALLY suited to computer programming...and calling yourself a 'programmer'
may be offensive to those of us who actually are...
Ah, Democracy and Freedom of Speech...there's nothing like speaking your
mind on a sunny Sunday... :-)
Pete.
| |
| docdwarf@panix.com 2005-06-05, 3:55 pm |
| In article <3gfukvFc4h3qU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:d7s7o9$6ol$1@panix5.panix.com...
>
>From memory... (might be slightly off; I stored it when I was a child...)
>
>"The question is", replied Alice, "whether you CAN use words that way."
>
>"The question is", said Humpty Dumpty, "who is to be the master, that is
>all."
>
>Richard has a perfect right to call something he considers 'abuse' ....
>'abuse'.
That depends, Mr Dashwood, on how one defines a 'right'.
>
>Bill has a perfect right to say, "No, it isn't."
See above.
>
>Both can present their arguments and the Doc has a perfect right to point
>out that it is purely a semantic argument.
Well... it *is* a discussion about language (English) being used to
describe language (COBOL).
>
>I have a perfect right to comment on the whole process.
Above again.
>
>And you, gentle reader, have a perfect right to ignore the whole tedious
>thread. Or not...
Looky yonder, up there!
>
>My advice: Don't use NEXT SENTENCE.... ever.
I've heard that said about SEARCH, internal SORTs, GO TO and PERFORM THRU;
such advices have been labelled here, previously, as the basis of
'religious wars'.
>It is a stupid and unnecessary
>inclusion in the COBOL language.
.... and beloved by poopie-heads? It is a construct which transfers
control of execution to code following the next full stop/period (barring
paragraph intervention), nothing more, nothing less.
>It is NEVER required, UNLESS you (or your
>installation) forbids the use of negated conditions.
Ahhhhh... 'required'? Now *there's* a curious word. As mentioned before,
I've worked in shops where SEARCH was forbidden... and we worked around
it. Likewise with internal SORTs, also forbidden, also worked around. I
recall being regaled by a greyhead with Tales of the Oldene Dayse, when
they put together a system for airline reservations using only RR
(register-to-register) instructions because they were the fastest... and
they worked around the other ones.
It has been said that tools are devoid of values and intelligence; it is
the uses to which they are put which can be labelled 'decent' or
'stupid'... a hammer can be used to build or destroy. Language constructs
may be seen in a similar fashion.
>
>If you are a poor unfortunate who works on a site where they force you to
>work with blunt tools in this way (usually because the Management can't get
>their heads around Boolean Algebra), look for another job...
I recall, Mr Dashwood, different Oldene Dayse when computer speed was
*very* costly; NEXT SENTENCE and GO TO -EXIT were beloved of those who
wanted to save CPU-cycles. Some readers might be so young as to consider
these days nearly as recent as those of the horse-and-buggy... but others
will sigh and say 'Ahhhhh, yes... those were the Oldene Dayse, when a
coder could code code such as *ten* coders could not, today!'
Now I am not saying that machine time is of the same weight in the
Equation of Programming Factors nowadays... but... here's the sly part...
not only is code written in those days still running happily (Mr Swarbrick
indicated the program saw its first incarnation in 1978) BUT... is it not
a Good Thing to keep later modifications as close to the style of the
running code as possible?
The conclusion will be left as an exercise for the reader.
DD
| |
| Pete Dashwood 2005-06-05, 3:55 pm |
| Please note: This is a long (though hopefully entertaining) post about why
you should or shouldn't use NEXT SENTENCE.
It contains at least one COBOL example.
It discusses some points raised by the Doc.
It includes some nostalgia.
It assumes that your installation has NOT banned the use of Boolean
operatives in COBOL. (You can use negated conditions at the very least...)
So now you know what's in it, there's no need for you to read it, so why not
go and do something else?
<docdwarf@panix.com> wrote in message news:d7urar$87e$1@panix5.panix.com...
> In article <3gfukvFc4h3qU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
news:d7s7o9$6ol$1@panix5.panix.com...[color=darkred]
>
> That depends, Mr Dashwood, on how one defines a 'right'.
>
How could you define the word "right" in such a manner that Richard cannot
say he considers something 'abuse', Bill can't disagree with him, you can't
interfere, and I can't either, in what is an open unmoderated internet forum
where there is no requirement for participation other than a news group
connection and the desire to do so?
The right to post here is implicit in the fact that it is open, and
unmoderated. No one participant has any more weight or "right" than any
other.
>
> See above.
>
>
> Well... it *is* a discussion about language (English) being used to
> describe language (COBOL).
>
Exactly.
>
> Above again.
>
>
> Looky yonder, up there!
>
>
> I've heard that said about SEARCH, internal SORTs, GO TO and PERFORM THRU;
> such advices have been labelled here, previously, as the basis of
> 'religious wars'.
>
Ah, yes, but I'm an atheist so I don't participate in religious wars.
(Except the ones where people are forcing religious views on me...) The
above is clearly labelled as 'my advice'. I really don't care whether it is
taken or not, and have no intention of going to a religious or any other
kind of war over it.
>
> ... and beloved by poopie-heads?
Hmmm... I have yet to meet a poopie-head so I am entirely uninformed as to
what they like or don't like.
> It is a construct which transfers
> control of execution to code following the next full stop/period (barring
> paragraph intervention), nothing more, nothing less.
>
Not quite.
The transfer of control is to the first EXECUTABLE COBOL STATEMENT following
the full stop/period. (If there isn't one, execution results are
indeterminate for most implementations I've ever worked with. This is the
famous 'dropped out of the program.' Never experienced it myself, but I've
helped people who have...)
The 'barring paragraph intervention' is inaccurate, because a paragraph name
MUST be preceded by a full stop/period. You only needed that particular
qualification because you neglected to note the transfer of control is to
executable code.
Irrespective of what it actually does, my comment was that it is unnecessary
(provided you use the full Boolean capabilities of the language.)
>
There... I said it again... :-)
> Ahhhhh... 'required'? Now *there's* a curious word. As mentioned before,
> I've worked in shops where SEARCH was forbidden... and we worked around
> it.
And I'm sure you fully understand the difference between 'forbidden' and
'required'. The fact that certain constructs in certain shops are forbidden,
has nothing whatsoever to do with the fact that NEXT SENTENCE is simply not
necessary (required) in the language.
Show me a construct that uses NEXT SENTENCE and I'll rewrite it so it
doesn't. (I already did that in this thread, but people are much more
interested in arguing the meaning of the standard (as if that was
pertinent....) than in discussing Frank's code sample and the implications
of removing this ugly, redundant construct.
>Likewise with internal SORTs, also forbidden, also worked around.
Me too. It's irrelevant to the NEXT SENTENCE case I am making.
The difference is that installations ban things for many reasons. Usually it
is because there is a lack of understanding about how to use it (but not
always).
Personally, I don't really care whether people use NEXT SENTENCE at all, use
it in a manner that violates the standards, use it in a manner that renders
it non-portable, or don't use it. It is only computer programming, and COBOL
at that. I stated my opinion for the benefit of those who are newcomers;
notice I did NOT say it should be banned. All I said was that I would advise
people not to use it. Grounds for this are that there is no need to use it
and it is ugly. (last is certainly a subjective value judgement, but that's
what I think.) In forty years I have never coded it, as far as I can recall.
I seem to remember being annoyed that it might be necessary when I first
started using SEARCH but then I found that the WHEN statements function
perfectly OK without it.
> I recall being regaled by a greyhead with Tales of the Oldene Dayse, when
> they put together a system for airline reservations using only RR
> (register-to-register) instructions because they were the fastest... and
> they worked around the other ones.
>
Yep, I think most people who were around at that time could tell similar
stories, and across different platforms also. I remember writing a program
in 1900 assembler (PLAN) that ONLY used the BOOLEAN functions AND, OR, NOT,
and XOR, plus EXECUTE, for a bet. My point was that that's all the hardware
can do and everything else is derived from that. The program read cards and
printed a report by building the instructions in memory using the functions
mentioned. It was silly and I wouldn't do it now, but I was young and had
just discovered propositional calculus...:-)
We all got used to doing 'work arounds' but it was more often because of
limitations in software/hardware, rather than stupid restrictive standards.
(Having said that, I have certainly worked in places where the standards
were both restrictive and stupid and programmers did the job in spite of the
standards, instead of being assisted by them.)
> It has been said that tools are devoid of values and intelligence; it is
> the uses to which they are put which can be labelled 'decent' or
> 'stupid'... a hammer can be used to build or destroy. Language constructs
> may be seen in a similar fashion.
>
Certainly. But I wouldn't use a hammer unless I needed a hammer. I don't
need NEXT SENTENCE (and I am satisfied from my own research that NOBODY
needs it in COBOL) , so I don't use it. I further would admonish others not
to use it (and I have, above), but I would not enforce that opinion on
anyone, even if the installation standards were my responsibility. (And
there have been times and places when they were...)
get[color=darkred]
>
> I recall, Mr Dashwood, different Oldene Dayse when computer speed was
> *very* costly; NEXT SENTENCE and GO TO -EXIT were beloved of those who
> wanted to save CPU-cycles.
Sorry Doc, I was there in those Oldene Dayse too. GO TO was certainly a fast
instruction (unconditional branch is often the fastest instruction in most
instruction sets.), but NEXT SENTENCE never saved anything. It simply
generated an unconditional branch where negating the condition removed the
need for it.
Consider...
IF condition
NEXT SENTENCE
ELSE
do this and this and this. <=== note full stop/period
the condition wasn't true so do this
....as opposed to ...
IF NOT condition
do this and this and this. <=== note full stop/period
the condition wasn't true so do this
As one of 'those who wanted to save CPU-cycles' that construct was
certainly NOT beloved by me.
(Nowadays a good optimizing compiler would generate identical code for both
constructs, but not in Oldene Dayse. On at least one platform I worked with
(Burroughs B500) the machine code generated by COBOL 'IF', ALWAYS generated
code for the ELSE branch (whether you used it or not) so you had a five
instruction overhead before you started...)
> Some readers might be so young as to consider
> these days nearly as recent as those of the horse-and-buggy... but others
> will sigh and say 'Ahhhhh, yes... those were the Oldene Dayse, when a
> coder could code code such as *ten* coders could not, today!'
>
....and we did :-)
> Now I am not saying that machine time is of the same weight in the
> Equation of Programming Factors nowadays... but... here's the sly part...
> not only is code written in those days still running happily (Mr Swarbrick
> indicated the program saw its first incarnation in 1978) BUT... is it not
> a Good Thing to keep later modifications as close to the style of the
> running code as possible?
>
Definitely. But not to the point of perpetuating bad practice. If I was
maintaining COBOL code and it contained NEXT SENTENCE (in the sections I was
working on; I would not go on a cru e through the code, because it really
isn't THAT important...), I would remove it, exactly as I did in Frank's
original sample posted at the start of this thread. The code is simpler
without it. (Code that is tighter - fewer statements in it - is generally
(not always) simpler and easier to maintain.)
> The conclusion will be left as an exercise for the reader.
>
Yes, it will. I have said everything I want to say about NEXT SENTENCE and
would be unlikely to respond further... :-)
Pete.
| |
| William M. Klein 2005-06-05, 3:55 pm |
| (see bottom)
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:3ggk9aFbdacjU1@individual.net...
> Please note: This is a long (though hopefully entertaining) post about why
> you should or shouldn't use NEXT SENTENCE.
>
<snip>
>
> Sorry Doc, I was there in those Oldene Dayse too. GO TO was certainly a fast
> instruction (unconditional branch is often the fastest instruction in most
> instruction sets.), but NEXT SENTENCE never saved anything. It simply
> generated an unconditional branch where negating the condition removed the
> need for it.
>
> Consider...
>
> IF condition
> NEXT SENTENCE
> ELSE
> do this and this and this. <=== note full stop/period
> the condition wasn't true so do this
>
> ...as opposed to ...
>
> IF NOT condition
> do this and this and this. <=== note full stop/period
> the condition wasn't true so do this
>
At some (IBM) mainframe shops with their '74 Standard compiler (without a 3rd
party add-on product) there was (significant?) performance advantage in placing
the "most commonly encountered" condition FIRST. Therefore, the "NEXT SENTENCE"
construct 8did* perform better than the 2nd (which actually only has one test -
no "ELSE"). I cannot remember what type of "object code" it created, but I do
remember the need for such code. It is POSSIBLE that my memory has the "first
condition - most common" and the "don't use negative logic" requirements mixed
up, but it is my memory that that the first code performed better than the 2nd.
There is NO doubt in my mind that they are "logicallly equivalent".
P.S. In case it isn't clear from this or the other thread:
A) I do NOT recommend the use of "NEXT SENTENCE" which is currently classified
as "Archaic" in the ISO Standard
B) I do NOT object to anyone calling this (or anything else they want) "abuse"
C) I DO *disagree* with those who call "NEXT SENTENCE" with END-IF an ABUSE
"because the Standard disallows it" - but do not call all OTHER (equally valid)
extensions "abuse". (Note: "disagree" is NOT the same as saying that they can't
so label it in this public forum)
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Richard 2005-06-05, 8:55 pm |
| > Mr Dashwood, different Oldene Dayse when computer speed was
> *very* costly; NEXT SENTENCE and GO TO -EXIT were beloved of those who
> wanted to save CPU-cycles.
Actually, I very much doubt that either would be used to 'save CPU
cycles', they were used because there was inadequate methods of
constructing code without using these. Specifically, they were used
because there were no scope terminators and Continue.
| |
| Richard 2005-06-05, 8:55 pm |
| > At some (IBM) mainframe shops with their '74 Standard compiler
A '74 compiler cannot have END-IF. Therefore there cannot be a NEXT
SENTENCE in an imperitive IF statement. NEXT SENTENCE would do no more
nor no less than what a CONTINUE does.
> there was (significant?) performance advantage in placing
> the "most commonly encountered" condition FIRST. Therefore, the
> "NEXT SENTENCE" construct 8did* perform better than the 2nd (which actually
> only has one test - no "ELSE").
That is complete nonsense. In a '74 compiler NEXT SENTENCE has nothing
to do with ordering conditions. It merely acted as a place holder when
there would otherwise be a null statement.
> I cannot remember what type of "object code" it created, but I do
> remember the need for such code. It is POSSIBLE that my memory has the "first
> condition - most common" and the "don't use negative logic" requirements mixed
> up, but it is my memory that that the first code performed better than the 2nd.
I think that you have these mixed up. You may well use NEXT SENTENCE
(or in a modern compiler CONTINUE) to avoid 'negative logic' but this
has nothing to do with 'first condition' or saving CPU cycles.
It also have _nothing_ to do with the abuse of using NEXT SENTENCE in
an imperitive IF (in '85) in order to jump to an anoymous point in the
midst of zero scope level code.
> There is NO doubt in my mind that they are "logicallly equivalent".
In other's minds, such as J4, one particular item you see as 'logically
equivalent' is marked "must not be specified".
> B) I do NOT object to anyone calling this (or anything else they want) "abuse"
You put up a pretty good approximation of that.
> C) I DO *disagree* with those who call "NEXT SENTENCE" with END-IF an ABUSE
> "because the Standard disallows it" - but do not call all OTHER (equally valid)
> extensions "abuse".
That is complete bullshit. I can label anything that _I_ want to as
abuse and I have provided good reasons why I do so, and it is not just
that it is marked "must not". If _you_ want other things to be called
abuse by you or anyone else then come up with your own _reasons_ for
doing that - without just making stuff up.
There is in fact no relationship between this being abuse and this
being an extension beyond that without the extension the compiler will
reject it. Whether I may or may not care about other constructs or
other extensions is irrelevant.
| |
| William M. Klein 2005-06-05, 8:55 pm |
| Richard,
When you TOTALLY remove the context for a reply, YOUR reply makes no sense.
Please repost *with* context (showing what Pete posted and what I replied to).
--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1118005868.310723.98950@g43g2000cwa.googlegroups.com...
>
> A '74 compiler cannot have END-IF. Therefore there cannot be a NEXT
> SENTENCE in an imperitive IF statement. NEXT SENTENCE would do no more
> nor no less than what a CONTINUE does.
>
>
> That is complete nonsense. In a '74 compiler NEXT SENTENCE has nothing
> to do with ordering conditions. It merely acted as a place holder when
> there would otherwise be a null statement.
>
>
> I think that you have these mixed up. You may well use NEXT SENTENCE
> (or in a modern compiler CONTINUE) to avoid 'negative logic' but this
> has nothing to do with 'first condition' or saving CPU cycles.
>
> It also have _nothing_ to do with the abuse of using NEXT SENTENCE in
> an imperitive IF (in '85) in order to jump to an anoymous point in the
> midst of zero scope level code.
>
>
> In other's minds, such as J4, one particular item you see as 'logically
> equivalent' is marked "must not be specified".
>
>
> You put up a pretty good approximation of that.
>
>
> That is complete bullshit. I can label anything that _I_ want to as
> abuse and I have provided good reasons why I do so, and it is not just
> that it is marked "must not". If _you_ want other things to be called
> abuse by you or anyone else then come up with your own _reasons_ for
> doing that - without just making stuff up.
>
> There is in fact no relationship between this being abuse and this
> being an extension beyond that without the extension the compiler will
> reject it. Whether I may or may not care about other constructs or
> other extensions is irrelevant.
>
| |
| Richard 2005-06-05, 8:55 pm |
|
William M. Klein wrote:
> Richard,
> When you TOTALLY remove the context for a reply,
You are , my reply (which you included and reproduced here)
included the context that I was replying to. If you cannot remember why
you posted the remarks that I included then you should look back at
your own post to work out what you said and why.
> YOUR reply makes no sense.
> Please repost *with* context (showing what Pete posted and what I replied to).
According to Google there was a 3 hour difference between your post and
my follow up. I have included what you had said that _I_ was replying
to (ie the context). If you cannot recall why you said something to
Peter then I suggest that my reposting would be a waste of time (as
this may be) because you will probably have forgotten why you asked for
a repost.
[color=darkred]
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Richard" <riplin@Azonic.co.nz> wrote in message
> news:1118005868.310723.98950@g43g2000cwa.googlegroups.com...
| |
| docdwarf@panix.com 2005-06-05, 8:55 pm |
| In article <3ggk9aFbdacjU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
[snip]
>Yes, it will. I have said everything I want to say about NEXT SENTENCE and
>would be unlikely to respond further... :-)
No need to bother with providing alternate viewpoints, then... you see, Mr
Dashwood, I try to read an entire posting at least once before I respond.
DD
| |
| docdwarf@panix.com 2005-06-05, 8:55 pm |
| In article <1118003752.914573.214600@g43g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>Actually, I very much doubt that either would be used to 'save CPU
>cycles', they were used because there was inadequate methods of
>constructing code without using these.
Mr Plinston, your doubt - and perhaps other things you express - appears
to be the result of ignorance.
DD
| |
| Richard 2005-06-06, 3:55 am |
| >>Actually, I very much doubt that either would be used to 'save CPU
[color=darkred]
> Mr Plinston, your doubt - and perhaps other things you express - appears
> to be the result of ignorance.
Then perhaps you could post an example where the use of NEXT SENTENCE
could save CPU cycles that could not be done equally well with later
'84 constructs.
| |
| Pete Dashwood 2005-06-06, 3:55 am |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:rfHoe.284063$CV1.151042@fe02.news.easynews.com...
> (see bottom)
>
<snip>> >
>
> At some (IBM) mainframe shops with their '74 Standard compiler (without a
3rd
> party add-on product) there was (significant?) performance advantage in
placing
> the "most commonly encountered" condition FIRST. Therefore, the "NEXT
SENTENCE"
> construct 8did* perform better than the 2nd (which actually only has one
test -
> no "ELSE"). I cannot remember what type of "object code" it created, but
I do
> remember the need for such code. It is POSSIBLE that my memory has the
"first
> condition - most common" and the "don't use negative logic" requirements
mixed
> up, but it is my memory that that the first code performed better than the
2nd.
>
Bill, while I have nothing but the utmost respect for your knowledge and
wisdom on things COBOL, at this point I have to disagree. If we remove the
optimization from the discussion, I believe that the code generated by the
first construct can NEVER be as good as that generated by the second, in an
IBM mainframe environment. If memory serves, and we take a simple condition,
like IF character = 'A', the code generated is a CLI and a BC. Putting the
NEXT SENTENCE in generates ANOTHER BC for the ELSE. It simply CANNOT be as
efficient.
('IF character NOT = 'A' still generates a CLI and BC, but removes the need
for an alternative BC.)
Even if the NEXT SENTENCE branch was ALWAYS taken, there would be no
advantage over the form that DIDN'T use NEXT SENTENCE. (And the load module
would contain more code and therefore take longer to load, which could be
significant in a CICS environment, for example.)
Placing the most common conditions first, certainly would be good practice
because the requirement for further checking of the condition code would be
obviated once the condition was true.
> There is NO doubt in my mind that they are "logicallly equivalent".
>
Good. (That's a relief... :-))
> P.S. In case it isn't clear from this or the other thread:
>
> A) I do NOT recommend the use of "NEXT SENTENCE" which is currently
classified
> as "Archaic" in the ISO Standard
I didn't know it was Archaic. Thanks for that. Anything that discourages
people from using it is 'good' in my book.
<snipped reasonable position on rights of others>
Pete.
| |
| Pete Dashwood 2005-06-06, 3:55 am |
|
<docdwarf@panix.com> wrote in message news:d800ab$hob$1@panix5.panix.com...
> In article <3ggk9aFbdacjU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> [snip]
>
and[color=darkred]
>
> No need to bother with providing alternate viewpoints, then... you see, Mr
> Dashwood, I try to read an entire posting at least once before I respond.
>
Me too. I think you may have misunderstood what I said; "unlikely" doesn't
mean "won't"...
And whether I respond or not, there is absolutely no reason why discussion
should not proceed without me.
Having said everything I would want to say, I see little likelihood in
being able to contribute further, or needing to say more. It would get VERY
tiresome if all my subsequent responses amounted to "see my previous
post..." :-)
But that's just me... others here have no such limitations... :-)
Pete.
| |
| docdwarf@panix.com 2005-06-06, 3:55 am |
| In article <3ghn42Fcdo4uU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:d800ab$hob$1@panix5.panix.com...
>
>Me too. I think you may have misunderstood what I said; "unlikely" doesn't
>mean "won't"...
Mr Dashwood, my knowledge of English, though scant, encompasses the fact
that 'unlikely' is not the same as 'won't'.
My knowledge of probability, though scant, causes me to concentrate first
more on likely scenarios, then on the unlikely.
>
>And whether I respond or not, there is absolutely no reason why discussion
>should not proceed without me.
Mr Dashwood, discussion will continue... however, given a lack of
likelihood of your responding to me as I would respond to you I'll
concentrate my efforts elsewhere.
>
>Having said everything I would want to say, I see little likelihood in
>being able to contribute further, or needing to say more.
Far be it from me to tax either likelihood or ability, Mr Dashwood.
DD
| |
| docdwarf@panix.com 2005-06-06, 3:55 am |
| In article <1118015537.829545.131280@g14g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>
>Then perhaps you could post an example where the use of NEXT SENTENCE
>could save CPU cycles that could not be done equally well with later
>'84 constructs.
Mr Plinston, when I claim I can do such a thing I'll do just that... and
it will have neither prove nor disprove my assertion about what was
beloved and when it was so.
DD
| |
| Richard 2005-06-06, 3:55 am |
| > Mr Plinston, when I claim I can do such a thing I'll do just that...
Is your disclaim that you can do it admitting that this is a result of
ignorance ?
> and
> it will have neither prove nor disprove my assertion about what was
> beloved and when it was so.
That would make it a matter of faith then.
| |
| William M. Klein 2005-06-06, 3:55 am |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1118007996.007187.59960@z14g2000cwz.googlegroups.com...
>
>
> William M. Klein wrote:
>
> You are , my reply (which you included and reproduced here)
> included the context that I was replying to.
but NOT what I was replying to (which was a specific code structure and comment
from Pete.
However, it now looks like you are simplying arguing to try and make your
(inconsistent) use of the term "abuse" not the point of this thread - or any
thread ... So I'll let you talk to yourself in peace.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Richard 2005-06-06, 3:55 am |
| >> You are , my reply (which you included and reproduced here)
[color=darkred]
> but NOT what I was replying to (which was a specific code structure and comment
> from Pete.
Perhaps you could indicate which part of PECD's message promoted this
particular response and which lines of that message would have given
you more 'context':
[color=darkred]
> to try and make your (inconsistent) use of the term "abuse" not the point of this thread
I can't recall actually making _any_ recent statements of my opinions
on other extensions at all, even to the point of explicitly reserving
them, so your claim that my opinions are 'inconsistent' is spurious,
ficticious and abusive.
The point of the thread is, and always has been, the use of NEXT
SENTENCE in imperitive IF statements - except where you have attempted
to change it.
Why you think that my opinions on other, entirely unrelated, matters
should be relevent does not seem to have been explained.
| |
| William M. Klein 2005-06-06, 3:55 am |
| "Richard" <riplin@Azonic.co.nz> wrote in message
news:1118031194.670531.34400@z14g2000cwz.googlegroups.com...
<snip>
>
>
>
> I can't recall actually making _any_ recent statements of my opinions
> on other extensions at all, even to the point of explicitly reserving
> them, so your claim that my opinions are 'inconsistent' is spurious,
> ficticious and abusive.
>
> The point of the thread is, and always has been, the use of NEXT
> SENTENCE in imperitive IF statements - except where you have attempted
> to change it.
>
> Why you think that my opinions on other, entirely unrelated, matters
> should be relevent does not seem to have been explained.
>
What I disagree with (while certainly NOT saying you can't say it) is your
statement,
"A NEXT SENTENCE in the same IF as an END-IF is abuse because the
standard specifically disallows it"
See your post of:
Friday, June 03, 2005 9:10 PM
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Richard 2005-06-06, 3:55 am |
| > What I disagree with (while certainly NOT saying you can't say it) is
> your statement,
> "A NEXT SENTENCE in the same IF as an END-IF is abuse because the
> standard specifically disallows it"
If it wasn't disallowed by the standard then it wouldn't be abuse of
the language. How hard is that ? As J4 had wanted it not to to be used
then using it is against their wishes, as they determine the language
standard then it is abusing their wishes. How hard is that ?
As I had already spent several previous messages in the thread
discussing why I didn't like the construct and what problems arise from
using it then it seemed unnecessary to repeat all that.
> (while certainly NOT saying you can't say it)
Then what exactly _is_ your point ?
Looking back at the thread your messages seem to be _entirely_ off the
subject and making claims about things that I _DIDN'T_ say.
You repeatedly acted as if I have said that 'all extensions are abuse'
or even 'all things disallowed are 'abuse', when it was quite clear
that I restricted my comments to one specific item.
But the main thing that _I_ disagreed with was all the complete
nonsense and misinformation that you spouted (examples supplied upon
request).
| |
| docdwarf@panix.com 2005-06-06, 8:55 am |
| In article <1118026402.170078.259260@g44g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>Is your disclaim that you can do it admitting that this is a result of
>ignorance ?
No, Mr Plinston, it is a matter of time; I have enough on my hands
supporting my own claims, let alone what things I have not claimed.
>
>
>That would make it a matter of faith then.
Mr Plinston, they were called objects of love; if you wish to see that as
a matter of faith it is your own concern.
DD
| |
| Howard Brazee 2005-06-06, 3:55 pm |
|
On 3-Jun-2005, docdwarf@panix.com wrote:
> I do not understand what you are calling 'abuse'; a NEXT SENTENCE, in my
> experience, does what the Standards say it should do and what every
> textbook I have ever read say it should do.
Although including it within an IF END-IF pair as the code that started this
thread does not. (On my computer it is called an Extension).
| |
| docdwarf@panix.com 2005-06-06, 3:55 pm |
| In article <d81lvr$p3v$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 3-Jun-2005, docdwarf@panix.com wrote:
>
>
>Although including it within an IF END-IF pair as the code that started this
>thread does not. (On my computer it is called an Extension).
So, it seems, what on your computer is called an Extension qualifies,
under at least one view, as 'abuse'.
DD
| |
| Howard Brazee 2005-06-06, 3:55 pm |
|
On 3-Jun-2005, "William M. Klein" <wmklein@nospam.netcom.com> wrote:
> The "Standard" also disallows GoBack - and if you asked (IBM) mainframe people
>
> to "give that up" because it was "abuse" - you would be in REAL trouble.
Which standard disallowed GoBack? It was my understanding that this former
extension has now been incorporated within the standard, but I'm not the
standards expert you are. I'd hate to discover that I've been lying to my
co-workers about it though.
| |
| Howard Brazee 2005-06-06, 3:55 pm |
|
On 5-Jun-2005, "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
> My advice: Don't use NEXT SENTENCE.... ever. It is a stupid and unnecessary
> inclusion in the COBOL language. It is NEVER required, UNLESS you (or your
> installation) forbids the use of negated conditions.
Why is it required then?
I'm a big proponent of using the
IF (complicated condition)
CONTINUE
ELSE
...
END-IF.
construct for some conditions. In Olden Dayze, I would have used NEXT
SENTENCE, but don't need to anymore.
| |
| Howard Brazee 2005-06-06, 3:55 pm |
|
On 4-Jun-2005, docdwarf@panix.com wrote:
> Answering a question with a question, Mr Plinston, is no answer at all.
Sometimes it is, sometimes it isn't. And sometimes it is is necessary to
determine how to answer.
Was your reply (given above) more or less of an answer? I vote "less".
| |
| Howard Brazee 2005-06-06, 3:55 pm |
|
On 6-Jun-2005, docdwarf@panix.com wrote:
>
> So, it seems, what on your computer is called an Extension qualifies,
> under at least one view, as 'abuse'.
Apparently. I can see someone setting up standards that disallow extensions
that are explicitly proscribed by the standard. Breaking a standard has been
called "abuse" in my experience.
But in evaluating why to do this, it would be because:
1. I don't expect that extension to be available when I upgrade my computer.
2. I expect my code to be portable if we go to a new computer.
3. Somebody created a standard and nobody knows why, but it's a standard and
changing it will take man-months of effort.
Personally I don't believe in #2 at all. I've done too many conversions in the
past. Even changing databases with the same type of computer require
re-writes.
#2 seems unlikely but possible.
I've had lots of experience with #3 being true.
| |
| Chuck Stevens 2005-06-06, 3:55 pm |
|
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:3gfukvFc4h3qU1@individual.net...
> My advice: Don't use NEXT SENTENCE.... ever. It is a stupid and
unnecessary
> inclusion in the COBOL language.
The authors of the current COBOL standard agree that its use should be
discouraged. Support for it is retained so that existing programs
containing it will continue to compile, but NEXT SENTENCE is marked as an
"archaic element" of standard COBOL in all contexts in which it is allowed
by the standard (IF and SEARCH statements). The standard doesn't
characterize it as "stupid"; it does say it "can be confusing" and that its
function is commonly misunderstood. "The CONTINUE statement and scope
delimiters can be used to accomplish the same functionality and such
constructs are clearer and less prone to error." (ISO/IEC 1989:2005 page
833, Archaic and obsolete language element lists).
-Chuck Stevens
| |
| Chuck Stevens 2005-06-06, 3:55 pm |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1118036593.893537.20610@f14g2000cwb.googlegroups.com...
> If it wasn't disallowed by the standard then it wouldn't be abuse of
> the language. How hard is that ? As J4 had wanted it not to to be used
> then using it is against their wishes, as they determine the language
> standard then it is abusing their wishes. How hard is that ?
I would argue that if the rules of COBOL grammar prohibit NEXT SENTENCE in a
certain context, it is not an *abuse* of COBOL to use it in that context, it
is simply not grammatical COBOL. If an implementor chooses to allow it,
then it is an *extension to* standard COBOL.
To cite an extreme example, in an environment in which speaker and listener
are both fluent in English and German, it is not necessarily *abuse* to
switch back and forth between the two languages, but the conversation is
neither strictly English nor strictly COBOL. The ENTER statement was in the
'74 standard, is marked obsolete in the '85 standard, and is gone from the
'02 standard. I can think of no case in which its use was portable from
one operating environment to another.
The use of NEXT SENTENCE outside the context in which the COBOL standard
allows it strikes me as ungrammatical in the same sense that ending
sentences with prepositions or splitting infinitives is ungrammatical in
English. If both the compiler and the user agree as to its meaning, then
they have communicated successfully; the question is whether anybody else
should be expected to understand what was being communicated.
-Chuck Stevens
| |
|
|