Often in client/server environments, a client machine may use different character encoding than the server machine, particularly if the client machine is set up for foreign language characters that utilize values above ACSII 127 and the server is not, or if the client is using a PC character set and the server is using a UNIX character set. This presents a problem when programs or data are passed between the environments, because the characters do not translate directly.
If you anticipate passing any items with special characters (e.g., vowels with a grave accent, acute accent, circumflex, tilde, etc.) during a remote CALL, then you should create a map file to reconcile the character encoding for you.
The map file should specify which client characters are to be converted to which values before passing the CALL's arguments to the server process or returning information from the server process. The translation on returning data will affect items that were passed to the server process as "BY REFERENCE" (the default).
The map file should re-map only those values that vary between the two character sets. It should contain two values per line: the first indicating the decimal or hexadecimal value of the special character on the client machine and the second indicating the decimal or hexadecimal value of the corresponding character on the server machine. You can check the values of specific characters using the Windows Character Map accessory in the PC environment, or by referring to your UNIX man pages in the UNIX environment.
In your character map, hexadecimal values should use the standard "0x" notation. For instance:
0x90 0xC9
maps "E" (acute) in the IBM PC character set to "E" (acute) in the ISO8859-1 character set using hexadecimal notation.
144 201
gives the same mapping using decimal notation.
You can use the pound sign (#) to indicate a comment if desired.
Note that the map will be used to translate only alphanumeric fields; but it will translate all alphanumeric fields, including group items and items subject to a REDEFINES clause. If this is not a desired behavior, you may need to restructure your program to avoid these clauses by passing the elementary items instead of the group item, or passing an item from the REDEFINES clause instead of the first reference.
For example, if you pass the group-name in the following COBOL program:
01 group-name 03 field-1 pic99 comp-5. 03 field-2 pic99 comp-5. call "sun3:/usr/obj/prog2" using group-name.
Then translation will occur on the elementary numeric items. If these numeric items contain binary data that matches the value of mapped characters, the data will be corrupted. To correct this situation, you could change the CALL statement to:
call "*sun3:/usr/obj/prog2" using field-1, field-2.
Or you could change the definition of the numeric items to a type that will not conflict with potentially mapped characters, as in:
01 group-name 03 field-1 pic99. 03 field-2 pic99.
Defined this way, the numbers are stored as the ASCII representation of each digit, which should not conflict with any character mapping.
Once the map file is created, you place it on the client, or if the client is AcuServer enabled, you can place it on the client or server. Either way, you specify the location of the map file using the DEFAULT_MAP_FILE or server_MAP_FILE variables in the client configuration file (e.g., "client.cfg").