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