Re: Another code page - character set issue ?

There are four important CCSID’s in a job, the current job CCSID and the
standard/default CCSID (use DSPJOB opt 3), the DB CCSID (use DSPFFD) and
then the programs source file CCSID (use DSPFD).



CCSID from DB into a program.


If the current CCSID I 65535 no conversions are done when SBCS EBCDIC is
read into the program, you need to know the CCSID in the file, this can be
displayed with DSPFFD.


If the current CCSID is an EBCDIC CCSID the system will try to convert data
from the DB to the current CSSID.



CCSID in constants in the program.


The CCSID will be in the source files CCSID, is the CCSID 37 char $ = x’5B’
is the CCSID 277 (Danish) char $ = x’67’ – remember that any instruction
doesn’t use “characters” but the underlying hex value.


Current CCSID 65535 may therefore cause unpredictable result since a char $
from a CCSID 37 DB doesn’t have the same hex value as the constant $ in a
CCSID 277 source file.



CCSID in STMF.


Steam files are created with the CCSID at open()/open64(), it is important
that the steam file doesn’t exist before open.

If the current job CCSID is 65535 and the open is 1208 from 0 (current job
ccsid), the standard/default CCSID is used for conversion like fd =
ifsOpen(file:flags:permits:1208:0); If the DB is CCSID 37 and the
standard/default CCSID is 277 the x’5B’ that equals a $ char in 37 will be
translated as char Å that is the char for x’5B’ in 277 and end up as
x’C385’ instead of x’24’ in 1208.


If the current job CCSID is 65535 and you know your data’s EBCDIC CCSID
just open()/open64() the steam file with 1208 from 37 or whatever CCSID
like fd = ifsOpen(file:flags:permits:1208:37);


If the Current job CCSID is an EBCDIC CCSID and open is 1208 from 0
(current job ccsid) this EBCDIC CCSID is used for conversion.



Best scenarios.

The best scenario is that the current Job CCSID is equal to both the DB
CCSID and the source file CCSID, the next best is that the current Job
CCSID is equal to the source file CCSID


On Wed, Jan 22, 2014 at 4:54 PM, TheBorg <sjl_abc@xxxxxxxxxxx> wrote:

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

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.