Re: CCSID Question

Mike,

The only answer to that question is "it all depends". 

Many systems are set such that the *USRPRF CCSID defaults to *SYSVAL so 
user jobs default to running in the CCSID specified for the system value 
QCCSID.  A job CCSID of 65535 indicates that the system is to do no data 
conversions, a job CCSID of 37 indicates that the system should 
automatically perform data conversions in operations such as database 
reads and writes. 

Now lets assume that your system QCCSID is currently 65535 and your system 
QLANGID is FRA for French.  This would mean that by default files 
previously created on your system were CCSID tagged 297 (a French CCSID). 
Now lets assume that you have in the past written data to these files and 
some of the data has an @ sign (x'44') in it.  Everything is working fine 
as you have French display devices which display x'44' as @, etc. and the 
system makes no attempt to convert the @ sign as the job CCSID is 65535.

Now you change QCCSID to 37, user jobs default to this new CCSID of 37, 
but you leave everything else the same. 

When your application program opens a file database will detect that your 
job is 37, that your file is 297, and automatically convert the x'44' 
stored in your file to x'7C' when it provides the data to your application 
on a Read.  This is because in CCSID 37 the @ is x'7C'.  Now your 
application program writes the data to a French display, the display 
receives a x'7C' and since in 297 (the CCSID/CHRID of the French display) 
x'7C' is à that is what gets displayed.  Most users would not care for 
this... This type of problem can be handled by changing other system and 
job values/attributes, but my assumption here is that you ONLY changed 
QCCSID to 37.

Now assume the application program scans the data returned on the Read for 
the @ sign.  The application was written using CCSID 297 tagged source 
files and so is looking for the x'44' (under the covers) when you scan for 
the literal '@'.  Guess what?  It's not found as the @ is now x'7C' in 
your application variable and so the program does whatever processing it 
would do in the absence of the @ rather than the logic associated with 
finding the @.

These are just two of the possible problems one can encounter when 
changing the QCCSID value and the '@' is only one of many characters that 
might be impacted.  If all of your files are CCSID tagged 37 then you will 
PROBABLY be OK.  If your current QLANGID is ENU then the default for files 
created in the past would be 37 and you will PROBABLY be OK.  If you have 
any purchased applications then their databases are most likely tagged 
with whatever CCSID was used on your suppliers system -- which may or may 
not be 37.

What you really need to do is determine what objects on your system are 
currently tagged with a CCSID that is not 37 and not 65535, and then 
determine what will happen if data conversions to 37 start happening 
automatically on your system.  This normally requires an indepth knowledge 
of the application (especially when the application might be doing 
comparisions to characters such as #,@,$,etc).

And for sure I would go back to the supplier of your software and ask why 
they require a CCSID of 37.  This typically indicates that the application 
has hard coded literals in CCSID 37 and didn't want to go through the 
(trivial) effort of either 1) converting their literals from 37 to the 
current job CCSID or 2) under the covers changing the job CCSID to 37 for 
their language dependent processing and then returning the job CCSID to 
the initial value when exiting their languge dependent processing.  They 
probably are not aware of the impact their recommendations might have on 
systems outside of the United States.

As I indicated earlier, the answer is "it all depends" and as you can see 
one should not change QCCSID without really understanding their system. 
The sytem may appear to run fine for a hour, day, week, or month and then 
you find that year end has this one little file over on the side that used 
@....

Your approach of only changing the CCSID related to the job running this 
software is much safer than changing QCCSID, and using a CHGJOB CCSID(37) 
prior to calling the application and a CHGJOB(65535) after the application 
ends even safer.

Bruce Vining




Mike Wills <koldark@xxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
02/16/2006 10:31 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
CCSID Question






One of the instructions in this setup manual I have is to change th CCSID 
of
the system. Currently it is set at 65535 and they want me to change it to
37. I really don't understand much about the CCSID. What impact would that
have on a system in general? The option (which I am doing so far) is to
change the default CCSID for a user.

--
Mike Wills
koldark@xxxxxxxxx
http://mikewills.name
http://theriverbendpodcast.com

"There are 10 types of people in the world: those who understand binary, 
and
those who don't." -Unknown