Considerations for Enabling DBCS

Following are consideration items you need to keep in mind before you start your actual design.

• Designing DBCS support from the beginning

  It is an ideal process if all the DBCS and NLS requirements and consideration are included in the early design phase because adding DBCS support into existing products tends to be considerably expensive. You have to locate hits, add DBCS support, and re-test the DBCS support version. Sometimes, your external interfaces need to be changed to accept DBCS. So, DBCS support should be specified and designed from the very beginning, and DBCS enabling works should be incorporated into your development process.

• Hardware Independence

  A hardware independent program is a program which does not access the hardware resource directly but through the system software services. DBCS hardware has unique features. If your program uses the capability of hardware directly, then your program may have hardware dependence on those hardware, and you may need to define the support hardware list for your program and enable your program to support the DBCS hardware.

  If your program supports the same hardware devices, still it may need to cover such differences as resolution of the display and the key layout of the keyboard. Those different information are defined as the device characteristics or device capabilities (DEV CAPS) and can be obtain by the system Dev API. A hardware independent program will not assume these device value and queries them from the system through the system Dev API. This style of hardware independent programming is recommended.

• Differences of Code Page

  In order to handle DBCS data, you must take care of the following:

  • Some applications use MSB (Most Significant Bit) of a character/byte as a flag and so on. It was OK for the applications who use only the left half of a code page. But, now you must not use MSB since the right half of code pages is very important for national characters and DBCS.

  • Do not hard-code the DBCS code page and DBCS code range information. If you want to judge whether a code page is a combined code page or SBCS code page, instead of preparing a table in your module, apply the system provide API to get the DBCS code range from the DBCS environment vector. If the range is zero, then the code page is an SBCS code page, else it is a DBCS code page.

  • Do not use national unique characters (including DBCS characters) as syntactic character, command, system file name. Use the characters whose code points are the same across all code pages, i.e. from 20H through 7DH, excluding 5CH. Be aware that the code points of DBCS character are different even for DBCS alphanumeric in each DBCS language. See Example of Code Points Used in Each DBCS National Language.
  
  Define the DBCS support data format

  Not all the data format need to support DBCS data. Normally text data need to support DBCS data. (See the Types of Character Data for the discussion about what types of data are need to be supported as the DBCS data. Also see Data Type.) You may need to consider the following types:

  • Mixed DBCS data

    Both SBCS data and DBCS data are allowed.

  • Pure DBCS data

    Only DBCS data are allowed.

  • SBCS (no DBCS) data

    Only SBCS data are allowed.

  
  Need the DBCS OS/2 and requisite hardware

  You can perform the DBCS and NLS enabling tasks (e.g. coding, compile) on the SBCS environment, but you need to test the program on a DBCS environment.

  
  Differences in DBCS Application Development Environments

  Considerations are described in DBCS Support in a Typical Application Model

  
  Single Module

  Considerations are described in Single Module

  ---

  [Back: General Considerations]
  [Next: Considerations for Languages]