Re: Variant characters in source-code

On 21-Apr-2015 14:18 -0500, Luis Rodriguez wrote:

Both my system (V5R3) and my job are running under CCSID(284). To be
sure, I just created a new PC5250 session and made sure it was
running under CCSID(284) and created a new library and source file
that shows, sure enough, a CCSID(284) under DSPFD.

Tried #FIELD: Got a RNF3301 . Loosely translated it states that the
"Name entry is not valid".
Tried ÑFIELD: No errors.

What am I missing here?

I usually test before posting, or preface with a comment suggesting that I had not tested and\or can not test. So... Nothing was missed; my comments with regard to the use of the proper glyph for the CCSID of the source are just flat-out wrong. Indeed, the glyph providing the proper code point must be used [for a /valid/ name] instead of merely the appropriate glyph, despite the source code being tagged properly.

I must have been dreaming that the compilers had eventually ameliorated the situation that had persisted prior to CCSID support. No idea why nor when I had thought such support arrived, as I know the support was not there immediately with the support for a CCSID in the source files.

While I know that object names [including record format] and field names always have been stored as the code-points rather than as /characters/, I mis-remembered what CCSID support was provided by the [pre]compilers with regard to treatment of those names. My false recollection was that the compilers would load the names from external reference having been converted [as if coming] from CCSID(37) into the CCSID of the source, and that name specifications [variables and object names] within the source were validated according to the CCSID of the source rather than as code points. For some reason, my recollection was that only C had the issue remaining, whereby the character at the code-point would need to be specified.

I have always and still do discourage use of variant characters, but I clearly had forgotten *just how perverse* the issue was within a purely EBCDIC setting, in contrast with how much less problematic things could be. Being away from the real work [expression: being /out-of-the-trenches/]for so long, allows for such dreams to eclipse the realities that are no longer being encountered\confronted :-)