Chuck,
Re-reading the Infor documentation, I now see that it is more
complicated at the latest release. Job CCSID is controlled, whereas it
hasn't been at previous releases (so defaulted to QCCSID, which was
recommended to be 65535).
I need to get the product installed and tested !
Cheers,
Sean
-----Original Message-----
From: bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx] On
Behalf Of CRPence
Sent: 13 May 2009 16:27
To: bpcs-l@xxxxxxxxxxxx
Subject: Re: [BPCS-L] 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
midrange.com
