× 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.



I am at a loss how this has anything to do with RPG, but...

STRSQL is a server based feature which /understands/ all specified data to be in the CCSID of the job from which STRSQL was invoked, and those are all EBCDIC CCSIDs. I infer the specified host code page is used to provide the converted-to EBCDIC data to the host application from the client. If so, then an insert of a literal string of data in UNICODE, having characters that are incapable of being converted into the specified host code page, would be /lost in translation/. That still leaves the need to match the data being entered [i.e. the data converted from ASCII to EBCDIC] with the CCSID of the job; thus further errors could occur if the job CCSID was inconsistent with the specified host code page.

The only way to enter literal strings [not hex notation] of UNICODE data directly into the table is to use a script interface which supports more than EBCDIC, a program interface, or an ASCII client interface to the database [rather than a host based interface] from which the UNICODE data entry is possible [its interface to the DB2 for i likely being JDBC, ODBC, DRDA, or ??]; e.g. the Run SQL iNav window.

Regards, Chuck

McGovern, Sean wrote:
That's interesting.

I did think that iSeries Access for Web would be the solution. I
tested this last week and had the same problems as each iSeries
Access for Web session still has to be defined with a code page (the
same list as within iSeries Access for Windows). If I configured a
session as code page 285 (UK) and within that session used STRSQL and
an INSERT statement to insert Hungarian text into a unicode table, I
could initially see the correct Hungarian text within the INSERT
statement but the data did not get written correctly to the database
file as it was going through the 285 layer and losing Hungarian
specific characters. Using the same INSERT statement from within an
SQL script within iSeries Navigator correctly inserted the data into
the table.

I will read your article and come back with questions.

Bruce Vining wrote:

There are two products that I am aware of that take advantage of
the 5250 datastream support for Unicode. They are iSeries Access
For Web and HATS.

My COMMON presentation, What's With These ASCII, EBCDIC, Unicode
CCSIDs, at
http://www.brucevining.com/Presentations/PPT_Presentations/Whats_with_these_ASCII_EBCDIC_Unicode_CCSIDs.pdf
uses iSeries Access for Web when concurrently showing Russian,
Chinese, German, and English on the 5250 *DSPF. The same program
was used for testing and demonstration of HATS by the HATS support
area :)

Other products may also support the 5250 based Unicode data stream.
I'm simply not aware of them.

Sean wrote:

Is it possible to setup 1 iSeries Access for Windows session that
is capable of viewing/maintaining ALL possible data held in a
unicode defined database ? Or is a separate session required
(with appropriate configuration) for each language ?




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.