× 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 have a vague recollection that displaying Unicode data is a function
of the device capabilities. I think PC5250 can't handle Unicode fields
and you need to use iSeries Access for the Web (or a third-party
facility that handles Unicode such as aXes).

How Unicode data is displayed is both a function of the device capabilities
and the definition of the display file.

If the device indicates that it supports Unicode and the display file
defines the field as Unicode (data type G with a Unicode CCSID) then
workstation support will pass the data to/from the device as Unicode.

If the device indicates that it does not support Unicode and the display
file defines the field as Unicode (data type G with a Unicode CCSID) then
workstation support will convert the data to the CHRID associated with the
device for output and from the CHRID to Unicode on input.

If the display file does not define the field as Unicode, and Unicode
encoded data is passed to/from the device, then "nothing good" is going to
come of it.

DFU does not (at least on V5R4 and I doubt it's been changed with later
releases) retain the CCSID keyword definition of the data file when
generating the display file, so it's passing Unicode data without defining
it as Unicode to workstation support. This falls into the "nothing good"
bucket.

Depending on the underlying data DFU might still be useable (with
restrictions). If the data found in any given record is tied to a particular
language then you can create a logical file over the original file, mapping
the Unicode (type G with CCSID specified) field to a character field
(assuming SBCS). Creating a DFU application using the logical file, database
will then cause DB2 to map the Unicode data to/from the EBCDIC CCSID of the
job running the DFU program (note that I say "running" the DFU program --
the EBCDIC CCSID of the logical file is not material at DFU run time so long
as the "running" job CCSID is not 65535). So if you know a given record (or
records) is simply Unicode encoded Latin-1 data, then use that record with
DFU in a job with a Latin-1 CCSID such as 37. If the given record is
Cyrillic, access that record (with the same DFU program and logical file)
but now in a job with a CCSID such as 1025. The downside is you need to know
the language characteristic of the record so that you can set the correct
job CCSID, prior to reading the record, so that DB2 Unicode/EBCDIC mapping
through the logical file is meaningful. If the underlying record contains
characters from more than one language (Cyrillic, Arabic, and Thai for
instance), then you're out of luck. You need a Unicode capable device and a
non-DFU based solution using a language such as RPG, COBOL, or C.

Bruce Vining (very familiar with Unicode support on the i)
www.brucevining.com



On Mon, Feb 22, 2010 at 12:32 AM, Simon Coulter <shc@xxxxxxxxxxxxxxxxx>wrote:


On 22/02/2010, at 5:09 PM, ewart.desouza@xxxxxxxxxxx wrote:

You make it sound very simple - but I still don't get it.

It was simple.


This is the definition of the field.
USERNM GRAPHIC(10) CCSID 13488 DEFAULT NULL ,

OK, my suspicion was correct. You're using it to hold Unicode data. My
test used a DBCS Graphic field (i.e., no CCSID value specified--one is
derived from the job).

Perhaps that makes a difference. I'll try and test later this evening.

Not sure what you mean by DBCS version. Is there any specific option
to
install this ? We have the V5R4M0 version & we are allowed to change
the
'Host code-page'.

As far as I know you need to order a Japanese or Chinese version of
PC5250 (or Client Access). I mostly use the Japanese version when I'm
playing with DBCS. There are behavioural differences between the SBCS
and DBCS versions (also data stream defects present in one but not the
other--quite interesting really).

There are not messages in the job log. I guess DFU does not handle
this
data.


I have a vague recollection that displaying Unicode data is a function
of the device capabilities. I think PC5250 can't handle Unicode fields
and you need to use iSeries Access for the Web (or a third-party
facility that handles Unicode such as aXes).


Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





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.