Character data representation architecture design

To enable your application for a multilingual environment, consider the information in this topic.

• Avoid coding CCSID values directly in your DDS for physical files. When creating different physical files for different languages, change the CCSID for your job (using the CHGJOB command). Only one set of DDS source code needs to be maintained.

  Conversions between all CCSIDs might not make sense in all cases. For example, if you access a Greek database with a CCSID of 00875 from a German display station with a job CCSID of 00273, you see garbled data on your display.

  Countries outside the Latin-1 character set use character sets that include non-Latin characters. No meaningful conversion is possible between the non-Latin code points and the Latin code points. Arabic, Greek, Hebrew, and Turkish are SBCS languages with non-Latin characters.

• When database sharing takes place, define your files with the CCSID of the primary language being used. Make sure that all users have the CCSID of the language that they use defined in their user profile.

• Use of the Send Network File command
  When you use the Send Network File (SNDNETF) command, the data (if sending a member only) is assumed to be in the CCSID of the job that is running the command. Therefore, no conversion takes place. When the data is received, care must be taken to store the member in a file with the same CCSID as the originating file.
• Scenario: Multilingual single system
  The figure in this topic shows a multilingual single system with German as the primary language and English and French as secondary languages. All users enter data into the same database file.
• Scenario: Multilingual network
  The figure in this topic shows an example of a multilingual network with three iSeries™ servers located in three different countries, each with a different language.