Re: DFU with field type G

Simon,

An excellent idea and that change to the display file source should
logically work. But evidently CRTDFUDSPF is doing something "special" under
the covers because a quick test failed. 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. And my goodness,
doesn't DFU generate an interesting set of DDS source? :)

Using a RPG program:
ftossdspf cf e workstn
fucstest if e disk

/free
read ucstest;
exfmt dsprcd;
*inlr = *on;
return;
/end-free

with a database file of:
R RECORD
NUMBER 5P 0
DATA 10G CCSID(1200)

with a display file of:
R DSPRCD
DATA 10G B 5 10CCSID(1200 5)

displays the string 'ABC ' when the file record (and RPG program
variable) contains x'00410042 00430020 00200020 00200020 00200020'. In this
test case I was using PC5250. As PC5250 does not support Unicode work
station data management is converting the Unicode data to the CHRID defined
for the device.

Bruce
On Mon, Feb 22, 2010 at 3:46 PM, Simon Coulter <shc@xxxxxxxxxxxxxxxxx>wrote:

On 23/02/2010, at 12:13 AM, Bruce Vining wrote:

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.

So one could therefore save the DFU-generated display file DDS, edit
it, and add the appropriate CCSID keyword to resolve that issue. Yes?

A 9 2'GRAPHIC:'
A 24 17 DSPATR(HI)
A N17 DSPATR(ND)
A B100000005 5G B 9 13CHGINPDFT CCSID(13488)
A CHECK(FE)
A 03 DSPATR(RI)
A N17 DSPATR(ND)
A N19 DSPATR(PR)
A 19 DSPATR(UL)
A 31 19 DSPATR(PC)
A CHANGE(31)
A 09 DUP(02)
A 23 17 DSPATR(HI)

However that won't help if the device cannot handle Unicode data and
as far as I know PC5250 still indicates Unicode is not supported in
which case a different emulator will be needed. Yes?

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.