Literals (Was: OPNQRY reference book)

[bvining@xxxxxxxxxxxx]

I happened to glance at this note and, as I did not read many of the
other notes related to this subject, hope this reply is not redundant
to other replies.  That said:

Your approach of calling the NLS APIs to do the conversion provides for
more flexibility and reliability in that you can always ask for a
conversion to the job default CCSID; where as database will only provide
the conversion if the job CCSID is not 65535.  As there are a lot of
systems that use 65535 as the default, using the job default CCSID (which
is never 65535) provides an additional safety valve for making sure the
intended character is in fact used/displayed.

Either approach though is superior to just coding a variant literal in
the program source.

For your specific question: if the file is tagged 37, the program is
tagged 37, and the job CCSID is 1025 (or any non-65535 value), then
data management will convert the file data from 37 to 1025 on input and
from 1025 to 37 on output.  If the job CCSID is 65535, the file data will
not be converted.  This lack of conversion can then cause problems if
the rest of the job data is in 1025 (due to the workstation device using
a Cyrillic/1025 keyboard) and variant characters (such as an
exclamation mark, left bracket, etc.) are being used.

Bruce

>
>You wrote:
>>For CCSID to CCSID portability, you shouldn't code literals in your source
>>unless they are invariant characters (apostrophe is invariant).  Instead,
>>you should put your "literals" in a file and read them in at runtime.
>
>Just to make sure I clearly understand this:  If I store variant characters
>in a file tagged with CCSID 37 and compile my program on a system under
>CCSID 37 and then restore both objects on a system with a different CCSID
>the data in the file will be converted into the CCSID associated with the
>job when the program is invoked and reads the file?  So this is making use
>of standard database CCSID support?
>
>What I've done is code the literals as a constant in the program and call
>the NLS APIs to translate them into the CCSID of the job before use.  That
>approach seems fine in the limited testing I've done.  Comments?
>
>I'm sure there's a bit more to it because not all CCSID tables map
>perfectly.  I have ordered the CDRA Level 2 documentation.  Hopefully there
>is a bit more information in them.
>


+---
| 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
+---