Any reference to an ASCII or Unicode term where the value contains characters outside the invariant EBCDIC character set will clearly have a value which depends on the EBCDIC code page in which the source was written. This means that it is not possible to determine the binary value of such a constant from the written or printed form of the program. This language limitation was originally considered a possible reason not to support ASCII and Unicode self-defining terms at all, but we decided that it would be a useful language extension anyway.
The code page conversion only affects the binary values of generated character constants and self-defining terms. It does not affect the source code or listing (except in the Linux environment, where the EBCDIC and ASCII options determine source file and listing conversion). All source files and listings are assumed to be in the local EBCDIC code page as specified on the EBCDIC option or assumed by default. The CCSIDs used to generate character constants can be modified using ACONTROL, so it is possible for DC character constants in different parts of the same program (possibly generated by different macros or copy books) to be generated in different national language code pages, while appearing correct in the source program and listing. However, this function is only expected to be useful in rare cases, such as when messages in multiple national languages need to be included in assembled code and it is not convenient to use a separate module for each language. Note that IBM product macros will normally expect EBCDIC data to be generated unchanged, so it is safest not to use the CE option as an installation default, although the risks are low. For example, if an IBM macro checks for valid characters in a macro parameter such as a DDNAME which will be generated as a character constant, the macro will assume that the generated codes will be the same as the source, so if a variant character such as the dollar symbol is used, the check may accept it as valid but the assembled constant may generate an invalid symbol. Jonathan Scott, HLASM IBM Hursley, UK
