We have JDE files which are mostly coded as CCSID(65535), and in the
different environments the [PC5250] emulator configuration determines the
true CCSID of the data going into the files.
To handle this, in my custom CVTUTF command I have a parm from 'from CCSID'
in the event that the file fields are coded as CCSID(65535). In the CPP, I
first use iconv to convert the data from the specified CCSID to CCSID(1200),
then use QlgTransformUCSData to convert it to any other UTF representation.
;-)
-sjl
wrote in message
news:mailman.735.1390390040.25182.rpg400-l@xxxxxxxxxxxx...
Dirk,
Basically, you're in trouble ....
To convert data to a different encoding, e.g. UTF-8, the system must know
the encoding of the original data. In other words, it must know what each
byte value means, what character it represents, in order to translate it
to the correct byte value in the target encoding. Your system has QCCSID
65535 (hex FF), which basically means 'no conversion'; every job that is
started starts with CCSID 65535, but also gets a 'default CCSID' (<
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fnls%2Frbagsjobdefaultccsid.htm
), that is used when a CCSID is necessary and the job CCSID is 65535.
When writing text data to a stream file from a job with CCSID 65535, that
default CCSID is used. With DSPJOB you can see CCSID and default CCSID.
You say that in 5250 the file looks ok, but, assuming you use an emulator,
the emulator has to convert from EBCDIC to something your PC can display.
In the communications settings of the emulator you can specify the 'host
code page'; that should be the same as the job CCSID (in your case I
assume it should correspond to the default CCSID).
Steps to take:
- Make sure that your input file has a valid CCSID (not 65535)
- Make sure that your interactive job has a valid CCSID (not 65535)
- Make sure that your emulator's host code page matches the job CCSID
Now, when you display the contents of the input file, the data is
converted from the file CCSID to the job CCSID (if necessary) and the
emulator will convert the 5250 stream to the correct characters. Then you
will be able to tell if the contents of the file look ok. If it looks
wrong:
- Determine the right CCSID for your input file (that might be the hardest
part)
- Create a new file with the right CCSID
- Copy data with FMTOPT(*NOCHK)
- Display contents of new file
Here <
ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00037.pdf
you can see the encoding for code page 37 (default; US English). Change
CP00037 to CP00500 for international or CP01148 for international with
Euro sign.
Joep Beckeringh
Dirk.Marien@xxxxxxxxxxxxxxxxx
Re: Another code page - character set issue ?
Hi,
as answer to Joep's and Wim's questions :
* Word cannot open (because file contains invalid characters)
* in 5250, file looks ok (accents are shown like it should)
* Qccsid (and job ccsid = 65535)
* Qchrid = 697 500
Hope you can help me looking at this additional info ... .
Kr,
Dirk.
Dirk Mari?n
Toyota Motor Europe
60 Avenue du Bourget,
1140 Brussels, Belgium
Ph: +32 (0) 2 745 2581
www.toyota-europe.com
midrange.com
