Hello Bruce,
Just tried changing the Global fields to Alphanumeric in the logical file
& it works fine. Maybe I got it wrong the first time !!
A R USRDTLR PFILE(USRDTLP)
A USERID A10
A USERNM A22
Thanks for the suggestion.
BR
Ewart
----- Forwarded by Ewart Desouza/8200/SANDVIK on 02/23/2010 11:52 AM -----
Ewart Desouza
From:
Ewart Desouza/8200/SANDVIK
Sandvik Asia Ltd
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Information Systems
Cc:
0091 20 27104620
Date:
02/23/2010 09:38 AM
Subject:
Re: DFU with field type G
Hello Bruce,
Thanks for the detailed explanation. Fortunately we use only English i.e.
ccsid 37.
Here is the field definition in SQL.
USERID GRAPHIC(10) CCSID 13488 DEFAULT NULL ,
Here is an extract from my job description:
Coded character set identifier . . . . . . . . . : 37
Default coded character set identifier . . . . . : 37
Character identifier control . . . . . . . . . . : *DEVD
Don't know if it is right or wrong but here is the logical that I created
from what I could gather from your mail:
A R USRDTLR PFILE(USRDTLP)
A USERID CCSID(13488 37)
A USERNM CCSID(13488 37)
I tried creating a DFU over this file but it still does not work. What is
surprising is that Query/400 displays & works upon the data nicely (as
pasted below) which indicated that the data is accessible.
Line ....+....1....+....2....+....3....+
VNEDUS VNEDTN
000001 IS4057 Ewart de Souza
000002 IT6048 Clement Smith
Thanks & best regards
Ewart
Bruce Vining
From:
Bruce Vining <bvining@xxxxxxxxxxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Cc:
Date:
02/22/2010 06:52 PM
Subject:
Re: DFU with field type G
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.
midrange.com
