Document Number: J4/03-0049
February 28, 2003
D-2.2 Page 1 of 4
Subject:
Distinguishing separators from editing symbols
Author:
Thane A. Hubbell
Previous Version:
J4/03-0010
References in Document:
1.
ISO/IEC FDIS 1989:2002, Programming language
COBOL:
a.
Page 81, 8.3.2 Separators.
b.
Page 82, 8.3.2 Separators, Item 4.
c.
Page 829, F.2 Substantive changes not affecting
existing programs, Item 101.
Other References:
2.
02-0099 – Interpretation request -
Distinguishing
separators from editing symbols (Klein)
William M. Klein (wmklein @ ix.netcom.com ), a US Citizen.
The defect was submitted directly to J4 by Mr. Klein.
[Editorial note – the initial submitter referenced the (Draft) standard. (Draft) has
been removed by the author with the submitters approval]
I am unclear as to what rules apply for distinguishing separators from editing symbols in and after
a picture character-string. Specifically, it is unclear to me if the following code is or is not
conforming to the 2002 Standard:
Document Number: J4/03-0049
February 28, 2003
D-2.2 Page 2 of 4
The issue is whether the “,“ after “99” is an editing symbol (“,”) followed by a separator space
followed by a Value clause and, therefore, this is non-conforming source code according to SR(8)
of the Picture clause which states,
“8) If the symbol ',' or the symbol '.' is the last symbol of character-string-1, the PICTURE
clause shall be the last clause of the data description entry and shall be followed
immediately by the separator period.”
or rather, that the “, “ is a separator comma, because that same SR(8) indicates that a “,” may not
be the last symbol of a picture character-string that is not followed by a separator period
(optionally preceded by one or more spaces).
It should also be noted that the “lead-in” to the definition of separators at “8.3.2 Separators”
states,
“A separator is one of the following, except when appearing in a literal or picture
character-string:”
This seems (to me) to lead to the paradox, that you need to know what separator terminates a
picture string to be able to determine what symbols precede the separator – but that you also
need to know where the picture character-string ends to determine what separator follows it.
My initial understanding that any comma or period that was “attached” to characters that formed a
picture character-string was automatically a part of the picture character-string. If this
“evaluation” (of a symbol “.” or “,” as editing symbols) violated other explicit rules of the Standard,
then this meant that the source code was non-conforming, not that the symbols “automagically”
became separators. However, if this is the case, then one is left believing that the following (quite
common in ’85 Standard source code) syntax would be non-conforming:
Because the “.” at the end of Data-2’s definition would be forced into being an editing symbol and
not a separator. However, I see no “consistent” way to call this example conforming source code
without also calling the first example conforming source code and that results in the possible
(unintended?) “anomaly” that”
This means that the Standard requires that one “parse” not only the next token (to see if it is a
separator or not) but also the token after that to see if it is or is not a separator period.
Summary
I now believe (but am far from certain) that the Standard requires that:
Document Number: J4/03-0049
February 28, 2003
D-2.2 Page 3 of 4
A)
A picture character-string may end with a period or comma and that such characters are
part of the picture character-string IF AND ONLY IF they are followed immediately by a
separator period (optionally with one of more spaces between the period or comma and
the separator period).
B)
It is conforming source code for a picture character-string to be followed immediately
(with no intervening spaces) by a separator comma which may then be followed by any
conforming data definition clause except a separator period (because if the separator
period follows, the preceding rule applies).
C)
If the symbols of a picture character-string “seem” to end in a period:
1)
It is a separator period (not part of the picture character-string) if the next
source code element (after any spaces) begins a new data-definition or
section or division.
2)
It is an editing symbol (part of the character-string) if the next source token is
a separator period or space(s) before a separator period.
3)
It is non-conforming source code if the next source token (after any spaces)
is a data definition clause other than a separator period.
I still question that all of this is “clear” in the current Standard. If any of my understandings are in
error, I question that the “correct” interpretation is any clearer given the current rules in the
Standard. I also question that (assuming my understanding is correct) that it was intended that a
compiler must “read ahead” as far as it (now) must to determine the category of a period of a
comma that might be at the end of a picture-character string, and, furthermore, I am not certain
that the current REPLACE and COPY/REPLACING rules handle this “distinction” between
separators and editing symbols – especially in cases where a data definition clause may or may
not be “added” by COPY/REPLACING or REPLACE processing after a picture character-string
that also “seems” to end in a comma or period.
None provided with the initial interpretation request.
J4 discussed the proposed response and modified the wording slightly. It was
determined that the removal of the substantive change not affecting was correct and that
no change potentially affecting is necessary, thus removing the open issue.
Open Issues
None
"05 Data-1 Pic 99, Value Zero." is conforming source code,
and the comma that appears after the 99 is treated as a separator, and not
Document Number: J4/03-0049
February 28, 2003
D-2.2 Page 4 of 4
part of the picture character string. Page 313, Picture Clause, 13.16.38.2 syntax rule 2
helps to make it clear that the comma is not part of the picture character string. The
changes for 8.3.2 Separators, makes this clear. The substantive change entry that
indicates that "05 Data-1 Pic 99. ." is conforming is in error as the first period should be
treated as a separator not as an editing symbol. Thus, “05 Data-1 Pic 99. .” is a non-
conforming data-description entry.”
A modification to a future standard may be indicated as a result of this
interpretation. Further investigation in this area will be pursed.
The following changes to the Standard are needed:
1.
Page 81, 8.3.2 Separators, first sentence change to read:
“A separator is one of the following, except when appearing in a literal:”
2.
Page 82, 8.3.2 Separators, Item 4) change from:
“The COBOL characters right and left parentheses are separators. Except
in pseudo-text, parentheses may appear only in balanced pairs of left and right
parentheses delimiting subscripts, a list of function or method arguments, a
reference modifier, arithmetic or boolean expressions, or conditions.”
to:
“4) Except when appearing in a picture character-string, the COBOL
characters right and left parentheses are separators. Except in
pseudo-text, separator parentheses may appear only in balanced pairs of left and
right parentheses delimiting subscripts, a list of function or method
arguments, a reference modifier, arithmetic or boolean expressions, or
conditions.”
3.
Page 829, F.2 Substantive changes not affecting existing programs, Item
101. Remove the item.
