Bill Klein wrote:
"Steve Comstock" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
<snip>
And I can't figure out why they made that change,
since DBCS is, supposedly, on its eventual way
out, to be replaced by NATIONAL (Unicode). Any
idea why the default was changed? Especially since
the vast majority of US shops do not even use
DBCS data?
NSYMBOL(National) *requires* (forces on) DBCS, so actually having/allowing
the DBCS option is a "pre-requisite" for having Unicode support.
Ah. Now that is just flat out wrong. The doc says it is
NSYMBOL({NATIONAL|DBCS}) - that is, one or the other.
Ahh, but wait. Same doc under "Conflicting Compiler Options",
it says NSYMBOL(NATIONAL) forces on the DBCS compiler option.
Now I'm really confused. Why would you set up a choice of
NSYMBOL({NATIONAL|DBCS}) when setting NATIONAL forces on DBCS?
Very nice.
There are some long and "painful" internal discussions (between myself and
the IBM ANSI COBOL rep) and within the J4 group about exactly what is
"Standard conforming" behavior when you have "control characters" within an
alphanumeric literal. I won't go into them here, but I semi-understand the
IBM position that ALLOWING "national" character strings within an
alphanumeric literal is a "good thing" when you MAY use X"0E" type notation
*if* you want to have those x'0d' and x'0e' within literals.
The change in defaults WAS highlighted in announcements, migration guides,
and installation material - but what its IMPLICATIONS were - are probably
unclear to most programmers (application or systems).
Yup.
Kind regards,
-Steve Comstock
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
