In this scenario, there is a single server supporting Spanish users and applications.
The primary language of the system is Spanish (NLV 2931). Because 2931 is the primary language, the default system settings and i5/OS™ localization preference are set to Spanish.
The user has also created a database file where the fields of interest are defined to contain Unicode, because they plan to use this sane database file for both 5250 applications and Java™ applications.
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 preference for the Java application, the user sets the Java locale to sp_SP for Spanish in Spain.
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 profiles's CCSID value to 284 to tell the system that this user is on a Spanish 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.
