In this scenario, there is a single server supporting English, Japanese, and German users and applications.
The primary language of the system is English (NLV 2924). The system has also been loaded with secondary languages of Japanese (NLV 2962) and German (2929). Because 2924 is the primary language, the default system settings and i5/OS™ localization preference is set to English. Because these three NLVs are installed, each user can work with the system in English, German, or Japanese.
The users see their language of choice and i5/OS localization preference from the initial sign-on screen by the use of a subsystem description for each secondary language.
The user has also created a database file in which the fields of interest are defined to contain Unicode. Because Unicode provides a unique number for every character on any platform, in any program,and in any language, one field can contain English, German, and Japanese.
The following example shows the SQL statement used to create a database containing a Unicode field named "PART_NAME" and a non-Unicode field named "STOCK_NUMBER":
CREATE TABLE SAMPLE (PART_NAME GRAPHIC (10) CCSID 1200 NOT NULL WITH DEFAULT, STOCK_NUMBER INT NOT NULL WITH DEFAULT 0)
If the user wants to display this data with a web service or Unicode enabled application, then Unicode is the natural encoding for web use and no conversion is needed. To get the correct localization and interface preference for the Java™ application, the user needs to set the Java locale to the correct value: en_US for English, Jp_JA for Japanese, and de_DE for German.
If the user wants to display this data with a 5250 session, then the Unicode field must be converted to the CCSID of the display device. The user only has to set the user profile's CCSID value to the correct value (37 for English, 1399 for Japanese, and 278 for German) to tell the system what the user's preference is for the display. This service is provided automatically by the system if requested with the CCSID keyword and the *CONVERT parameter in DDS.
To print the Unicode data, the user specifies the *NOCONVERT parameter of the CCSID keyword, and a TrueType font using the FONTNAME keyword. The unconverted Unicode data can be printed with PSF/400 or with Host Print Transform.
The following figure illustrates this scenario.
