Hi Simon,
As mentioned in my other mail I've decided to go in for Bruce's suggestion
of creating a logical file over the physical file with replacing the
Graphic fields with alphanumeric fields (I was not aware that this was
possible) & it works fine.
Thanks for the research anyway, I'll keep this in mind for any future
requirements.
BR
Ewart
Simon Coulter
From:
Simon Coulter <shc@xxxxxxxxxxxxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Cc:
Date:
02/23/2010 02:14 PM
Subject:
Re: DFU with field type G
On 23/02/2010, at 10:42 AM, Bruce Vining wrote:
I have no idea what CRTDFUDSPF is
doing (actually I didn't even know that command existed until I got
compile
errors with a run of the mill CRTDSPF lol), but it's existence
certainly
suggests some special treatment of the display file source.
Looks to me like it just does a normal CRTDSPF but with GENLVL(30).
Might be something else going on too.
A quick test with the following PF:
R FORMAT
UCS_2 10G CCSID(13488)
UTF_16 10G CCSID(1200 )
UTF_8 10A CCSID(1208 )
using UPDDTA seemed to work as expected.
Note: The following examples contain Japanese Hiragana characters--
whether you can see them successfully will depend on your e-mail
program (or whatever other viewer you use).
Note: I did the following tests without modifying the generated DDS to
add a CCSID keyword.
Using a DBCS version of PC5250 allowed me to enter Hiragana data
successfully and view it OK. (Ignore the spiky characters on line two--
they are actually lower-case Latin-1 (Format) interpreted as Katakana
which makes them nonsense.)
WORK WITH DATA IN A FILE
Fナネテアホ . . . . : FORMAT
*RECNBR: 2
UCS_2: しつのいぬて?す
UTF_16: たまこ?ち
UTF_8: UTF-8 DATA
Viewing that record from an SBCS version of PC5250 gave:
WORK WITH DATA IN A FILE
Format . . . . : FORMAT
*RECNBR: 2
UCS_2: a?y?a?la??a?ba?qa?o?a??
UTF_16: a?ja?ua?Da?k
UTF_8: UTF-8 DATA
Which is sort of expected since PC5250 can't handle the Unicode and
this data cannot be represented in an SBCS character set.
Using an SBCS version of PC5250 to enter data was more interesting. I
could not enter multi-byte data (e.g., Hiragana or Kanji) because
English versions of [ Windows | PC5250 ] don't [provide | support ] an
Input Method Editor (or not that I can find) so I just entered Latin-1
text.
WORK WITH DATA IN A FILE
Format . . . . : FORMAT
*RECNBR: 1
UCS_2: UCS-2 DATA
UTF_16: UTF-16 DATA
UTF_8: utf-8 data
Even though the DFU Audit Report indicated all three fields were
successfully updated the UCS_2 and UTF_16 fields ended up with blanks.
No error message in the job log. Viewing that record from SBCS PC5250
gave:
WORK WITH DATA IN A FILE
Format . . . . : FORMAT
*RECNBR: 1
UCS_2:
UTF_16:
UTF_8: utf-8 data
Note the first two fields are empty. DSPPFM showed these fields filled
with spaces (x'40'). Viewing from DBCS PC5250 gave:
WORK WITH DATA IN A FILE
Fナネテアホ . . . . : FORMAT
*RECNBR: 1
UCS_2:
UTF_16:
UTF_8: マホカ-8 エアホア
Again, the spiky data in the UTF-8 field is lower-case Latin-1 being
misinterpreted as Katakana so it looks wrong but is actually OK (as
long as you don't try to change it).
Then I modified the generated DDS and added appropriate CCSID keywords
to the UCS-2 and UTF-16 Graphic fields. Couldn't specify 1208 for a
display file CCSID value on VRM530. However, that just seemed to make
a mess of everything. DFU Entry showed:
UNICODE
Format . . . . : FORMAT
UCS_2: _________ . . . . . . . . . . .
UTF_16: _________ . . . . . . . . . . .
UTF_8: __________
With the underscored part of the first two fields shown in reverse
image and the dots in highlight. Entering data also proved
problematic--didn't seem to make it to the database. Trying to display
original record 1 (see above) caused DFU0810 - "The retrieved record
contains invalid data." in both SBCS and DBCS sessions. Displaying
original record 2 (see above) showed the correct data for the UTF-8
field but just empty reverse-imaged fields for the other two.
Looks like DFU can handle Unicode data but only from a DBCS version of
PC5250 or iSeries Access for the Web. So, without a DBCS PC5250 or
iSeries Access for the Web, it seems a user-written program is the way
to go.
And my goodness, doesn't DFU generate an interesting set of DDS
source? :)
That's one way of describing it!
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 / \
--------------------------------------------------------------------
midrange.com
