Many systems can change the CCSID from 65535 to the CCSID associated with their language ID without experiencing adverse effects. But "many" is definitely not the same as all :)
If the system is configured with all I/O devices using the same language and the applications in use are home grown (or at least developed using the same language environment) then you are most likely safe. It however gets a lot more interesting when either or both of these assertions are not true.
Let's say you have a system in the UK, using UK terminals, running an application developed in the United States. Let us further assume that the application has a control field in one file where values such as $ and # might be used (not necessarily "seen" by an end user, but used to control processing within the application) and that this file is tagged with CCSID 37 (US). When the job (or system) is running with a CCSID of 65535 and the application program read the file, the "$" control value is read as x'5B' and the "#" as x'7B'. The application program compares the control field to a constant within the program (x'5B' and x'7B' respectively) and happily goes on its way.
Now lets change the job (or system) CCSID to 285 (UK). When the application opens the file data managements will detect the difference between the file CCSID (37) and the job CCSID (285) and automatically convert the data from 37 to 285 on Reads and from 285 to 37 on Writes or Updates. This conversion will cause the "$" control value to be read into the application program as x'4A' (the code point for the "$" character in CCSID 285) and the poor application program (compiled using the CCSID 37 constant of x'5B' for the "$" sign) will no longer compare equal. This, in many cases, would be a definite problem :) The "#" however would be OK as it is x'7B' in both CCSIDs.
To further complicate though, if the application reads a "#" and then writes a "$" due to a status change in the record (or just writes a "$" for some new record), data management will see the program constant x'5B' being written to the updated (or new) record, realize that x'5B' in CCSID 285 is the "£" and convert that to the "£" sign in CCSID 37 - x'B1'. This value will work OK on subsequent reads from the application program, but will look like the character "[" to anyone looking at the file using a command such as DSPPFM. And if you now switch the job or system CCSID back to 65535 (due to the bad comparisions for existing records) you will find that now any records written or updated while you were in CCSID 37 are now messed up. You now have a very, very bad situation... I will point out though that this could have been avoided if the application file had had the decency to define the control field as Hex and not Character. Hex fields do not get converted by data
management on IO operations. Most applications however, that I've seen anyway, do not utilize this capability.
Now one might say that the problem here is that we switched from CCSID 65535 to CCSID 285. What we "should" have done was switched from CCSID 65535 to CCSID 37. Work station data management, like data base data management, will also do CCSID converions on your behalf. While the "control" field is now being correctly interpreted under CCSID 37, user data in the file is now being read into the application program under CCSID 37 even though it is really 285. WS data management can detect this difference and again provide automatic conversion on writes to the display file (or UIM panel) from 37 to 285, and on reads from the display from 285 to 37. So the "£" that the user entered (and saw) yesterday, today is displaying as a "$". The users may not like this... :) This conversion can be turned off (and in fact the default is for it to be off), but if you decide in the future to install (or develop) an application that truely is CCSID aware (and utilizes the WS data
management capabilities to support a multi-lingual environment) you will find yourself with difficulties when trying to move into that environment -- as you've been somewhat lying to the system since you changed the CCSID to 37...
You really, really need to understand the application and system configuration environment in order to change the system CCSID from 65535 to a non-65535 value. Though as I mentioned at the start of this note, this can be a no brainer for some environments. If it was simple to change for all systems IBM would have changed the default years ago. But IBM has no way of knowing what all mischief might be happening in that 65535 environment.
Bruce Vining
Bruce Vining Services
Pete Hall <pbhall@xxxxxxxxxxxxx> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've been in exactly that situation at my last two employers. Both
times, I changed the system value to ccsid 37, and I've never had a
problem (from that ;)). Since your language setting implies a ccsid of
37, data in the database is consistent with it, even though it is stored
as binary data. Once you change the system value, new tables take on the
new settings. Old tables are left as is. Of course, YMMV. I'd try the
test system first and let things settle for a few weeks.
Pete Hall
pbhall@xxxxxxxxxxxxx
Glenn Gundermann wrote:
Eric (& others),
I know I've seen a lot of posts about CCSID but I haven't paid much
attention to them. For some reason, this posting stuck out a bit more.
Make sure your QCCSID system value is not 65535, as this setting disables
much of the data conversion that is supposed to occur when exporting data
to the IFS.
As it turns out, I'm on two system (test/development & production) that
are both set with QCCSID to 65535.
If I DSPJOB, I see:
Coded character set identifier . . . . . . . . . : 65535
Default coded character set identifier . . . . . : 37
I'm not sure what these two do.(?)
What, if anything, is not going to work properly?
Everything seems to be working that I know of.
Should I be worried about something or bring this up with anyone?
Is there a strong reason to change the system value?
What, if anything, will stop working if this is changed?
Tks,
Glenn Gundermann
ggundermann@xxxxxx
(647) 272-3295
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla -
http://enigmail.mozdev.org
iD8DBQFHYzVipcZsDl8OX6kRApXrAKC9Z1JVKiz6y+ThXuY2sWd6pAKSRwCgnMqs
YPHKd+dZXqamqMdlS5KjQsQ=
=9ZOn
-----END PGP SIGNATURE-----
midrange.com
