Data fields in foreign languages are showing up as asterisks or other non-displayable characters
Article ID: 33139
Updated On:
Products
Issue/Introduction
Problem:
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:
Multinational corporations using any operating system
Cause:
An IDMS system that is implemented without the proper version of module RHDCCODE to interpret the data.
Resolution/Workaround:
Foreign language support is implemented for IDMS with Codepages. Most of the Codepages support specific languages but you can customize one 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. This is noted in technical note QI78099.
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. Some sites had to change one thing CP1140F; they had to define the #DEFBYTE macro to support a tilde (~). This is done by implementing the statement x'A1' TYPE=ALPHA in CP1140F.
Codepage samples are delivered at CA IDMS install time into the SMP/E defined CAGJSRC library. We deliver the default Codepage under the name CP1140R, not just plan CP1140.
There is occasionally a need to implement a specific translation at the application level. If you don't have situations like this then specifying the Codepage at the system level should be adequate. An example of when you'd need to implement something at the application level as well as at the system level is mentioned in the CA IDMS Systems Operations manual, in chapter "International Character Set Considerations" under subtopic "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, you would have to specify a CODEPAGE 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:
The use of Codepages is documented in the System Operations manual, section 5.2 (Customizing RHDCCODE); and in Knowledge Document TEC502048.
Technical note TEC582272 may also be helpful; it outlines how to implement the new Codepage in RHDCCODE.
As noted above, there is occasionally (and rarely) a need to implement one code page at the system level and another for a specific program. Information on how to do this is provided in TEC502048. This is usually not necessary.
Technical note TEC522052 documents the exception noted above to the system-wide nature of changing RHDCCODE, 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.
Environment
Component:
Feedback
