Clare,
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).
Sean
________________________________
From: bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx on behalf of Clare Holtham
Sent: Tue 12/05/2009 18:54
To: BPCS ERP System
Subject: Re: [BPCS-L] QCCSID & 65535
Hi Sean,
All the Western European BPCS users I know, in fact all BPCS users I
know, use 65535 which means 'no translation', probably because the
translation function has never worked properly! Unless there's something
new out there....;) And don't forget that the special EBCDIC characters
on the iSeries have to co-exist with ASCII on the PC Client end.
If you've ever tried to get CEA working by fiddling with translation
tables in Turkey or the Czech Republic (where they have extra
diacritics) you wouldn't want to even go there....
cheers,
Clare
McGovern, Sean wrote:
We are planning to install BPCS LX. Infor recommends a QCCSID setting of 65535. This doesn't seem like a very good choice to me and one that I would like to change.
If we keep the database as the shipped value of CCSID 937, and (try) to ensure 5250 job streams use host-code page of 937, wouldn't a QCCSID value of 937 be a better choice than 65535 ? This would ensure that if (when) anyone did connect via a 5250 job stream with a host-code page other than 937, at least the System i platform will attempt to correctly translate the data. 99% of the users we support are Western European users, so translation should be handled correctly be the system.
Sean
--
This is the BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/bpcs-l.
Delivered-To: sean.mcgovern@xxxxxxxxxxxx
midrange.com
