Document Number: J4/03-0010
January 13, 2003
D-2.1 Page 1 of 5
Subject:
Distinguishing separators from editing symbols
Author:
Thane A. Hubbell
Previous Version:
J4/02-0230
References in Document:
1.
ISO/IEC FDIS 1989:2002, Programming language
COBOL:
a.
Page 81, 8.3 Separators.
b.
Page 82, 8.3 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-0010
January 13, 2003
D-2.1 Page 2 of 5
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-0010
January 13, 2003
D-2.1 Page 3 of 5
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 considered the discussion and subsequent investigation and determined that
with some minor wording changes, the suggested response from D 2.0 was
acceptable. However, the second sentence of suggested change 2, page 82, 8.3
Separators, Item 4 really might better serve as a note rather than as a rule. This
is because the syntax rules always specify the pairing of parenthesis. Changing
it at this point may be error prone. Correcting this portion might be considered
with the work of a future revision.
J4 also determined that the second open issue, is not an open issue. The
Interpretation request made in 02-0158 is in no way related to this response.
Open Issues
Document Number: J4/03-0010
January 13, 2003
D-2.1 Page 4 of 5
1.
Removal of this substantive change not effecting means that we may have
made a substantive change potentially affecting as we have now labeled
“Pic 99. . “ nonconforming. Some implementations may have allowed
this construct. At least one implementation of the 85 standard does allow
this without a warning or error.
"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
part of the picture character string. The substantive change entry which
indicated that "05 Data-1 Pic 99. ." was conforming was 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-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 Separators, first sentence change to read:
“A separator is one of the following, except when appearing in a literal:”
2.
Page 82, 8.3 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.
Document Number: J4/03-0010
January 13, 2003
D-2.1 Page 5 of 5
