Entry Parameters

[bvining@xxxxxxxxxxxx]

Warning:  If you aren't into CCSIDs, multilingual support, and topics
associated with those; please don't read any further.

>
>Hello Bruce,
>
>It didn't occur to me that braces would be variant.  It does make sense
>but I assumed '}' would be invariant because of its position.
>

Agreed.  Some developers have found out the hard way about variant
characters such as numeric pound sign, at sign, and dollar sign.  But
once one goes beyond the basics (A to Z,.:;?()'/-_&+%*=<>) you find
variance (sometimes isolated exceptions like Turkish having the quote (")
variant or some Japanese code pages with lowercase a to z variant;
sometimes large exceptions where multiple code pages have variance such
as with the closing brace).

>
>So, while doing this would be OK if the character value were being
>passed from a HLL program compiled under code page 37, it would not
>work from CL which will interpret the code points at runtime. Correct?
>

Compiler/runtime sensitivity to CCSIDs is a complex matter that really
needs a chalk/erasure board to go over as there are alot of
considerations.  The CLP, with a source file of 37 but a job CCSID of say
273 at compile time, will cause a constant of x'DC' to be stored in the
program even though the source input is x'D0'.  Run time will not cause
this to change (that is, the called program will receive x'DC'
regardless of the job CCSID at execution time).  CL runtime does have
CCSID considerations for variant characters, but they are distinct
from this discussion of constant passing.

An ILE HLL where the root source is 273 and there is an include file of
CCSID 37 that has x'D0' will cause the x'DC'; but change the root to 37
and include a 273 file containing x'DC' and you'll end up with x'D0'.
Now change the HLL from ILE to OPM and watch out as the rules change.
Throw in that the variant character is not a compile time constant but
instead stored in a file somewhere; and another set of considerations
come into play.

The "secret" to avoid all this stuff is, of course, to avoid variant
characters in program source.  Then none of this comes into play.
Unfortunately the need to pass negative zoned decimal values from the
command line brought us (inadvertently) into this arena of variance.

>
>And, of course, it would work from the command line provided the
>programmer knew what character was represented by X'D0'.
>

Correct (assuming the device CHRID/KBDTYPE matched the job CCSID as
the system (UIM, WS) can be told to automatically convert from the
keyboard CHRID to the job CCSID which could again cause a code point
conversion).

>
>And it would change depending on installed national language and device
>description keyboard type.  Correct?
>

The device description KBDTYPE and CHRID values would be the important
factors here.  The National Language Version installed would have an
influence due to the default system values associated with KBDTYPE and
CHRID.

>
>Regards,
>Simon Coulter.
>


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---