April
 

Subject:
Author: 

Interpretation Request – Distinguishing separators from editing symbols
William M. Klein (wmklein@ix.netcom.com

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 (draft) 2002 Standard:

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

“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

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”

“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 (draft)
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:

April
 

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

This means that the (draft) 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 (draft) Standard requires that:

A picture character-string may end with a period of 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
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:

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.
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) is

I  still  question  that  all  of  this  is  “clear”  in  the  current  (draft)  Standard.    If  any  of  my
understandings are in error, I question that the “correct” interpretation is any clearer given the

current  rules  in  the  (draft)  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.