This content has been marked as final. Show 2 replies
The iSeries has supported Unicode (and DBCS) for a long time. Unicode is broader than DBCS in that it supports ALL languages in a single code page dynamically using from one to four bytes for character encoding. Unicode came after IBM dropped support for RPG-3.
The JD Edwards World database does not support any language CCSID's - all fields are tagged 65535 (no language/no conversion). To support languages, IBM segregates the data and builds language libraries. All JD Edwards World languages are in the same control files (thus CCSID 65535-no conversion). Years ago there were some tools written for NLS (National Language Support) to help multi-national companies convert the database to specific language CCSID's, and convert the data within. Some of the conversion was manual as not all data could be programmatically determined.
In Single Byte (SBCS), the "description" character fields are tagged to CCSID 37 (US English). For Double Byte, the "description" character fields are changed to be "Open" fields and CCSID 65535. Open fields are not "double byte" fields as the SBCS and DBCS database files have the same record length. Open fields are "mixed" data types, meaning they can contain both SBCS and DBCS sound byte characters. DBCS characters must be encased between Shift-Out/Shift-In characters. For example, Japanese companies (language 2962 Kanji) run CCSID 290 - which is a SBCS CCSID. That confuses people, but true DBCS requires "Graphic" fields which do not contain Shift-Out/Shift-In characters because ALL the data contained in the field is DBCS. Graphic fields also double the length of the field, thus the SBCS/DBCS databases would have different record lengths.
The iSeries Information Center (documentation manuals) has copious information on Globalization under the Programming section and some examples of creating Unicode logical files over physicals for the system to do CCSID/data runtime conversion...
The topic of Unicode usually surfaces around Internet/WebServers/Email interfaces - especially from non-iSeries people. The JD Edwards World database cannot change because of RPG-3 and the way languages were implemented. Even RPG-4 must use system API's to convert/process graphic (Unicode) data. Companies cannot change database files to Unicode because any JD Edwards upgrade/cume/pccpy will convert the database back during file conversions. Also, just as is true when files are changed for World DBCS, if you change the database to Unicode, it will change file format level id's. All programs using native I/O or embedded SQL on those tables would need to be recompiled, and a PL/1 compiler would be required.
Thanks for the information. It helped me get going.