In this scenario, there is a single server supporting Spanish users and applications and an existing EBCDIC database.
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 is 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 same database file for both 5250 applications and Java™ applications. They also have an existing database in which the fields are defined in EBCDIC.
The following example shows the SQL statement used to create the EBCDIC database:
CREATE TABLE SAMPLE (PART_NAME CHAR (10) CCSID 284 NOT NULL WITH DEFAULT, STOCK_NUMBER INT NOT NULL WITH DEFAULT 0)
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)
When using the Unicode file
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.
When using the EBCDIC file
If the user wants to display this data with a web service, then the file first must be converted to Unicode. This can be done with the JDBC connector. 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, EBCDIC is the natural encoding for the 5250 device and no conversion is needed. To print the EBCDIC data, the user sends the data to the printer; because EBCDIC is the default encoding for the printer, no conversion is needed.
Logical file support
One of the unique features of i5/OS is the ability to use the system's logical file support to have either the EBCDIC file appear to the application as a Unicode file, or to have a Unicode file appear to the application as an EBCDIC file. This might be of use if you want to move your database to Unicode, but do not want to update your existing applications.
If the majority of your application's use of the database involves Unicode, you can have the data stored as Unicode, and create a logical view of the file in EBCDIC. You can then have your EBCDIC programs access this logical file and they do not need to be updated to handle Unicode.
If the majority of your application's use of database involves EBCDIC, you can have the data stored as EBCDIC, and create a logical view of the file in Unicode. You can then have your Unicode programs access this logical file and they do not need to be updated to handle EBCDIC. However, because EBCDIC encodes a smaller set of characters than Unicode does, some character loss might occur.
The following figure illustrates this scenario.
