Postive and Negative requirements (was: interesting use of NEXT SENTENCE vs. CONTINUE

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1117919295.721873.96000@g43g2000cwa.googlegroups.com... 
>
> 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".
>

Within the COBOL Standard ('85 and '02 - probably before and probably will b
e
after), there are SOME *requirements* written positively and some that are
written negatively.  These are ALL "requirements" of the language specificat
ion
and all have "equivalent" wording that could be provided using the opposite
technique.  For example, (from the '02 Standard as it is easier for me to
search)

"A given literal shall not be continued with more than one form of
continuation."

which COULD be worded as

"A given literal shall be continued with only one form of continuation."

* * * *
or

"All the characters forming a multiple-character floating indicator shall be
specified on the same line."

which could be worded as

"The characters forming a multiple-character floating indicator shall not be
specified on multiple lines."

For a DETAILED description of what these mean (and this is an ISO requiremen
t -
not a COBOL requirement), see the discussion of:

"Verbal forms for the expression of provisions"

On page 21 of the '02 Standard.  (You will notice that "must not" is no long
er
even permitted to be used within the Standard - and there is no such wording
 for
NEXT SENTENCE and END-IF in the only "currently acknowledged" ANSI/ISO COBOL
Standard).

These may (or may not) be how YOU use the language in other contexts, but th
is
is the way the COBOL Standard uses it.

FYI,
For END-IF and  "NEXT SENTENCE" the '02 Standard handles this via the syntax
(general format) diagram - not by a syntax rule.  However, the following wor
ding
is used for NEXT SENTENCE and SEARCH,

"If the END-SEARCH phrase is specified, the NEXT SENTENCE phrase shall not b
e
specified."

--
Bill Klein
wmklein <at> ix.netcom.com

> which COULD be worded as

> "A given literal shall be continued with only one form of continuation."

No. Wrong. Your version implies that continuation is a requirement:
'The literal shall be continued', the 'only one form' is then only a
limitation on how this requirement is fullfilled.

> which could be worded as ...

I think that the committe have, for the most part, worded the items as
they wish to have them having considered what they actually intended.
I doubt that they would agree that your versions are equivalent,
especially as you have admitted that you don't see the difference
between not mentioning something and disallowing it.

> FYI,
> For END-IF and  "NEXT SENTENCE" the '02 Standard handles this via the synt
ax
> (general format) diagram - not by a syntax rule.

I am pleased to hear that. They did have to admit that the '85 rule
could lead to a conditional IF statement with NEXT SENTENCE being
embeded in an imperitive IF and thus bypassing the intent of the
prohibition. I trust this new formulation is designed to eliminate
that.

> However, the following wording
> is used for NEXT SENTENCE and SEARCH,

> "If the END-SEARCH phrase is specified, the NEXT SENTENCE phrase shall not
 be
> specified."

One may assume that there was no need to change this because no one
contrived to misuse this within the wording of the standard.

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1117928023.972656.276500@g49g2000cwa.googlegroups.com... 
>
<snip>

(general format) diagram - not by a syntax rule.
>
> I am pleased to hear that. They did have to admit that the '85 rule
> could lead to a conditional IF statement with NEXT SENTENCE being
> embeded in an imperitive IF and thus bypassing the intent of the
> prohibition. I trust this new formulation is designed to eliminate
> that.
>

No, it is even clear that it is INTENTIONAL that the following is VALID
(conforming) source code:

If A-field = "A"
IF A-field = "A"
Next Sentence
Else
Display "Never Reached"
Else
Display "Not A"
End-IF

--
Bill Klein
wmklein <at> ix.netcom.com

> No, it is even clear that it is INTENTIONAL that the following is VALID
> (conforming) source code:

You have made the assertion that it is intentional in the past, but so
far you have not provided any actual evidence on which you based this.

It is clear that one can contrive the rules in such a way that they do
not explicitly disallow it, and I understand that the committee have
agreed that it is not disallowed by the actual wording.

It is a large leap, however, to make the claim that it was intentional.
This requires that they actually considered the issue (for which I have
seen no evidence) and then decided to deliberately allow it (for which
I have seen no evidence) rather than, say, not being able to formulate
an acceptable rule that would disallow it without impacting on other
areas.

In fact I would say that the change in this area in '02 may be as a
result of this contrived avoidance of the rule.

If it is so clear then you should be able to quote the wording
_from_the_standard_ (and not MF notations) as to what make you think it
was intended.

For the '02 Standard, read the "general format" on page 455 where the (clari
fy
if it was uncler - which the committee did not think it was - in the '85
Standard) that NEXT SENTENCE may not be used WHEN IMMEDIATELY followed by EN
D-IF
(or an ELSE imperative-statement-2 END-IF).  In cases where the IF statement
does NOT (itself) include the END-IF phrase, then it is (clearly and always)
valid (conforming).

As far as the (now no longer current) '85 Standard, you need to read the
response to the interpretation request where they talk about the rules that
mention:

