12 December 2010
OWG-1/29-0016
Page 1 of 16
Subject:
Refinements to currency sign and currency symbol rules
Author:
Charles C. Stevens
Document references:
1) ISO/IEC 1989:20xx CD 1.2
2) PL22.4/02-0128, Defect report – multiple currency signs (Jones).
3) PL22.4/06-0135, Currency Sign, String, and Symbol Issues with
related (and not so related) problems (Klein)
4) PL22.4/09-0121, Currency sign (et al) Follow Up (Paper 1 of 3)
(Klein)
5) PL22.4/09-0122, Currency sign (et al) Follow Up (Paper 2 of 3)
(Klein)
Author's general comments [probably to be deleted before final
distribution]:
On national literals as currency symbols:
The advisability and utility of allowing national literals as currency symbols
was carefully considered. The major problem with this is that the utility is
marginal at best.
An examination of the rules for LOCALE lead the author to the string
suspicion (subject to correction by those with better understanding in this
area) that the processing of numeric-edited items is first performed
according to the non-LOCALE rules, then a secondary process converts
that information into the format specified by the LOCALE. As the rules for
that secondary processing are delegated to a separate International
Standard (ISO/IEC 9943:-2:1993), that processing is outside the purview
or direct control of either the user or the COBOL standard.
On hexadecimal literals as currency symbols:
The meaning of hexadecimal literals is consistently described as being
determined at run time. Since the identification of a currency symbol
within a PICTURE character-string must take at compile time, since a
currency symbol must be chosen from a limited set of characters, and
since it is not possible to "embed" a hexadecimal value directly among the
characters in a PICTURE character-string, this author believes allowing a
hexadecimal literal as a currency symbol is a fundamentally bad idea,
regardless of whether it is currently allowed by the syntax rules or not.
12 December 2010
OWG-1/29-0016
Page 2 of 16
On the use of non-COBOL characters as currency symbols:
Despite PICTURE clause Syntax Rule 2 as currently written, this author
believes that the intent of the standard is to allow currency symbols such
as the UK pound, the Euro, and the Japanese Yen to be used as currency
symbols. Certainly a number of implementations are based on that
assumption. These (and other similar) characters are not allowed in
library text, source text, or pseudotext for processing through COPY …
REPLACING and REPLACE. This document proposes notes in several
places recommending against the practice, without the (current) intent to
archaize it.
On the impact of non-COBOL characters as currency symbols on COPY and
REPLACE:
The author is preparing a document whose current direction is to provide a
specific mechanism for the substitution of non-COBOL characters in
COPY … REPLACING and REPLACE by creating a new form analogous
to the text-word,
It might be equally effective to provide NOTEs to the effect that using nonCOBOL characters in or as text-words is not conforming COBOL, though it
may be allowed as an implementor extension.
After all, if the currency STRING contains a non-COBOL character, the
author already proposes NOTEs to the effect that it's a really good idea to
specify the currency symbol explicitly from within the COBOL character
repertoire, and perhaps leaving the text-word definition as is and noting
that this is a fundamental limitation on COPY and REPLACE that will not
be treated as an error.
If you want to have a non-COBOL character as the currency string, the
best and most portable way to do that is to make sure the symbol is part of
the COBOL character repertoire by providing a COBOL character as the
currency symbol for the non-COBOL currency string, even if the string is a
single character.
More generally, if you don't like the consequences of having a nonCOBOL character as a currency symbol (in particular, on COPY and
REPLACE), then the most obvious and effective solution is to avoid the
practice, not expect the standard to provide a mechanism to change those
consequences. .
12 December 2010
OWG-1/29-0016
Page 3 of 16
Discussion:
The original issue precipitating this effort is described in Reference 2. This led to
further investigation in the area, and much of the additional background
information may be found in References 3 -5. Considerable correspondence
between this author of References 3-5 and the author of these documents led to
the direction taken in this paper.
PL22.4 elected to defer all these issues to the revision.
During the course of this investigation, it was noted that numerous instances of
"the currency symbol" appeared throughout the standard. This is no longer
appropriate in most cases given the possibility of multiple currency symbols
within a single program as introduced with ISO/IEC 1989:2002, and changes are
recommended to correct these cases for clarity.
Details of the individual issues raised in references 2, 3, 4, and 5 are
summarized as follows:
1) PL22.4/02-0128 (reference 2) notes that multiple currency sign clauses
using the same currency sign are allowed by the standard, and proposes
that the last encountered be used. .
Recommended response: Duplicate currency strings are allowed;
the rules are being revised to specify that each of the duplicate
currency strings must be associated explicitly with a unique
currency symbol through the PICTURE SYMBOL phrase of the
CURRENCY SIGN clause.
2) PL22.4/06-0135 (reference 3) item 1 notes that literal-7 in the
CURRENCY SIGN clause may be a national literal, but that literal-8 may
not be. Allowing literal-8 to be a national literal should be considered as a
candidate for a future revision.
Recommended response:
Since the PICTURE character-string
for a USAGE NATIONAL data item is limited to the alphanumeric
characters N, B, / and 0, there is no demonstrable enhanced utility
in allowing a national literal as a currency symbol, and considerable
risk of ambiguity and confusion. The rules are being revised to
clarify that national literals as literal-8 (and for that matter literal-7
when literal-8 is not specified) oin the CURRENCY SIGN clause
are not permitted.
12 December 2010
OWG-1/29-0016
Page 4 of 16
3) PL22.4/06-0135 (reference 3) item 2 notes the absence of a rule
prohibiting multiple instances of literal-7 from having the same value (with
or without currency symbols).
Recommended response: The rules are being revised to specify
that duplicate currency strings are permitted so long as each of
them has a currency symbol that is unique within the program.
4) PL22.4/06-0135 (reference 3) item 3 notes that in the absence of
PICTURE SYMBOL phrases there is no rule prohibiting two currency
strings which are also used as currency symbols from matching after case
mapping.
Recommended response: The rules are being revised to specify
that currency symbols within a program must be unique, after case
mapping, whether or not they are specified by PICTURE SYMBOL
phrases.
5) PL22.4/06-0135 (reference 3):item 4 notes that no rule prohibits a
currency string used also as a currency symbol from having the same
value (with or without case mapping) as another currency symbol. .
Recommended response: The rules are being revised to specify
that currency symbols within a program must be unique, after case
mapping, whether or not they are specified by PICTURE SYMBOL
phrases.
6) PL22.4/06-0135 (reference 3) item (first) 5 notes that there is no
prohibition against having a national currency symbol and an alphabetic
currency symbol that equate to the same value according to the COBOL
character repertoire rules. It also notes that the USAGE of the currencystring must be the same as that of the data item.
Recommended response: The rules are being revised to specify
that national literals are disallowed as currency symbols, whether
specified by literal-7 or literal-8, and that currency symbols must be
unique within a given program.
Since the symbols B, /, 0 and N are the only ones allowed in a
USAGE NATIONAL data item, a currency STRING of USAGE
NATIONAL for a numeric-edited data item (which cannot be of
class national) is of no utility, though it is permitted so long as a
12 December 2010
OWG-1/29-0016
Page 5 of 16
letter from the computer's coded character set is specified as the
associated picture symbol. No change is needed on this account.
7) PL22.4/06-0135 (reference 3) item (first) 6 subitem A notes that when
literal-7 is used as both a currency symbol and a currency string, it is
treated "as if uppercase", and that this may imply that the currency
STRING is not converted to upper case but left as is
Recommended response: The rules are being revised to clarify
that the value of a currency string is not converted in any way for
output, input, and data comparison and conversion purposes.
Uppercase and lowercase instantiations of the same character can
be used as currency strings in a given program provided BOTH of
them specify unique currency symbols. When a CURRENCY SIGN
clause does not include the PICTURE SYMBOL phrase, an
uppercase character as both the currency string and the currency
symbol is treated as equivalent to its corresponding lowercase
character for purposes of matching with the contents of a PICTURE
character-string.
8) PL22.4/06-0135 (reference 3) item (first) 6 subitem B notes that in general
character mapping in COBOL is from upper to lower case, but in the case
of PICTURE this sense is reversed, and for that reason some ambiguities
may arise.
Recommended response: Although the value of the currency
string is used exactly as specified, uppercase and lowercase
instantiations of the same character are equivalent in terms of the
currency symbol. The rules are being revised to make it clear that
programmatic comparisons between the PICTURE character-string
and the currency symbol are based on lowercase equivalence.
9) PL22.4/06-0135 (reference 3) item (second) 5 subitems A-i and A-ii note
that there are some ambiguities in the specifications as to which
characters can be used as currency symbols and which cannot.
Recommended response: The rules are being revised to make it
more explicit exactly which sets of characters can be used as
currency symbols.
Issues surrounding the use of non-COBOL characters in, or as,
text-words in source text, library text, and in the
COPY…REPLACING and REPLACE statements are to be
addressed in a future effort.
12 December 2010
OWG-1/29-0016
Page 6 of 16
10) PL22.4/06-0135 (reference 3) item (second) 5 subitem A-iii notes the
limitation of "text-wors" to separators, literals, and strings of characters
from the COBOL character repertoire.
Recommended response: Issues surrounding the use of nonCOBOL characters in, or as, text-words in source text, library text,
and in the COPY…REPLACING and REPLACE statements are to
be addressed in a future effort.
11) PL22.4/06-0135 (reference 3) item (second) 5 subitem A-iv notes that
many implementations allow the yen (¥), UK pound (£), and Euro (€) signs
as currency symbols. These characters are not included in the COBOL
character repertoire, and recommends that they (and other non-COBOL
characters) be allowed as currency symbols.
Recommended response: The rules are being revised to allow
characters from outside the COBOL character repertoire to be used
as currency symbols.
Cautionary NOTEs are also being added to suggest that when the
currency string is a single character from outside the COBOL
character repertoire, the use of the PICTURE SYMBOL phrase to
supply a currency symbol from within that set is recommended on
the grounds of increased likelihood of portability.
12) PL22.4/06-0135 (reference 3) item (second) 5 subitem A-v notes that
such characters as the yen, UK pound and Euro signs are prohibited in
text-words, although many implementations allow such use. This can
create incompatibilities between implementations.
Recommended response: Issues surrounding the use of nonCOBOL characters in, or as, text-words in source text, library text,
and in the COPY … REPLACING and REPLACE statements are to
be addressed in a future effort.
13) PL22.4/06-0135 (reference 3) item (second) 5 subitem B-i notes that
SPECIAL-NAMES GR18 and GR20 do not specify the character repertoire
from which the content of the currency string must be chosen when there
is no associated PICTURE SYMBOL phrase.
Recommended response: The use of literal-7 as both the
currency symbol and the currency sign in this case limits the
content of literal-7 to those characters that are also legitimate as a
12 December 2010
OWG-1/29-0016
Page 7 of 16
currency symbol. Associated rules as to the content of a currency
symbol are being revised.
14) PL22.4/06-0135 (reference 3) item (second) 5 subitems B-ii and B-iii note
that while the currency symbol, when explicitly declared, can be any
character from the computer's coded character set, while Syntax Rule 2 of
PICTURE disallows any character from outside the COBOL character
repertoire.
Recommended response: Syntax rule 2 of the PICTURE clause
is in error (see for example Syntax Rule 8 of the PICTURE clause
which conflicts with it) in not allowing the currency symbol, and is
being revised to correct that error.
15) PL22.4/06-0135 (reference 3) item (second) 5 subitem B-iv notes that
characters in text-words are limited to those in the COBOL character
repertoire.
Recommended response: Issues surrounding the use of nonCOBOL characters in, or as, text-words in source text, library text,
and in the COPY … REPLACING and REPLACE statements are to
be addressed in a future effort.
16) PL22.4/06-0135 (reference 3) item (second) 5 subitem C-i notes
ambiguities in the rules regarding the use of characters from the
computer's coded character set that are not also in the COBOL character
repertoire in the CURRENCY SIGN clause without the PICTURE
SYMBOL phrase.
Recommended response: The rules specifying the allowable
content of currency symbols and the PICTURE character-string Iare
being revised to eliminate these ambiguities.
17) PL22.4/06-0135 (reference 3) item (second) 5 subitem C-ii notes that
such characters were not allowed as text-words in source text, library text,
or pseudo-text, whether or not they were allowed in picture characterstrings.
Recommended response: Issues surrounding the use of nonCOBOL characters in, or as, text-words in source text, library text,
and in the COPY … REPLACING and REPLACE statements are to
be addressed in a future effort.
12 December 2010
OWG-1/29-0016
Page 8 of 16
18) PL22/06-0135 (reference 3) subitem C-iii notes that characters that are
not within the COBOL character repertoire are permitted in the currency
symbol according to the rules for SPECIAL-NAMES, but prohibited in
PICTURE character-strings by SR2 of the PICTURE clause. This renders
their specification as currency symbols useless in conforming COBOL
programs. It also notes that they are not allowed in text-words.
Recommended response: The rules specifying the allowable
content of currency symbols and the PICTURE character-string Iare
being revised to eliminate these ambiguities.
Issues surrounding the use of non-COBOL characters in, or as,
text-words in source text, library text, and in the COPY …
REPLACING and REPLACE statements are to be addressed in a
future effort.
19) PL22.4/06-0135 (reference 3) item (second) 5 subitem D notes that the
yen sign, pound sign, and euro sign fall outside the COBOL character
repertoire and are not technically permitted as currency symbols, and
since they are also not permitted in text-words, this causes problems for
text-words in COPY and REPLACE. .
Recommended response: The rules specifying the allowable
content of currency symbols and the PICTURE character-string are
being revised to allow the use of such characters as currency
symbols.
Cautionary NOTEs are also being added to suggest that when the
currency string is a single character from outside the COBOL
character repertoire, the use of the PICTURE SYMBOL phrase to
supply a currency symbol from within that set is recommended on
the grounds of increased likelihood of portability.
Issues surrounding the use of non-COBOL characters in, or as,
text-words in source text, library text, and in the COPY …
REPLACING and REPLACE statements are to be addressed in a
future effort
20) PL22.4/06-0135 (reference 3) item (second) 6 notes that hex literals
represent bit patterns from the runtime character set, but in certain cases
they must be interpreted at compile time. Understanding of the value of a
hex literal at compile time seems required in the following known contexts:
1) literal-1 and literal-2 of a COPY statement; 2) literal-1 in a constant
entry declaration, especially when that constant is used as a repetition
12 December 2010
OWG-1/29-0016
Page 9 of 16
specification in a PICTURE character-string. There may be other such
cases. .
Recommended response: The rules are being revised to prohibit
the use of hex literals as currency symbols. The valid values for
literal-1 and literal-2 in COPY statements are expressly defined by
the implementor. The use of a hex literal in a constant entry that is
referenced as the repetition specification in a PICTURE characterstring is to be addressed in a future effort. Suggestions as to what
other cases not yet identified require knowledge of the value and
meaning (and not just the actual content) of hex literals at compile
time are welcome.
21) PL22.4/06-0135 (reference 3) item 7 notes that there do not seem to be
any rules prohibiting more than one currency symbol from being used
within a given PICTURE character-string
Recommended response: The rules are being revised to prohibit
the use of more than one unique currency symbol within a given
PICTURE character-string. (Repetitions of the same currency
symbol, with no other currency symbol appearing in the PICTURE
character-string, are currently allowed for floating insertion).
.
22) PL22.4/06-0135 (reference 3) item 8 recalls discussions about the
allowance or disallowance of forward references to type-names, but
recalls no similar discussions about forward references to constant
entries. Prohibiting forward references to constant entries would prohibit
their use as literal-7 and literal-8 in the CURRENCY SIGN clause.
Recommended response: No general prohibition against forward
references is known to exist. No restriction preventing the use of
constant-names as either the currency string or the currency
symbol is intended here. No change is being made on this issue. .
23) PL22.4/06-0135 (reference 3) item 9 notes that it is unclear whether
"extended letters" from the COBOL character repertoire are allowed in
PICTURE character-strings as they explicitly are in user-defined words.
Recommended response: The rules for the content of the
PICTURE character-string are being revised to include the currency
symbol, which is permitted to be any character (with exceptions)
from the computer's coded character set, which is presumed to
include "extended letters".
12 December 2010
OWG-1/29-0016
Page 10 of 16
Cautionary NOTEs are also being added to suggest that when the
currency string is a single character from outside the COBOL
character repertoire, the use of the PICTURE SYMBOL phrase to
supply a currency symbol from within that set is recommended on
the grounds of increased likelihood of portability.
24) PL22.4/06-0135 (reference 3) item 10 notes the use of undefined
terminology ("case-insensitive") in the rules for the NUMVAL-C function
when the ANYCASE parameter is specified.
Recommended response: The argument rules for the NUMVALC intrinsic function are being revised to clarify the intent using
more-established terminology. Note that if argument-2 for this
function contains a currency string as a data item, it need bear no
relationship to any CURRENCY SIGN clause in the program.
When neither argument-2 nor the LOCALE parameter is included,
matching of the data in argument-1 is against the set of currency
strings in the program, and any comparisons between national or
alphanumeric letters in the data or in the currency strings are
compared against the data using their respective lowercase
equivalents when the ANYCASE keyword parameter is specified,
and are exact comparisons when it is not.
.
25) PL22.4/09-0121 (reference 4) item 1 notes that the "formal" definitions for
"currency symbol" and "currency string" are found in the general rules for
the CURRENCY SIGN clause and recommends they be moved
somewhere before SR18 so that they can be used in the syntax rules.
Recommended response: Rather than enhance or correct the
glossary entry for a given technical term in the standard, the
general practice is to insure that an index entry points to the
functional definition. As part of the revision to SR18, the term
"currency string" is being more formally defined within this syntax
rule. SR19 will be modified to define similarly the term "currency
symbol" for the case in which literal-8 is not specified, and SR22
will be modified to define the term for the case in which literal-8 is
specified. The project editor will be asked to ensure that index
entries for currency string and currency symbol exist for these
pages.
26) PL22.4/09-0121 (reference 4) item 2 suggests better specifications for
the equivalence of currency symbols as distinct from currency strings. It
also suggests that these rules include equivalence of uppercase to
12 December 2010
OWG-1/29-0016
Page 11 of 16
lowercase, hexadecimal and nonhexadecimal literals, and alphanumeric
and national literal representations of the same alphanumeric characterl
Recommended response: The rules for currency symbols are
being revised to reflect the equivalence of an uppercase
alphanumeric letter to its lowercase equivalent.
The rules are also being revised to prohibit hexadecimal and
national literals as currency symbols.
27) PL22.4/09-0121 (reference 4) item 3 suggests that a syntax rule be
added such that no two currency clauses may specify equivalent currency
symbols.
Recommended response: The rules for the CURRENCY SIGN
clause are being revised to reflect that sentiment. These rules are
also being revised to allow duplicate currency strings so long as
each of the duplicates has an explicitly-specified currency symbol
through the PICTURE SYMBOL clause.
28) PL22.4/09-0121 (reference 4) item 4 recommends the rule noting that a
lowercase character appearing as a currency symbol is equivalent to its
corresponding uppercase character be rewritten. .
Recommended response: The rules are being revised to reflect
the fact that an uppercase letter appearing as a currency symbol or
within the PICTURE character string is considered equivalent to its
corresponding lowercase representation.
29) PL22,4/09-0121 (reference 4) item 5 recommends that the rules be
clarified to ensure that the currency string is represented for input, output,
and compatibity of data exactly as it appears in literal-7 of the
CURRENCY SIGN clause.
Recommended response: The rules are being revised to clarify
that literal-7 is the exact representation of the currency string and
no "case folding" occurs for it in that role (input, output, and validity
checking). If literal-7 is also used as the currency symbol, an
uppercase character appearing there, or in the PICTURE
character-string with which it is being compared during compilation,
is treated as its equivalent lowercase representation for comparison
purposes..
,
12 December 2010
OWG-1/29-0016
Page 12 of 16
30) PL22,4/09-0121 (reference 4) item 6 recommends the clarification of a
perceived conflict between SR18 and SR22 of the SPECIAL-NAMES
paragraph that appears to allows the currency symbol to be a national
literal if no PICTURE SYMBOL phrase is associated with its declaration,
but not if the declaration of that currency symbol is explicit.
Recommended response: The rules are being revised to prohibit
the use of a national literal as the currency symbol, whether that
symbol is represented by literal-7 or literal-8.
31) PL22.4/09-0121 (reference 4) item 7 recommends that all changes made
as a result of all these clarifications be examined to ensure their validity in
the context that a LOCALE phrase has been used in defining a numericedited item.
Recommended response: When a LOCALE is in effect, the
information is processed according to the rules without the
LOCALE, and then reprocessed according to the LOCALE. That
secondary processing is handled according to a different
International Standard, and is outside the purview of this standard.
No change is needed.
32) PL22.4/09-0122 (reference 5) items 1 and 2 recommend that all cases in
which a hexadecimal literal is allowed throughout the standard be
examined to determine whether it is necessary for the corresponding
value to be determined at compile time, and rules written to resolve these
issues.
Recommended response: The rules for the currency symbol are
being revised to prohibit hexadecimal literals in that context.
Determination of other cases in which the ultimate representation of
the hexadecimal literal needs to be known at compile time, and
development of rules to provide for these circumstances, is
deferred to a future effort.
33) PL22.4/09-0122 (reference 5) item 3 suggests the use of a FLAG-nn
feature to flag hexadecimal lilterals whose value and meaning must be
known at compile time.
Recommended response: Flagging of hex literals used as
currency symbols is unnecessary; they are now prohibited.
12 December 2010
OWG-1/29-0016
Page 13 of 16
The following are deferred to a future effort: 1) Determination of
cases other than the CURRENCY SIGN clause in which the
ultimate representation of the hexadecimal literal needs to be
known at compile time; 2) development of rules to provide for these
circumstances; and 3) determination as to whether a FLAG-nn
mechanism is appropriate for each such circumstance.
Changes recommended for the revision:
1)
Page 66, 8.2.1, Locale field names, entry for LC-MONETARY items "p-csprecedes" and "n-cs-precedes": Change both in part to read " … whether a
currency symbol precedes …"
2)
Page 82, 8.3.1.3, PICTURE character-strings, introductory paragraph:
Change in part to read "… composed of a currency symbol that …"
3)
Page 221, 12.3.6.3, SPECIAL-NAMES paragraph, Syntax Rule 18: Add
the following sentence: Literal-7 is the currency string associated with this
particular CURRENCY SIGN clause. When literal-8 does not appear in the
CURRENCY SIGN clause, literal-7 is also the currency symbol associated
with the clause." Add an index entry for this rule (it is the formal definition of
"currency string" and half the definition of "currency symbol").
4)
Page 221, 12.3.6.3, SPECIAL-NAMES paragraph: Add three new syntax
rules immediately after SR18 (renumbering the remainder accordingly:
18a) If literal-7 is a hexadecimal literal or a national literal, the
PICTURE SYMBOL phrase shall be present in the CURRENCY SIGN
clause.
18b) If two or more occurrences of a currency string have the same
value, the CURRENCY SIGN clause associated with each of them
shall include the PICTURE SYMBOL phrase, specifying a unique
currency symbol for each of them. .
18c) No two occurrences of a currency symbol may have the same
value, nor may they have the uppercase or lowercase equivalent to
that value.
5)
Page 221, 12.3.6.3, SPECIAL-NAMES paragraph: Add the following
NOTE immediately after (current) Syntax Rule 20:
12 December 2010
OWG-1/29-0016
Page 14 of 16
NOTE The use of a character from outside the COBOL character
repertoire as literal-7 when the PICTURE SYMBOL phrase is not
specified, or as literal-8 when the PICTURE SYMBOL phrase is
specified, is not recommended, even though such use is permitted. In
cases such as this it is suggested that the PICTURE SYMBOL phrase
be used to specify a currency symbol from within the COBOL character
repertoire. The subset of the computer's character repertoire that is
not also part of the COBOL character repertoire is defined by the
implementor; for that reason, the possibility exists that programs using
a character from outside the COBOL character repertoire for the
currency symbol may not be portable to other implementations
because the computer's coded character set on other implementations
might not include the character in the currency symbol. .
6)
Page 221,12.3.6.3, SPECIAL-NAMES paragraph, Syntax Rule 22:
Change in part to read " … figurative constant or a hexadecimal literal. No
two … " Add the following sentence at the end: "Literal-8, when specified, is
the currency symbol associated with the currency string specified in the
CURRENCY SIGN clause." Add an index entry for this rule; it is the second
half of the formal definition of "currency symbol".
7)
Page 225, 12.3.6.3, SPECIAL-NAMES paragraph, General Rule 13,
antepenultimate paragraph: Change to read "Literal-7 represents the value of
the currency string. For character matching between literal-7 and input or
output data or for checking for data compatibility against the currency string,
the representation of the currency string in the data shall be exactly as it
appears in literal-7 unless explicitly specified elsewhere."
8)
Page 226, 12.3.6.3, SPECIAL-NAMES paragraph, General Rule 13, first
paragraph: Change in part to read " … is referred to as a currency symbol."
9)
Page 226, 12.3.6.3, SPECIAL-NAMES paragraph, General Rule 13, last
paragraph: Change to read "An uppercase character appearing as a
currency symbol is treated as if it were its lowercase equivalent for purposes
of matching with PICTURE character-strings. An uppercase character
appearing as a picture symbol is treated as if it were its lowercase equivalent
for purposes of matching with currency symbols.
10)
Page 338, 13.18.39.1, PICTURE clause, Syntax Rule 2: Change to read
"Character-string-1 shall consist of an allowable combination of characters
used as symbols. All such characters, with the exception of a currency
symbol, shall be from the COBOL character repertoire.
12 December 2010
OWG-1/29-0016
Page 15 of 16
11)
Page 338, 13.18.39.1, PICTURE clause: Add the following NOTE after
Syntax Rule 2:
NOTE: The use of a character other than the basic letters, basic
special characters, and extended letters of the COBOL character
repertoire as a currency symbol is not recommended. The PICTURE
SYMBOL phrase of the CURRENCY SIGN clause may be used to
specify an association between the desired currency string and a
currency symbol from among the basic letters and basic special
characters of the COBOL character repertoire.
12)
Page 338, 13.18.39.1, PICTURE clause, Syntax Rule 3: Change to read
"All uppercase letters in character-string-1 are equivalent to their
corresponding lowercase representations."
13)
Page 338, 13..18.39.1, PICTURE clause, Syntax Rule 8: Change in part
to read " … or a currency symbol."
14)
Page 339, 13.18,39.1, PICTURE clause, Syntax Rule 24: Change in part
to read "A currency symbol, when used …"
15)
Page 340, 13.18.39.1, PICTURE clause, Syntax Rule 26: Change in part
to read " … when a currency symbol is used …"
16)
Page 340, 13.18.39.1, PICTURE clause: Add a new Syntax Rule
immediately after SR 28 (renumbering the remaining rules accordingly): "If a
currency symbol appears in a PICTURE character-string, only that currency
symbol shall appear in that PICTURE character-string.
17)
Page 340, 13.18.39.1, PICTURE clause, Syntax Rule 31: Change in part
to read " … '+', '.', and a currency symbol may appear …"
18)
Page 340, 13.18.39.1, PICTURE clause, Syntax Rule 33: Change in part
to read "A currency symbol and …"
19)
Page 341, 13.18.39.2, PICTURE clause, General Rule 12a, third bullet
item: Change in part to read "… a currency symbol."
20)
Page 341, 13.18.39.2, PICTURE clause, General Rule 12b: Change the
entry for "E" in part to read " … by the symbol 'E' or the symbol 'e'.
21)
Page 342, 13.18.39.2, PICTURE clause, General Rule 13, entry for "E":
Change in part to read "The symbols "E" and "e" represent …"
12 December 2010
OWG-1/29-0016
Page 16 of 16
22)
Page 343, 13.18.39.2, PICTURE clause, General Rule 14, entry for "cs":
Change in part to read " … corresponding to a currency symbol …"
23)
Page 345, 13.18.39.,3, PICTURE clause, General Rule 17, entry for "cs":
Change in part to read "A currency symbol indicates …"
24)
Page 347, 13.18.39.4, Editing Rule 5, Fixed insertion editing, Table 8:
Change the contents for "CR" in the editing symbol column to read "CR, cr",
and change the contents for "DB" to read "DB, db".
25)
Page 347, 13.18.39.4, Editing Rule 5, Fixed insertion editing: Change the
last paragraph to read "The uppercase letters CR are the insertion characters
for the insertion symbols 'CR' and 'cr'. The uppercase letters DB are the
insertion characters for the insertion symbols 'DB' and 'db".
26)
Page 348, 13.18.39.4, Editing Rule 9: Change in part to read " … used for
a currency symbol are determined …".
27)
Page 349, 13.18.39.5, Precedence rules, Format 1, first paragraph:
Change the last sentence in part to read "A currency symbol is indicated …".
28)
Page 350, 13.18.39.5, Precedence rules, Format 1, second paragraph:
Change the first sentence in part to read "A currency symbol …".
29)
Page 350, 13.18.39.5, Precedence rules, Format 1, fourth paragraph:
Change in part to read "The symbol 'P', a currency symbol when used …".
NOTE: Analysis of the above changes for candidacy for the "Substantive
Changes" lists, and provision of the appropriate entries, is left to a future
draft of this document.