Chuck, you need to write a book on this! :-) I know of some of the
different spots within the Infocenter that have info on CCSID's, but they
didn't seem to have anywhere near the clarity you are offering here.
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Saturday, December 15, 2007 9:40 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: My CCSID is set to 65535 (was Print and email a file in the
IFS)
Pretend for a moment that there is no system-wide definition of
CCSID. The goal is to ensure that each user profile is specifically
associated with the language [and regional characteristics] representing
what the human actually types and reads. It is only because the default
settings defer to *SYSVAL, that the system value QCCSID is so often
mentioned as a way to establish the CCSID [for the users and thus the
jobs of the users] for the system. However any specific user may more
appropriately have their own specific language settings, different than
the system value settings.
The LANGuage IDentifier and Coded Character Set IDentifier should be
set to appropriately identify the operating defaults for the user. The
parameters are the first two of the following list, which includes other
language and regional settings: LANGID CCSID CNTRYID CHRIDCTL SETJOBATR
LOCALE SRTSEQ These parameters are available on CRTUSRPRF & CHGUSRPRF,
each with default of *SYSVAL for create, and thus each parameter has a
corresponding system value -- with naming Qparameter
So instead of being concerned with "CHGSYSVAL QCCSID A_Value", change
can be limited by changing each user by requesting to CHGUSRPRF UsrPrf()
LANGID(as_appropriate) CCSID(as_appropriate). In an environment where
the user profile sees in WRKJOB OPTION(*DFNA) the CCSID and Default
CCSID as noted below, 65535 and 37 respectively, then the language
environment resolution by the system [in response to a defaulted
CCSID(*HEX) environment], inferred that the user (job) should run with a
US English CCSID 37. Typically the inference is from the QLANGID. I
believe the QLANGID is established according to the installed Primary
Language; see GO LICPGM, option 20.
If a user had established LANGID(ESP) CCSID(*SYSVAL) to identify
themselves with Spanish language while the system value was 65535, then
jobs for that user would have been established with a /Default/ CCSID of
284. If the system value were later changed to 37, then that user would
experience a change to their default job CCSID for new jobs, to the new
value of 37.
Given the language settings are setup appropriately, more things will
/start working/ than stop working. However what is corrected, could
easily have some functions appear to be broken. That is, a correction
could be perceived as a defect, because that which is inconsistent is
often more problematic than being consistently incorrect. However the
sooner the appropriate language settings are established across the
system, the sooner the situations of /consistently incorrect/ can be
addressed. And such a _proactive_ approach to establish the appropriate
CCSID can prevent having to deal in a _reactive_ approach later, to data
issues that resulted from not having already done so.
However the bigger issue is [not the user & job CCSID, but] that the
data being typed and displayed is properly reflected across multiple
language environments. Whereas many systems will not have any such
concern for differences in the spoken & written languages amongst a
homogeneous group of individual users, the concern still remains for the
/encoded characters/ stored as data on a computer. The encoding is
defined by the CCSID. The most pervasive issue is for transfer of data
between an ASCII system and the EBCDIC i5/OS; i.e. different encoding,
and a difference more obvious to most. If a file for example is defined
[tagged] with the CCSID(*HEX) [AKA CCSID(65535)] that indicates to the
system that /no character conversion/ should occur. The data after a
transfer between disparate system encoding defaults, could be generally
unreadable. Some functions like ODBC had implemented a special [IMO
horrible] feature to /translate irrespective of tagging/ to ask the code
to _assume_ that the CCSID of the data reflects the job [default] CCSID.
As more lies are told to the system code, and more transfers of data
with such _assumptions_ based on such lies occur, the more likely the
data will have lost its fidelity. Or one day when fidelity is required,
for the lack of proper tagging with a CCSID, the true meaning of the
data is lost transferring outside of the original language-specific
encoding. The most typical example is when a UK pound sign is presented
where the US dollar sign was intended to be manifest to the viewer of
the data. So not only get the system\user\job CCSID established, but
get any files and other data properly tagged.
Regards, Chuck
midrange.com
