Re: BPCS-L Digest, Vol 7, Issue 58 -- BPCS-L

Thanks for the info Debasish,

Sounds like I may have a reason to learn Java, not sure if that is a
good thing. I'm glad AS/SET is going, but not so glad that the AS/SET
generated source is still in use ! But why are you debugging - surely
there are no bugs anymore ?? ;-)

The setup at GSK seems appropriate, QCCSID should be set to whatever is
relevant for the LPAR. What do GSK use for the Western European LPAR,
937 ?

Reading through the Infor NLV documentation again, I see that if the MLS
product is being used, the job CCSID will be changed at the startup of
ERP LX (to match SYS600 settings), thus making the QCCSID irrelevant for
the BPCS users. But it seems that the host-code page should be set
differently depending on whether the user is performing database events
against the MLS files or against the rest of the BPCS files. Not sure
how that is going to be managed ! I guess I just need to get ERP LX
installed and start testing...

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 debasish chakraborty
Sent: 14 May 2009 06:01
To: BPCS GROUP
Subject: Re: [BPCS-L] BPCS-L Digest, Vol 7, Issue 58

Hi Sean,

If you are implementing LX then the technology to learn is how to
Weblicate customised menus/programs. LX does not have client server so
it is either web or full grenn screen and I mean full including cea, OLM
etc etc, websphere, webtop etc. The web uses IBM websphere and java and
sort of screen scraping and create wrappers around the display programs
for web. Oh I forgot no AS/SET but you have to debug AS/SET code in
RPGLE. Have fun.

As far as the ccsid is concerned I think keeping a default at the
highest level is recommended probably for backward compatibility. I am
working for GSK and probably they have the second largest user license
using BPCS (Bent Nielsen is there I dont know if you remember him). They
have different CCSIDS for different servers and they not only have
western european but chinese , arabic , Japanese etc. Like for there
arabic language based servers the QCCSID is 420. So I think keeping the
CCSID right is the ideal way to go. IBM if I am not wrong does not
recommend 65535 if you are using multi language multi environment.

Thanks & Regards
Debasish
The past, it's a story. The future, it's a mystery. The present, it is a
gift.
IBM System i - For when you can't afford to be out of business.

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)

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)

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

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

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)

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

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)

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

Our database is corrupt because of that setting (which is defaulted

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
*************************************

_________________________________________________________________
Beyond Hotmail - see what else you can do with Windows Live.
http://clk.atdmt.com/UKM/go/134665375/direct/01/