Based on the character set used on the platform where the agent and subagent are running, you will encounter one of the following three scenarios:
In reality a lot of platforms use the ASCII character set. For those platforms, just use the native character set. In that case, the native character set is ASCII.
It is expected that the agent and the subagent normally run on the same machine or at least on the same platform. In that case, it is easiest to use the native character set for data that is represented as strings. If such native character set is not the ASCII character set, the agent must translate from ASCII to the native character set (and vice versa) as needed.
If the agent and subagent each run on their own platform and those platforms use different native character sets; for example, IBM OS/2 uses ASCII and IBM MVS uses EBCDIC, you must select the ASCII character set, so that you both know exactly how to represent string-based data that is being send back and forth. The entity that is not ASCII based must do the translation from ASCII to the native character set (and vice versa) as needed.
When the DPI subagent sends a DPI OPEN packet, it must specify the character set that it wants to use. The subagent here needs to know or determine in an implementation dependent manner if the agent is running on a system with the same character set as the subagent. If you connect to the agent at loopback, localhost, or your own machine, you might assume that you are using the same character set. As long as you are just using OS/2 on an Intel based processor, it does not matter. Always use the native character set, which is ASCII.
The subagent has two choices:
DPI_NATIVE_CSET
The DPI packets have a number of fields that are represented as strings. The fields that must be represented in the selected character set are:
Related Information