Re: CCSID (I think) problem

Hello Vernon,

I wrote a really long response explaining some of this stuff and then I
started to think a bit more about the original problem.  Here is the
original question:

>>I have an AS/400 located in Ontario (Canada english). on this system,
>>we generate a file to be transfered to a bank. The files contains the
>>caracter "[" among others. I use CA experss to download the file on a
PC
>>in Quebec (Canada french). After the transfer, the caracter "[" is
>>replaced by "¢"!!!

{{{{ Oh, look at that -- a real 'cent' character }}}}}

>>When I do the same transfer from other AS/400 in Quebec, all is fine.
>>
>>On the Ontario machine here are the related sysval (I think):
>>QCCSID: 65535
>>QCHRID: 697-37
>>
>>On the quebec machine, those values are:
>>QCCSID: 65535
>>QCHRID: 697-500

However, I initially read the question as a problem between two AS/400s.
In fact it is a problem between an AS/400 and a PC so we do need
additional information.

What Denis neglected to provide is:

        a) The CCSID of the file/field containing the 'bad' character
        b) The CCSID/Codepage of the PC receiving the file
        c) The LANGID value on both hosts
        d) The default CCSID for the host file transfer job
        e) Exactly what happens to the data during the transfer.

We can deduce some things:

QCHRID tells us that both systems are using the same Character Set (i.e.,
697) but they have different code pages therefore a given hex code will
likely display differently on each system.  Some definitions are in
order:

A code is the global identifier for a particular character.  A code point
is the unique bit pattern assigned to a code.  Code points are assigned
to characters in a code page.  The code page (CP) describes which
character is represented by which code point.  The character set (CS)
describes which specific characters are available.

Codepage 37 is for USA, Canada, Netherlands, Portugal, Brazil, Australia,
and New Zealand.

Codepage 500 is International Latin-1 used in Belgium, Canada, and
Switzerland.

Since the file is being downloaded to a PC we can guess that it is some
dialect of WinDOS and therefore probably using codepage 1252 (Latin-1).

We can presume that since the host system has a CCSID of 65535 then the
file is probably also 65535.

He says the data is generated on the CP37 Ontario AS/400 and downloaded
to the PC in Quebec and this download 'corrupts' the square bracket.

He says if the data is (generated?? sent??) to the Quebec CP500 AS/400 it
downloads correctly.

A left-square-bracket in CP37 is x'BA', in CP500 it is x'4A', and in
CP1252 it is x'5B'.  I do not see how a square bracket can become a
'cent' sign in this instance.

If a left-square-bracket were created on CP37 it should have code point
x'BA'.  If a 'cent' sign were created on CP37 it should have code point
x'4A'.  Interestingly that is the same codepoint as used for the
left-square-bracket in CP500.  So if a file with CCSID 65535 containing a
CP37 'cent' sign were sent to a CP500 AS/400 it would display as a
left-square-bracket.  If that file were then sent to a PC it should
appear on the PC as a left-square-bracket because CA will attempt to
guess the correct conversion tables.

Even allowing for the alternate set of square brackets (x'AD' and x'BD)
doesn't account for the observed behaviour.  There is more going on here
than is immediately apparent and we need more information to explain the
behaviour.

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HT
 E-Mail  / \
--------------------------------------------------------------------