Home > Archive > Cobol > October 2005 > Semantics and syntax of the ADD ... GIVING statement
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 |
Semantics and syntax of the ADD ... GIVING statement
|
|
| Oliver Wong 2005-09-15, 6:55 pm |
| According to my reference, the syntax for the ADD ... GIVING statement is as
follows ([] means optional, + means 1 or more times, <> means "substitute a
value here")
ADD <identifier or literal>+ [ TO ] <identifier or literal>+ GIVING (
<identifier> [ ROUNDED ] )+
Since the TO keyword is optional, is there a semantic difference between:
ADD 10 27 GIVING foo
and
ADD 10 TO 27 GIVING foo
?
Also, is it a requirement that the ADD ... GIVING statement has at least 2
operands? I.e. is the following valid:
ADD 5 GIVING foo
- Oliver
| |
| Binyamin Dissen 2005-09-15, 6:55 pm |
| On Thu, 15 Sep 2005 15:05:42 GMT "Oliver Wong" <owong@castortech.com> wrote:
:>According to my reference, the syntax for the ADD ... GIVING statement is as
:>follows ([] means optional, + means 1 or more times, <> means "substitute a
:>value here")
:> ADD <identifier or literal>+ [ TO ] <identifier or literal>+ GIVING (
:><identifier> [ ROUNDED ] )+
:>Since the TO keyword is optional, is there a semantic difference between:
:> ADD 10 27 GIVING foo
:>and
:> ADD 10 TO 27 GIVING foo
:>?
I believe that they are identical.
:>Also, is it a requirement that the ADD ... GIVING statement has at least 2
:>operands? I.e. is the following valid:
:> ADD 5 GIVING foo
I believe that two or more operands are required.
--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
| |
| Chuck Stevens 2005-09-15, 6:55 pm |
|
> Since the TO keyword is optional, is there a semantic difference between:
>
> ADD 10 27 GIVING foo
> and
> ADD 10 TO 27 GIVING foo
> ?
No.
> Also, is it a requirement that the ADD ... GIVING statement has at least 2
> operands?
Yes. The syntax diagram requires at least two addends.
>I.e. is the following valid:
>
> ADD 5 GIVING foo
No.
-Chuck Stevens
| |
| Michael Mattias 2005-09-15, 6:55 pm |
| > >I.e. is the following valid:
[color=darkred]
> No.
It's not just invalid, it's silly. Add 5 and what? Or to what?
('Add 5 to foo' would be valid, however).
MCM
(Damn, wouldn't it be a hoot to actually get a compiler error message
containing the word 'silly?')
| |
| Howard Brazee 2005-09-15, 6:55 pm |
| Michael Mattias wrote:
>
>
> It's not just invalid, it's silly. Add 5 and what? Or to what?
>
> ('Add 5 to foo' would be valid, however).
>
> MCM
> (Damn, wouldn't it be a hoot to actually get a compiler error message
> containing the word 'silly?')
I've had CoBOL programs that added 0 to numbers, to make sure that the
resulting number would be in the correct format.
| |
| HeyBub 2005-09-15, 6:55 pm |
| Howard Brazee wrote:
> Michael Mattias wrote:
>
> I've had CoBOL programs that added 0 to numbers, to make sure that the
> resulting number would be in the correct format.
And I saw one that had:
MOVE X.
I guess for the purpose of getting it out of the way.
| |
| Oliver Wong 2005-09-15, 6:55 pm |
|
"Michael Mattias" <michael.mattias@gte.net> wrote in message
news:sIgWe.1310$D42.34@newssvr19.news.prodigy.com...
>
>
> It's not just invalid, it's silly. Add 5 and what? Or to what?
If you interpret the ADD statement to act like a summation, then the sum
of 1 number is that number itself, and the sum of zero numbers is zero. But
I guess this isn't the interpretation that COBOL uses.
- Oliver
| |
| Oliver Wong 2005-09-15, 6:55 pm |
| "Michael Mattias" <michael.mattias@gte.net> wrote in message
news:sIgWe.1310$D42.34@newssvr19.news.prodigy.com...
> (Damn, wouldn't it be a hoot to actually get a compiler error message
> containing the word 'silly?')
Back in my "Compilers" class in university, one of the warning messages
the compiler I wrote produced was "Why would you ever want to do this?" I
forget the exact details, but it was detecting obscure, useless, but legal
syntax.
- Oliver
| |
|
| In article <sIgWe.1310$D42.34@newssvr19.news.prodigy.com>,
Michael Mattias <michael.mattias@gte.net> wrote:
[snip]
>(Damn, wouldn't it be a hoot to actually get a compiler error message
>containing the word 'silly?')
I once mis-coded a SEARCH (or maybe it was a SEARCH ALL) back in the days
of IKFCBL00 so the error read 'EXPECTED WHEN. FOUND 'WHEN'. DELETING UNTIL
NEXT VALID INPUT.'
DD
| |
| William M. Klein 2005-09-15, 6:55 pm |
| Oliver,
A couple of "add-on" comments to Chuck's (correct) statement.
1) Looking at BOTH the '85 And '02 Standards, if the identifier-2 / literal-2
items were in "square brackets" rather than "curli-brackets" this would have
indicated that they were optional. This distinction is pretty important in
understanding how to read Standard COBOL syntax diagrams.
2) The '85 Standard identifies the (optional) "TO" word in the "giving" format
of the ADD statement as a "Substantive change". Therefore, if you need to
distinguish between '74 and '85 (or later) syntax, this was an EXTENSION if
available in a '74 Standard compiler. (I know that IBM did allow it, but I
don't know how common it was - as an extension).
--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:dgc3v2$rlq$1@si05.rsvl.unisys.com...
>
>
> No.
>
>
> Yes. The syntax diagram requires at least two addends.
>
>
>
> No.
>
> -Chuck Stevens
>
>
| |
| Chuck Stevens 2005-09-15, 6:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:EIhWe.20156$R83.14463@fe04.news.easynews.com...
> 2) The '85 Standard identifies the (optional) "TO" word in the "giving"
format
> of the ADD statement as a "Substantive change". Therefore, if you need to
> distinguish between '74 and '85 (or later) syntax, this was an EXTENSION
if
> available in a '74 Standard compiler. (I know that IBM did allow it, but
I
> don't know how common it was - as an extension).
I can say with some certainty that the COBOL74 compiler used in the Unisys
MCP environment does not allow both TO and GIVING in the same ADD statement.
I can't address how common this extension was, but I can say that it wasn't
universal.
-Chuck Stevens
| |
| Oliver Wong 2005-10-06, 6:55 pm |
|
"Volker Bandke" <vbandke@bsp-gmbh.com> wrote in message
news:snnak1ljc4088e7l5ha9slco9rs488008s@
4ax.com...
> On Thu, 15 Sep 2005 15:05:42 GMT, "Oliver Wong" <owong@castortech.com>
> wrote:
>
>
>
> Are you sure about the "+" on the second identifier? I don't see in
> the IBM ENTERPRISE COBOL 3.3 syntax diagram. Also, it would be
> ambiguous
>
> ADD salary taxes social-expenses
> TO totalcost department-cost
> GIVING some-value some-other-value
>
> is definitely different from
>
> ADD salary taxes social-expense total-cost
> TO department-cost
> GIVING some-value some-other-value
>
>
> In order to have "TO" as an OPTIONAL item the second operand would
> have to be specified exactly once to make the statement ambiguous
Fairly sure. My interpretation of the reference is that:
ADD A B C TO D E GIVING F
essentially assigns the value (A + B + C + D + E) to the variable F.
In other words, the keyword "TO" can appear one or zero times, and if it
appears once, it can appear essentially anywhere in the list of operands. In
all cases, the "TO" keyword doesn't change the semantics of the statement.
It doesn't do an "ADD CORRESPONDING" which I think is what you're thinking
of.
- Oliver
| |
| Volker Bandke 2005-10-06, 6:55 pm |
| On Thu, 06 Oct 2005 17:46:34 GMT, "Oliver Wong" <owong@castortech.com>
wrote:
Okay, I tried it.
Compiler: IBM Enterprise COBOL 3.3
Variables predefined as
A=1
B=2
C=4
D=8
E=16
F=32
G=64
First experiment: ADD A, B, C, D, E GIVING F, G
Result: As expected, F and G are now each 31, all others unchanged
Second experiment: ADD A, B, C, D TO E GIVING F, G
same as above
Third experiment: ADD A, B, C, D TO E, F GIVING G
This gives a syntax-error: GIVING is invalid. IOW, at least the IBM
compiler does not want more than 1 item following the (optional) TO
word.
There is no mentioning of this behaviour to be
non-standard-conforming, therefore I still believe the second
identifier (after the TO) cannot be repeated
With kind Regards |\ _,,,---,,_
ZZZzz /,`.-'`' -. ;-;;,
Volker Bandke |,4- ) )-,_. ,\ ( `'-'
(BSP GmbH) '---''(_/--' `-'\_)
Extreme good-naturedness borders on weakness of character. Avoid it.
(Another Wisdom from my fortune cookie jar)
| |
| Chuck Stevens 2005-10-06, 6:55 pm |
|
"Oliver Wong" <owong@castortech.com> wrote in message
news:_pd1f.7580$Io.4900@clgrps13...
> In other words, the keyword "TO" can appear one or zero times,
True according to ANSI X3.23-1985 page VI-73.
> and if it appears once, it can appear essentially anywhere in the list of
operands.
False according to the same page.
In Formats 1 and 3 ADD (without GIVING and the CORRESPONDING version), "TO"
is *mandatory* before the last identifier and identifies the receiving field
for Format 1 and the receiving group for Format 3.
In Format 2 ADD (with GIVING), "TO" is *optional* before the sending field
that immediately precedes the GIVING phrase -- that is, the *last* of
*multiple* sending fields, but is *NOT* allowed elsewhere in the statement.
"ADD A B C D E TO F G H" is valid COBOL (format 1).
"ADD A B C D E TO F GIVING G H" is valid COBOL (format 2).
But "ADD A B C D TO E F GIVING G H" is not only not valid COBOL, it is
ambiguous and is correctly a syntax error on that basis.
Is it a Format 1 ADD with an extraneous GIVING clause, a Format 2 ADD with
an extraneous sending item, or a case of misplaced "TO", and exactly how is
the compiler supposed to know which is intended by the user?
How much "value-add" does the user get if the implementor allows "TO" --
which in formats 1 and 3 denotes the *receiving* item(s) -- anywhere among
the list of *sending* items in a Format 2 ADD?
How much clearer is the source code *with* a "misplaced" TO than with a
correctly placed one, or with no "TO" at all?
Who benefits by such an extension?
-Chuck Stevens
| |
| Rick Smith 2005-10-06, 6:55 pm |
|
"Oliver Wong" <owong@castortech.com> wrote in message
news:_pd1f.7580$Io.4900@clgrps13...
>
> "Volker Bandke" <vbandke@bsp-gmbh.com> wrote in message
> news:snnak1ljc4088e7l5ha9slco9rs488008s@
4ax.com...
is[color=darkred]
"substitute[color=darkred]
([color=darkred]
[snip][color=darkred]
>
> Fairly sure. My interpretation of the reference is that:
>
> ADD A B C TO D E GIVING F
>
> essentially assigns the value (A + B + C + D + E) to the variable F.
[snip]
Mr Wong, I notice that, where you use a "+", the COBOL
format uses a "..." (ellipsis). Does your reference have an
ellipsis immediately preceeding "GIVING"?
| |
| Volker Bandke 2005-10-06, 6:55 pm |
| On 6 Oct 2005 12:39:32 -0700, "Richard" <riplin@Azonic.co.nz> wrote:
>
>Multiple variables after the TO is valid without the GIVING
Yes, I know, but then the TO has a (different) Meaning: It specifies
the result/target variable. The discussion that was in progress did
include the GIVING, though :)
With kind Regards |\ _,,,---,,_
ZZZzz /,`.-'`' -. ;-;;,
Volker Bandke |,4- ) )-,_. ,\ ( `'-'
(BSP GmbH) '---''(_/--' `-'\_)
Extreme good-naturedness borders on weakness of character. Avoid it.
(Another Wisdom from my fortune cookie jar)
| |
| Michael Mattias 2005-10-07, 7:55 am |
| "Volker Bandke" <vbandke@bsp-gmbh.com> wrote in message
news:1brak15q3952j4lk27tfs0gc4qal9fudql@
4ax.com...
> On Thu, 06 Oct 2005 17:46:34 GMT, "Oliver Wong" <owong@castortech.com>
> wrote:
>
> Okay, I tried it.
> [ test conditions and results]
Too bad too many people who post questions to newsgroups don't [ "try it"].
Nice demonstration of practical problem-solving. We can only hope it will
'rub off' on others.
Thank you.
MCM
| |
| Oliver Wong 2005-10-07, 6:55 pm |
|
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:11kb20ipsrjhq47@corp.supernews.com...
>
> "Oliver Wong" <owong@castortech.com> wrote in message
> news:_pd1f.7580$Io.4900@clgrps13...
> is
> "substitute
> (
> [snip]
> [snip]
>
> Mr Wong, I notice that, where you use a "+", the COBOL
> format uses a "..." (ellipsis). Does your reference have an
> ellipsis immediately preceeding "GIVING"?
>
Yes; In this example, everywhere the reference used "..." I've used "+".
- Oliver
| |
| Oliver Wong 2005-10-07, 6:55 pm |
|
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:di3uo7$qc3$1@si05.rsvl.unisys.com...
>
> In Format 2 ADD (with GIVING), "TO" is *optional* before the sending field
> that immediately precedes the GIVING phrase -- that is, the *last* of
> *multiple* sending fields, but is *NOT* allowed elsewhere in the
> statement.
>
> "ADD A B C D E TO F G H" is valid COBOL (format 1).
>
> "ADD A B C D E TO F GIVING G H" is valid COBOL (format 2).
>
> But "ADD A B C D TO E F GIVING G H" is not only not valid COBOL, it is
> ambiguous and is correctly a syntax error on that basis.
>
> Is it a Format 1 ADD with an extraneous GIVING clause, a Format 2 ADD with
> an extraneous sending item, or a case of misplaced "TO", and exactly how
> is
> the compiler supposed to know which is intended by the user?
>
> How much "value-add" does the user get if the implementor allows "TO" --
> which in formats 1 and 3 denotes the *receiving* item(s) -- anywhere among
> the list of *sending* items in a Format 2 ADD?
>
> How much clearer is the source code *with* a "misplaced" TO than with a
> correctly placed one, or with no "TO" at all?
>
> Who benefits by such an extension?
I might have misinterpreted the reference then. I am thinking about
Format 2, and the reference I'm using can be downloaded in PDF format from
http://www.liant.us/download/pdf/rmclrm75.pdf with the relevant information
appearing on page 327 and 328 (or "6-29" and "6-30" using the document's
internal page numbering scheme).
To me, the reference seems to be clearly saying that in Format 2, you
can have more than one operand appear after the "TO" keyword; or
equivalently, that the "TO" keyword can appear in other locations that just
before the last operand.
Anyway, if this is indeed a peculiarity of Liant's implementation of
COBOL, I'll make a note of that.
- Oliver
| |
| Chuck Stevens 2005-10-07, 6:55 pm |
| I can't say whether it is a peculiarity unique to Liant's implementation or
it's a peculiarity shared by any other implementations, but I *can* say
this:
1) The syntax diagram for ADD Format 2 (ADD ... GIVING) in ANSI X3.23-1974
on page II-55 does not allow TO in this format at all. Any instance in
which both TO and GIVING appear in the same ADD statement is outside the
bounds of standard COBOL. If an implementation allows it instead of issuing
a syntax error, what the statement does is defined by the particular
implementor.
2) The syntax diagram for ADD Format 2 (ADD ... GIVING) in ANSI X3.23-1985
on Page VI-37 allows an optional TO immediately preceding the *last of
multiple* sending fields. There is no ellipsis immediately before the
keyword GIVING. Any instance in which TO appears in ADD ... GIVING
anywhere other than immediately preceding the last sending field before the
GIVING phrase is outside the bounds of standard COBOL. If an implementation
allows TO anywhere else in the statement instead of issuing a syntax error,
what the statement does is defined by the particular implementor.
3) The syntax diagram for ADD Format 2 in ISO/IEC 1989:2002 on Page 415 is
in this regard the same as that for ANSI X3.23-1985. There is no ellipsis
immediately before the keyword GIVING.
I can't address why Liant's documentation has an ellipsis there, whether
it's a documentation error, whether it should be taken as evidence that they
support syntax like "ADD A TO B TO C TO D TO E GIVING F ROUNDED G", or
whether any other implementations share the ability to parse such a
statement, and if they do, exactly what it is that the particular
implementations (Liant or anyone else) actually do with it.
TO is optional in '85-and-subsequent standard COBOL ADD ... GIVING
statements. But if it is present, it is allowed only immediately prior to
the *last* sending field. Them's the rules of standard COBOL. And when you
get off into the bounds of implementor extensions, all bets are off in terms
of portability.
From what I can see in the three standards, it appears that the intent is
primarily to allow TO when there are exactly two sending fields, that is,
"ADD A TO B GIVING C", where it can be said to make the intent of the
statement clearer. When there are more than two sending fields, TO is
still allowed before the last. But in my opinion it obfuscates the intent
of the statement and *detracts* from the clarity of its intent.
I have run into instances in which a documentation error has resulted in
sufficient marketing pressure so as to force the implementors to follow the
error rather than strictly adhering to the standard. I can't help but
wonder if, presuming the Liant compilers actually do allow TO interspersed
among the sending fields as a noise word, the reason this is allowed is a
case of a documentation error driving a compiler change so the compiler
conforms to the documentation rather than vice versa.
-Chuck Stevens
"Oliver Wong" <owong@castortech.com> wrote in message
news:GTv1f.9445$yS6.2660@clgrps12...
>
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:di3uo7$qc3$1@si05.rsvl.unisys.com...
field[color=darkred]
with[color=darkred]
among[color=darkred]
>
> I might have misinterpreted the reference then. I am thinking about
> Format 2, and the reference I'm using can be downloaded in PDF format from
> http://www.liant.us/download/pdf/rmclrm75.pdf with the relevant
information
> appearing on page 327 and 328 (or "6-29" and "6-30" using the document's
> internal page numbering scheme).
>
> To me, the reference seems to be clearly saying that in Format 2, you
> can have more than one operand appear after the "TO" keyword; or
> equivalently, that the "TO" keyword can appear in other locations that
just
> before the last operand.
>
> Anyway, if this is indeed a peculiarity of Liant's implementation of
> COBOL, I'll make a note of that.
>
> - Oliver
>
>
| |
| Rick Smith 2005-10-07, 6:55 pm |
|
"Oliver Wong" <owong@castortech.com> wrote in message
news:fuv1f.9444$yS6.6513@clgrps12...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:11kb20ipsrjhq47@corp.supernews.com...
[snip]
>
> Yes; In this example, everywhere the reference used "..." I've used
"+".
Thank you. What led me to question the content of
the reference was what appears to be discrepancies
in the LRM for Micro Focus COBOL 3.2 (Apr 1994).
On page 4-330, both the ellipsis and TO are in a
box marked ANS85 and the TO is not underlined.
On page A-30, both the ellipsis and TO are in a
box marked ANS85 but the TO is underlined.
These disagree with what I understand the standards
to be, in that the ellipsis preceding the TO should not
be in the box. Also, the TO in the latter should not
be underlined.
I just tested a program using the statements:
ADD A B GIVING D.
ADD A B C GIVING D.
ADD A B TO C GIVING D.
with the directives FLAG "ANS74" and FLAG "ANS85".
Only the third statement gave a message for ANS74.
No messages were given for ANS85. This is what
I understand the standards to be.
|
|
|
|
|