× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Literals (Was: OPNQRY reference book)
  • From: bvining@xxxxxxxxxxxx
  • Date: Fri, 2 Feb 01 09:10:41 CST

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.