"An END-IF phrase at the same level of nesting"
(in one rule - talking about the "scope" of an IF Statement versus nested IF
's)
and then say
"If the END-IF phrase is specified, the NEXT SENTENCE phrase must not be
specified."

where it is clear (to them - if not to you) that this is NOT a rule talking
about nested IF's.

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1117933131.539990.23360@f14g2000cwb.googlegroups.com... 
>
> You have made the assertion that it is intentional in the past, but so
> far you have not provided any actual evidence on which you based this.
>
> It is clear that one can contrive the rules in such a way that they do
> not explicitly disallow it, and I understand that the committee have
> agreed that it is not disallowed by the actual wording.
>
> It is a large leap, however, to make the claim that it was intentional.
> This requires that they actually considered the issue (for which I have
> seen no evidence) and then decided to deliberately allow it (for which
> I have seen no evidence) rather than, say, not being able to formulate
> an acceptable rule that would disallow it without impacting on other
> areas.
>
> In fact I would say that the change in this area in '02 may be as a
> result of this contrived avoidance of the rule.
>
> If it is so clear then you should be able to quote the wording
> _from_the_standard_ (and not MF notations) as to what make you think it
> was intended.
>

> where it is clear (to them - if not to you) that this is NOT a rule talking
> about nested IF's.

Yes, but your claim was that this was intended when it is actually
indistinguishable from them merely not having considered this and/or
not wanting to formulate such a rule as it would complexify other
issues.

I entirely agree that it was intended that a conditional IF statement
be allowed nested within an  imperitive IF, but if they intended to
allow this to have a NEXT SENTENCE then why did they bother explicitly
disallowing it within the imperitive ?

I agree that the clarification does state that the particular rule only
applies to the one level of imperitive IF. That in itself does not mean
that it was intended to be limited in that way, only that it turned out
to be so limited.

The intent in the '85 rule is pure conjecture on your part, because you
want it to be so. I see nothing that makes it other than an oversight
in '85, even in the clarification. In that and now in '02 they have to
live with what that may have allowed inadvertantly.

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1117948079.117667.172630@g14g2000cwa.googlegroups.com... 
<snip>
>
> The intent in the '85 rule is pure conjecture on your part, because you
> want it to be so. I see nothing that makes it other than an oversight
> in '85, even in the clarification. In that and now in '02 they have to
> live with what that may have allowed inadvertantly.
>

Richard,
How many J4 meetings have you attended?  How many WG4 meetings have you
attended?  How many Codasyl COBOL Committee meetings have you attended?

Were you involved (attended) the J4 meetings where the interpretation reques
t
specifically about this syntax was discussed?

I was there (at all of these) and can assure you that (in my mind) there was
 NO
DOUBT that this "feature" was intentional for SOME - (not all) participants 
in
the DEVELOPMENT of the '85 Standard.

One part of the history that you may not be familiar with is the fact that t
he
JOD *explicitly* did allow a NEXT SENTENCE with an END-IF (in the same "leve
l"
of the IF statement).  There was discussion about this during the developmen
t of
the '85 Standard and the decision was (eventually) NOT to allow this.  HOWEV
ER,
there was also discussion about the fact that there is one AND ONLY ONE plac
e
within the Standard ('85 or '74) where a "conditional statement" MAY be nest
ed
within another statement - and that is within either the IF (THEN) or the EL
SE
portions of an IF statement.  Furthermore, there was discussion about whethe
r a
2nd thru Nth "conditional phrase" (e.g. ELSE, WHEN, NOT AT END, etc) would o
r
would not "terminate" a nested conditional statement.  It was discussed and
decided that it would - HOWEVER, as only the IF statement could have a neste
d
conditional statement, it was decided that "ELSE" (and only ELSE) would be
allowed to terminate a nested conditional statement (and this INCLUDED the
"conditional" format of an IF statement - with a NEXT SENTENCE and without a
n
END-IF).

I will be happy to admit (and agree to it) that SOME members of the committe
es
drafting the '85 Standard did NOT want this (and it is even possible that so
me
didn't really understand it) - but there is no doubt that the committee "as 
a
whole" DID consider this - and make the rules as they did.


--
Bill Klein
wmklein <at> ix.netcom.com

> I will be happy to admit (and agree to it) that SOME members of the committees
> drafting the '85 Standard did NOT want this (and it is even possible that 
some
> didn't really understand it) - but there is no doubt that the committee "a
s a
> whole" DID consider this - and make the rules as they did.

Well, there yer go, you didn't have to make up the other arguments
after all.

And, as I said:  "and/or not wanting to formulate such a rule as it
would complexify other
issues."

ACTUALLY, I was working with Micro Focus when the OLNEXTSENTENCE directive w
as
introduced.  The compiler writer who made it equivalent to "CONTINUE" admitt
ed
that he was in error and that the JOD and the (draft at that time) '85 Stand
ard
*NEVER* said that.  NEXT SENTENCE has *always* been defined (in every Standa
rd)
as "going to the next sentence" and NOT to the next statement.

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1118032405.646051.54220@g47g2000cwa.googlegroups.com... 
>
> Actually I am familiar with this, and it does your case no good at all.
> In the JOD the NEXT SENTENCE was equivalent to CONTINUE. MicroFocus
> implemented this and had to change when the standard made the
> definition of NEXT SENTENCE into 'the next full stop'.
>
> The result is that MF has an OLDNEXTSENTENCE compiler directive to
> cater for code written to the JOD.
>

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:bu1pe.58080$Wv.42324@fe08.news.easynews.com...

> ACTUALLY, I was working with Micro Focus when the OLNEXTSENTENCE directive
was
> introduced.  The compiler writer who made it equivalent to "CONTINUE"
admitted
> that he was in error and that the JOD and the (draft at that time) '85
Standard
> *NEVER* said that.  NEXT SENTENCE has *always* been defined (in every
Standard)
> as "going to the next sentence" and NOT to the next statement.

Yeah, I strongly suspect J4 was being diplomatic when it indicated that it
was the *users* who were sometimes  about where control proceeds on
a NEXT SENTENCE ...

I also have this fairly strong suspicion that there just might be another
vendor or two aside from MF out there whose COBOL85 implementations
erroneously generated code to transfer control to the next *statement* in
cases like this ...  ;-(

-Chuck Stevens