|
From: bpcs-l-request@xxxxxxxxxxxx
Subject: BPCS-L Digest, Vol 7, Issue 58
To: bpcs-l@xxxxxxxxxxxx
Date: Wed, 13 May 2009 12:00:07 -0500
Send BPCS-L mailing list submissions to
bpcs-l@xxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/bpcs-l
or, via email, send a message with subject or body 'help' to
bpcs-l-request@xxxxxxxxxxxx
You can reach the person managing the list at
bpcs-l-owner@xxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of BPCS-L digest..."
*** NOTE: When replying to this digest message, PLEASE remove all text unrelated to your reply and change the subject line so it is meaningful.
Today's Topics:
1. QCCSID & 65535 (McGovern, Sean)
2. Re: QCCSID & 65535 (Clare Holtham)
3. Re: QCCSID & 65535 (McGovern, Sean)
4. Re: QCCSID & 65535 (rob@xxxxxxxxx)
5. Re: QCCSID & 65535 (McGovern, Sean)
6. Re: QCCSID & 65535 (CRPence)
----------------------------------------------------------------------
message: 1
date: Tue, 12 May 2009 18:41:19 +0100
from: "McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
subject: [BPCS-L] QCCSID & 65535
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
------------------------------
message: 2
date: Tue, 12 May 2009 18:54:52 +0100
from: Clare Holtham <Clare.Holtham@xxxxxxxxxxxxxx>
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
------------------------------
message: 3
date: Tue, 12 May 2009 21:19:35 +0100
from: "McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
subject: Re: [BPCS-L] QCCSID & 65535
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
------------------------------
message: 4
date: Wed, 13 May 2009 09:48:30 -0400
from: rob@xxxxxxxxx
subject: Re: [BPCS-L] QCCSID & 65535
We're in the states. I changed our system value to 37 quite awhile ago
during the middle of the business day and have never had a reason to
regret it. Makes downloading data much better than 65535. Yes, 65535 is
doable but you keep having to turn on switches to "translate 65535 data".
We're in the process of upgrading from 405CD to ERPLX 833 and have had
Infor consultants on site to assist us to do so.
Running 6.1 of i.
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From:
"McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
To:
<bpcs-l@xxxxxxxxxxxx>
Date:
05/12/2009 01:42 PM
Subject:
[BPCS-L] QCCSID & 65535
Sent by:
bpcs-l-bounces+rob=dekko.com@xxxxxxxxxxxx
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: rob@xxxxxxxxx
------------------------------
message: 5
date: Wed, 13 May 2009 15:15:30 +0100
from: "McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
subject: Re: [BPCS-L] QCCSID & 65535
Thanks Rob.
We are currently going through the process of upgrading from V61, V8 &
V82 to ERPLX 833 and upgrading from V5R4 to 6.1 of i. I believe we are
the largest users of BPCS worldwide (7000 BPCS user licenses).
I'd like to get the setting of QCCSID right but don't think the
recommendation from Infor is correct.
I'd welcome further comments on this subject.
Any 'gotchas' with upgrading to ERPLX 833 ? Any new technologies to
learn ?
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 rob@xxxxxxxxx
Sent: 13 May 2009 14:49
To: BPCS ERP System
Subject: Re: [BPCS-L] QCCSID & 65535
We're in the states. I changed our system value to 37 quite awhile ago
during the middle of the business day and have never had a reason to
regret it. Makes downloading data much better than 65535. Yes, 65535
is
doable but you keep having to turn on switches to "translate 65535
data".
We're in the process of upgrading from 405CD to ERPLX 833 and have had
Infor consultants on site to assist us to do so.
Running 6.1 of i.
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From:
"McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
To:
<bpcs-l@xxxxxxxxxxxx>
Date:
05/12/2009 01:42 PM
Subject:
[BPCS-L] QCCSID & 65535
Sent by:
bpcs-l-bounces+rob=dekko.com@xxxxxxxxxxxx
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: rob@xxxxxxxxx
--
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
------------------------------
message: 6
date: Wed, 13 May 2009 10:27:25 -0500
from: CRPence <CRPbottle@xxxxxxxxx>
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
------------------------------
--
This is the BPCS ERP System (BPCS-L) digest 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.
End of BPCS-L Digest, Vol 7, Issue 58
*************************************
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
