Re: QCCSID & 65535

McGovern, Sean wrote:

BPCS recommends that the QCCSID setting is set to 65535, so this probably explains why you have never come across a BPCS implementation with a different setting. But how many of those BPCS implementations have had corrupt databases precisely because of the 65535 setting ?

Our database is corrupt because of that setting (which is defaulted through to the 5250 jobs). This causes issues with 3rd party data mining tools which leads to development workarounds. The corruption occurs because users have been connecting through to the BPCS package with a iSeries Access for Windows host-code page other than the database CCSID (which is the shipped value 937). Users have been connecting with 285 (UK), 297 (France), 273 (Germany), 280 (Italy) etc.

As you have stated, 65535 instructs the Series i not to perform any translation, so the 285, 297, 273, 280 etc hex values get written directly to the 937 database without translation, thus causing corruption of the variant characters.

If the QCCSID setting had been the same as the database, i.e. 937, translation between the host-code page settings would have occurred automatically (and correctly) by the platform to the database CCSID of 937 and the database would not be corrupted.

Having QCCSID of 937 does not allow for a user connecting with a host-code page that does not belong to the Western European CCSIDs, such as Turkey or Czech Republic, as translation of the variant characters is not possible.. But this setup is better than having QCCSID of 65535, I believe.

I don't understand why, at BPCS LX version, Infor still recommend 65535. QCCSID value of 65535 is for backward compatibility for applications that were written prior to CCSIDs being introduced (pre V3R1).

Sorry if this is a duplicate; tried before I subscribed

Not sure what the QCCSID is relevant to in their claim; for anything really, since that is only the highest level of all possible sources for CCSID value resolution. What do they say about setting each user profile to have language specific settings *including* CCSID? The CCSID of course can be set even for any job. Are the QLANGID or each user\job LANGID at least being set correctly, to establish the /job default CCSID/ if the CCSID resolution down to the job remains 65535?

Perhaps what they really intend, is that some user profile for the product, according to some work management established for that user & job(s) must remain CCSID(*HEX). Perhaps they /assume/ that with QCCSID set to 65535, that means /system profiles/ would be affected similarly to what I allude for their own profile; e.g. if a user & job setup requires CCSID(*HEX), but instead of their own profile, some system profile like QUSER which by default resolves from QCCSID due to CCSID(*SYSVAL)? Perhaps the true intent of their recommendation has no bearing whatsoever on what any individual users can nor should have, in their profiles or jobs.? If so, then even honoring their recommendation of keeping QCCSID=65535, the users can still benefit from proper CCSID translations because their user profiles can be used establish their language specific settings.

Regards, Chuck