Document Number: J4/02-0230
D-2 Page 1 of 6
Subject:
Author:
Previous Version:
Distinguishing separators from editing symbols
Thane A. Hubbell
Not Applicable
References in Document:
1.
ISO/IEC FDIS 1989:2002, Programming language
COBOL:
Page 81, 8.3 Separators.
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 -
separators from editing symbols (Klein)
Distinguishing
William M. Klein, 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/02-0230
D-2 Page 2 of 6
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:
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).
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
B)
Document Number: J4/02-0230
D-2 Page 3 of 6
conforming data definition clause except a separator period (because if the separator
period follows, the preceding rule applies).
If the symbols of a picture character-string “seem” to end in a period:
C)
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.
It is non-conforming source code if the next source token (after any spaces)
3)
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 interpretation request, and came to the following conclusion:
Page 829, F.2.101, Substantive changes not affecting existing programs, is
incorrect.
The confusion generated by this incorrect Substantive Change notation may
have led to an incorrect interpretation by the submitter.
The author discussed this approach with the submitter, and the submitter noted
that even with the removal of this substantive change entry, the text of the
standard is still unclear as to whether or not the trailing periods and commas in
the picture string are really part of the picture string or are to be considered as
separators. The submitter now offers the following solution, which the Author
agrees is the correct response to the interpretation request:
On page 81, it states,
Document Number: J4/02-0230
D-2 Page 4 of 6
"8.3.2 Separators
A separator is one of the following, except when appearing in a literal or picture
character-string:"
But when you look at the list *ONLY* the parenthesis (left and right) can
ever appear as NON-separators in a CONFORMING picture character-string -
and not be separators.
Therefore, if that "introductory" sentence were changed to:
"A separator is one of the following, except when appearing in a
literal:"
and item 4 were changed to:
4) Except when appearing in a picture character-string, 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."
I think (but won't swear to it) that ALL the problems "go away" - both
those with logical conversion (COPY/REPLACE) *and* those for picture
character-string parsing.
Pic 99, .
and
Pic 99, Value zero.
are now conforming and are NOW numeric, not numeric-edited data items -
which at least some people thought all along)
Pic 99,.
would "remain" conforming numeric-edited definitions.
while
Document Number: J4/02-0230
D-2 Page 5 of 6
Pic 99. .
is NON-conforming, which SOME (but not all) '85 Standard implementations
thought was true. This would mean that the substantive change was wrong;
but there is already some question about that.
This would leave ONLY the parenthesis as an "exception" to the
text-word/separator rules, i.e. that they need to be treated "as if they
were separators" - and all other separator rules would "apply" for
determining text-words.
Since Pic 99. . will become non conforming as a result of the proposed change,
Page 829, F.2.101, Substantive changes not affecting existing programs,
remains incorrect and should be removed. The text there states:
PICTURE clause. When the last symbol of a PICTURE character-string is a
period or a comma, one or more spaces may precede the following separator
period. It was unclear in the previous standard whether a space could precede
the separator period in this context.
Open Issues
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.
Another interpretation request was received from the submitter, 02-0158,
2.
Interpretation Request – Distinguishing separators from decimal
separators. The work we do here on D-2 will likely impact this other
interpretation request. We could merge the two – which I am opposed to,
or simply ignore 02-0158 until after this defect report is complete. The
submitter is planning to review 02-0158 in light of the direction taken in
this defect report.
"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
Document Number: J4/02-0230
D-2 Page 6 of 6
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.
“A separator is one of the following, except when appearing in a literal:”
Page 81, 8.3 Separators, first sentence change to read:
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:
characters right and left parentheses are separators. Except in
“4) Except when appearing in a picture character-string, the COBOL
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.”
Page 829, F.2 Substantive changes not affecting existing programs, Item
