Data fields in foreign languages are displayed as asterisks or other non-displayable characters
Article ID: 33139
Updated On:
Products
Issue/Introduction
Multinational companies may have a need to display letters with accent marks on them somewhere. Usually these are in Portuguese, French, German, or Spanish words. If this is not correctly implemented, these letters that have accents will display as blanks, asterisks or other characters.
Environment
Release: All supported releases.
Cause
An IDMS system that is implemented without the proper version of module RHDCCODE to interpret the data.
Resolution
Foreign language support is implemented for IDMS with Codepages. Most of the Codepages support specific languages but they can also be customized to support multiple languages. Codepages are implemented in module in RHDCCODE. The changes implemented in module RHDCCODE via a Codepage will be reflected in all the system components.
The default Codepage, which supports only US characters, is CP1140. The most commonly used alternative is CP1140F, which supports both US and European character sets. To support the tilde character (~), it will be necessary to change the #DEFBYTE macro for x'A1' to TYPE=ALPHA in CP1140F.
Codepage samples are delivered at IDMS install time into the SMP/E defined CAGJSRC library. The default Codepage is delivered under the name CP1140R, not just plan CP1140.
There is occasionally a need to implement a specific translation at the application level. If this is not necessary, then specifying the Codepage at the system level should be adequate. An example of when it would be necessary to implement something at the application level as well as at the system level is mentioned at Customizing RHDCCODE:
"Another concern is uniqueness of data representation. An example is u-diaeresis, a German character that is usually replaced by "ue" if it cannot be typed in. By making the u-diaeresis a valid character, spelling of a word is no longer unique. For example, "Muenchen" and "Munchen" (U with an umlaut, which I can't copy here) both are valid German words for the city of Munich. This problem has to be handled at the application level by, for example, disallowing the "ue" representation of u-diaeresis."
There is one additional exception to the system-wide nature of changing RHDCCODE. That is when COBOL programs are used as a TCP/IP client or Server between IDMS on the mainframe and some other platform that supports UNICODE or ASCII. In that situation, a CODEPAGE would have to be specified at the application program level so that it knows how to translate the database fields. Other COBOL programs, which don’t need to do any data conversion between character sets, will not need to specify a Codepage.
Additional Information
Feedback
