An application example would be helpful...
Oracle's JD Edwards World software is often used in multinational company globalized environments where multiple languages are being used.
In such environments, the JDE files are typically defined with CCSID(65535), which is NOT a CCSID, rather it means 'No Translation occurs." Some of the JDE fields are defined as Open, to allow for storing double-byte data.
For example, at my former multinational vision care client there were LPAR's setup for different global areas:
* North America,
* LACAR (Latin America, Caribbean, and South America)
* Europe and Middle East
* Asia
These different systems have multiple JDE environments, one for each country. The system CCSID is 65535. Each country environment has different language requirements, thus the CCSID for the users' sessions is configured using "Host Code Page" setting in the 5250 emulator session. based on the country's language.
In the U.S. Environment we used Host Code Page = '037 United States'.
For the European LPAR most of the environments used Host Code Page = '500 Multilingual', but there were some exceptions.
On the Asian LPAR there were enviroments for China, Japan, and other Asian countries, some double-byte and others single-byte. Japan enviroment used Host Code Page = '930 Katakana' or '930 Katakana Extended'. Taiwan used '937 Taiwan (Traditional Chinese Extended)'.
Problems often arose when someone had their 5250 session host code page set up incorrectly for a given environment - this would cause invalid data to be placed into the files, since the 5250 session determines the representation of the data coming from the screen.
Especially problematic was that users would copy and paste data from Word or Excel documents into double-byte fields, sometimes overflowing causing the shift-in and shift-out characters to be missing, thus invaldating the double-byte value in the field. We had to write a program which scanned fields and forced the missing
I built an ETL system for extracting the data from various environments which required the data to be converted into a common representation, so in some cases in the ETL system we would convert the data from the different CCSID's into UTF-8 (1208) or UTF-16 (1200) and forward the UTF files via FTP to the remote systems.
Depending on the file destination, we also used Sterling Integrator, which has the capability to convert the data as it is being copied to remote systems and which has its own peculiarities....
Regards,
Steve Landess
(512) 289-0387
________________________________
Charles wrote:
It was the default for all AS/400's originally...
If you followed the system install guide, one of the first steps
was to set QCCSID properly.
Now IBM ships QCCSID set according to the primary language installed.
But for those who have migrated through the ages...
Brad Stone wrote:
In another thread on the RPG list the job CCSID of 65535 came up.
Niels called it the "no translation" CCSID.
It made me think of a question I've been wondering about for a while.
Why is this CCSID used?
I've never seen it do anything but cause translation
errors when working with stream files or sockets.
Should this CCSID be treated differently than others
when working with translations?
Or would it make sense to have the user set their job's
CCSID to something more "meaningful"?
I see it used more and more...
What is the purpose of this, and why does it
seem to almost be a default on some systems
(mostly non US from what I see).
midrange.com
