Re: CCSID (I think) problem

Thanks, Simon

I hope not to press this too much longer, but I want to understand this. In
the original situation the QCCSID values were both 65535, which means there
is no conversion--all bytes keep their original hex value, right? But the
QCHRID values are different on the 2 machines. Hence, workstation and
printer support will display each code point (hex character) differently.

It appears we may not have the full picture, either. I just looked up help
on QCCSID and QCHRID. The latter is a pair of values, and we were given
only one--the code page, I believe. But there's also a character set, which
may not have included the 'cent' sign at all, I believe.

It says that the QCCSID '[identifies] a specific set of encoding scheme
identifiers, character set identifiers, code page identifiers, and
additional coding-related required information'. And the code page part of
QCHRID will be changed to match a change in QCHRID.

Now, if the QCCSID of each machine were set to appropriate values for the
primary language, then the conversion would have happened automatically, right?

These values can be set on DSPFs and PRTFs--would the original respondent
be able simply to CHGPRTF and get what he wanted?

Regards

Vern

At 12:46 PM 8/19/02 +0000, you wrote:

>Hello Vernon,
>
>You wrote:
> >Not translated, yes. But the codepage tells how a code point will be
> >handled at a display of print, right?  So QCHRID seems to explain why
> >the same codepoint is displayed differently on the 2 systems.
>
>It explains why a given code-point represents a different character but
>if the file CCSIDs were set correctly you should see the same character
>on both machines which is the whole point of CCSID support.  (There are
>some instances where that will not happen but in most cases it behaves as
>expected.)
>
> >Aren't we saying the same thing?
>
>Not at all.  You said the CHRID is the problem.  It's not.  The problem
>is the 65535 CCSID.  The different CHRID is more of a symptom than the
>problem.
-snip-