RE: iSeries Access for Windows and unicode

Many thanks to Chuck and Bruce.

Chuck, as you have pointed out, it seems my issue with iSeries Access
for Web were due to using STRSQL to view the data.

Now that I have followed the example from Bruce, the data is displayed
correctly within iSeries Access for Web.

My faith is restored with the IBM i platform !

Again, many thanks,
Sean


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: 26 February 2009 16:31
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: iSeries Access for Windows and unicode

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_th
ese_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 ?

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.