Genyphyr,
Many thanks for your very informative response, it is much appreciated.
I've been meaning to digest your response but I'm currently tied up dealing with auditor reporting requests.
I will get to this when I am able.
Regards,
Sean
-----Original Message-----
From: bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx [mailto:bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx] On Behalf Of Genyphyr Novak
Sent: 19 May 2009 01:11
To: bpcs-l@xxxxxxxxxxxx
Subject: Re: [BPCS-L] ERP LX MLS set up for users ... was BPCS-L Digest,Vol 7,
Hi Sean,
Guess I replied too soon on the last one. :-)
OK this makes much more sense now. Now we come to a long reply ...
I recommend your users should be set up as follows:
* If the user will only type characters which are contained in the code page 937 the MLS setting (regardless of BPCS screen or message NLV translation used) for CCSID should be *AUTO and the user's job stream CCSID will be set to match the ERP LX database.
* The 5250 session needs the correct keyboard set up for their PC or input device, but the Host Code Page should be set to 937. This ensures that the characters are stored correctly in the database and the least 'back and forth' translation of keystrokes is required before the input data is stored in the database, or retrieved to the screen.
* If they are using for example German translations of BPCS messages and screens, the so-called 'non-accented' German NLV version should be installed (these 'non accented' language versions are a real misnomer, but basically this means the translated message files were keyed in using code page 37 while the 'accented' languages are designed for systems set up with one language only such as French and the whole system would be set to 297 and so the 'accented' NLV that is in code page 297 is installed to match. This still causes data translation to occur so that all input in 297 is transformed into 937 for storage ... why slow performance if you don't really need to). What is exactly is contained in code page 937 you might ask? Good
question. This code page uses a character set that supports the
languages of Traditional Chinese (Taiwan), German, English, French,
Spanish, Portuguese, Dutch, Swedish, Finnish, Norwegian, Flemish and
Italian (and a few others) according to IBM.
So, do NOT set up users of these
languages to other so-called 'native CCSIDs' for these languages using
BPCS MLS support, as you will simply complicate your life and set up of
BPCS (and slow performance a bit) for no particular reason since 937
already has the characters they need and matches the database set up.
937 is a multi byte code page made up of the 0037 single byte code
page, and the 835 DBCS code page.
You can see all the characters
available in single byte 0037 by clicking on this link and then
clicking on "CP00037.pdf"
:
http://www-01.ibm.com/software/globalization/cp/cp00037.jsp .
* If the user will need to view or type characters which are NOT contained in the code page 937, they can only do so in MLS enabled parts of BPCS, and thus should be set up in BPCS MLS with a CCSID matching their required input language. They may ONLY type the characters unique to that CCSID into the subset of MLS-enabled applications (this list of enhanced applications and specific panels should be available with the release notes).
* Otherwise, when in other parts of BPCS they must use the invariant character set (mainly A-Z a-z and 0-9 and a few math symbols) when typing. Additionally, depending upon how your company shares data and what other languages/countries/code pages are in use, they may also be able to use other characters found in code page 937 (this is of course assuming you have not changed the default database files code page to another CCSID).
* If your set up is correct, then the data they input into non-MLS enabled parts of BPCS will look OK no matter who retrieves it later because the system will be able to convert it properly to store in the 'normal' BPCS files. If they attempt to type characters NOT found in code page 937 into the normal BPCS files, they will either get an error or garbage characters appearing as green blocks (3F) will be stored in the BPCS database, depending upon how the system reacts.
* Inside MLS enabled applications, they can input any character they are
set up for in their input device, and it will be tagged as data in
their BPCS MLS language setting, stored in Unicode and when it is later
read from their or someone else's session, if possible, it will be
displayed. If the Unicode data stored cannot be represented on the
screen CCSID that the user is using for display purposes, there will be
a BPCS indication that the data cannot be displayed on the device. For
example, characters such as a Thai letter stored properly in Unicode
cannot be displayed in a 5250 device set up for US English.
Note that the decision to allow ONLY invariant characters (a subset of code page 37) as input into your 937 files, versus allowing input of any character found in code page 937 is entirely left to you and your internal corporate policies. An example of an issue in data compatibility would be something as follows. Your company does business in Eastern Europe and has an office in Budapest and another in Warsaw as well as offices in the US, UK and Spain. Some Spanish users type into the 937 files using the enya à character, and in the UK they have typed in some notes using sterling symbol  in normal non-MLS BPCS files. The US users can read these just fine, as can the UK and Spain read each other's data. All these are properly stored in code page 937 and all these users are set to host code page CCSID 937 and all characters can be displayed on their sessions.
However, the users in Poland and Hungary won't be able to read those 2 characters because when the system is translating from database code page 937 to the 'Latin 2 Multilingual' code page of 870 or 1110 used for 5250 display devices in Poland and Hungary (because these users need to type in addresses with letters not found in 937 such as Å and Å etc. which are found only in 870 and 1110 etc.), as these particular characters 'Ã' and 'Â' simply do not exist in their CCSID.
So for all users to be able to read each other's input in normal BPCS files with no issues, ideally users would not use any letters which any other CCSIDs in use in your company cannot represent. The users in Poland and Hungary similarly are restricted to only use the invariant character set for 'normal' non-MLS enabled applications, and can use their specific unique native CCSID letters such as Å and Å etc. in any MLS-enabled Unicode extension file. These characters however remain impossible to retrieve if your 5250 session is not set up for a code page compatible to view these letters.
I hope this helps?
Thanks,
Genyphyr Novak
iSeries technical consultant
+33 662 15 02 02
________________________________
From: "bpcs-l-request@xxxxxxxxxxxx" <bpcs-l-request@xxxxxxxxxxxx>
To: bpcs-l@xxxxxxxxxxxx
Sent: Monday, May 18, 2009 7:00:06 PM
Subject: BPCS-L Digest, Vol 7, Issue 65
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. Re: ERP LX MLS set up for users ... was BPCS-L Digest, Vol 7,
Issue 60 (McGovern, Sean)
2. Re: QCCSID & 65535 (rob@xxxxxxxxx)
----------------------------------------------------------------------
message: 1
date: Mon, 18 May 2009 14:35:50 +0100
from: "McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
subject: Re: [BPCS-L] ERP LX MLS set up for users ... was BPCS-L
Digest, Vol 7, Issue 60
Genyphyr,
The document is 'National Language Versions Installation Guide V8.3.3'
(not the document I refer to below written by yourself).
The section I need clarification with is as follows: -
"User setup to access ERP LX depends on whether you use the MLS
enhancement.
If you do not use the MLS enhancement, ensure that for all languages,
the Host Code Page setting on the user's 5250 emulator session matches
the CCSID of the Infor ERP LX database tables and the SYS820D System
CCSID is set to *AUTO. These settings must match the CCSID settings of
the NLV translations.
If you use the MLS enhancement, set the user's CCSID to match the NLV
message file CCSID that is assigned to the user. However, the user can
only enter data in their unique language CCSID into the MLS extension
files. Users should use the base language for the installation to write
data into other ERP LX files. Users should use the Invariant Character
set to
ensure the characters they write into the database can be stored
properly and will be able to be read by other users on the system."
We will be using the MLS product. Does the above indicate that the users
host-code page should match the CCSID setting in SYS600 when writing to
the MLS files, and that the host-code page should be set to the database
CCSID when writing to the rest of the database ?
Thanks and regards,
Sean
-----Original Message-----
From: bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx] On
Behalf Of McGovern, Sean
Sent: 15 May 2009 21:53
To: BPCS ERP System; bpcs-l@xxxxxxxxxxxx
Subject: Re: [BPCS-L] ERP LX MLS set up for users ... was BPCS-L
Digest,Vol 7, Issue 60
Genyphyr,
When I logged the QCCSID question with Infor, I was supplied with a
document (written by yourself in 2005, I think), which is how my
statement came about. I'll dig out the document on Monday and take
another look.
I'm certainly aware of the invariant character issue. One area where
this cropped up, we have the need to maintain shipping document texts in
the language of the country that the shipping documents are being sent.
Tthese texts are entered into the system by the same users at the same
PCs. Not a good situation. The solution was to store the texts in
Unicode tables, and use iSeries Access for Web rather than iSeries
Access for Windows (which doesn't support Unicode).
Cheers,
Sean
midrange.com
