Variant characters in source-code (was: Interactive logic-style question)

On 21-Apr-2015 12:47 -0500, Luis Rodriguez wrote:

Suppose I just copy & paste Bob's code... I must translate all his
"#" to my "Ñ" .

No, there should be no reason to do so; not since CCSID support arrived, in what, V2R1M1? The effect of the copy\paste should have maintained the #-character [as the visible glyph]; i.e. the copy\paste feature should be doing a text-copy, not an binary-copy, and the copied #-character should be the visibly the same glyph as pasted data. The emulator should be aware of the CCSID of the data, and do the right thing. Solve that problem and rejoice.

What happens here is that # is not a part (IIRC) of EBCDIC's
"invariant character set", symbols that do not change between code
pages like, for example, 'a' thru 'z', digits, %, =, etc.

Correct; the "Number symbol" [aka "hash"] character is a variant character in EBCDIC. When only invariant characters are coded in the source code, then the text-data can be safely transported as binary data, irrespective the SBCS EBCDIC CCSID of the sender or recipient. Yet there is little excuse for transporting text data as binary; while the /code/ might be all invariant characters, surely one can not safely presume that all /comments/ within the source code are all invariant character as well, thus binary transport is still a conspicuously bad idea.

Besides, Ñ just look awful as part of a field name :-)

If you have to code the Ñ-character in field\variable names to enable compiles [i.e. in order to make the compiler understand the Ñ-character as th #-character], then your environment is apparently [improperly IMO, though alternatively described as /by poor choice/] has been established with a CCSID(*HEX). Properly tag the container of the source-code with a CCSID that matches the data, and the [emulator and the] compilers should understand the #-character to be the #-character and understand the Ñ-character to be the Ñ-character.