Re: Changing CCSID

On 03 May 2012 10:00, Cyndi Bradberry wrote:

We have JDE World, 7.3 running on a 520 at V6R1. We are trying to
use a PC based SQL tool to extract some records from the F0911 file
but we get the Hex version on the PC. The system CCSID is set to
65535, LangID=ENU.

FWiW the system value can effectively be ignored with respect to the database\SQL. The QCCSID is mostly just an umbrella setting which can be overridden in resolution down through a chain of specifics. To get a user's jobs to inherit a specific CCSID different than the 65535 set in QCCSID, CHGPRF [or CHGUSRPRF] CCSID(37) for a particular user; i.e. change the setting for the user(s) [for which this change is desirable and safe] from CCSID(*SYSVAL) to an explicitly chosen CCSID. But for the database\SQL, even when the 65535 resolves all the way down to the job, there is finally the "Default Job CCSID" which is established from the LANGID [or QLANGID if user has *SYSVAL set for their LANGID], so any creation defaults should already effect the associated CCSID for the language of the system or user.

I have tried to change the PF to CCSID = 037. I have recompiled the
file, using a new source file that has a CCSID = 037. No matter what
I have tried, I can't get this to change.

Sorry, but "tried" and "can't get" leave anyone wanting for details. What was the effect for the attempt to CHGPF CCSID(37)? What is the CCSID and the DDS source for the CRTPF, what was the job and job default CCSID, and what is the DSPFFD that shows the effect?

Any suggestions ? I would eventually like to make this system
wide.....as it is silly to stay with the 65535.

As noted above, the system value likely plays no role, when the user profile is configured with the desired CCSID.

At the very least, is there something I can tell my PC guy to put
into his SQL statement to translate ?

The problem is most likely with the files; i.e. the definition of the fields as CCSID(*HEX). Sometimes that is by design, because the "character" data is really what should be the BINARY data-type but was only ever available in the DDS [keyboard shift definition of data] type H; i.e. what is called the Hex data type.

If the files are [in]correctly defined to effect no translation, then only /tricks/ like connection methods enabling a "force conversion from EBCDIC to ASCCI" feature will help; but obviously by presumably /fixing/ the problem with incorrectly defined fields, they will necessarily also be /breaking/ the desired effect for correctly defined fields. In cases where force-translation options are used, all columns which are decidedly correct as BINARY, should be omitted from any select column lists [or cast to a type that is unaffected or (de)converted as required] to avoid corrupting the intended-as-binary data.

Regards, Chuck