OSF DCE Application Development Guide--Core Components

Writing Internationalized RPC Applications
processes on the client host and processes on the server host.
2. The server, as part of its initialization phase, calls a DCE RPC routine that
retrieves information about code sets support on the server’s host. The RPC
routine examines the host’s locale environment and its code set registry to
determine the host’s supported code sets; that is, code sets for which conversion
routines exist that processes on the host can use to convert between code sets, if
necessary.
The code set registry is a per-host file that contains mappings between string
names for the supported code sets and their unique identifiers. OSF assigns the
unique identifiers for the code sets and DCE licensees, and DCE administrators
assign their platform string names for the code sets. The DCE RPC routines for
character set and code set interoperability depend upon a code set registry existing
on each DCE host. For more information about the code set registry, see the and
the csrc(8dce) reference page.
The routine returns a list of the supported code sets to the server; the list consists
of each code set’s unique identifier.
3. The server next calls a new RPC NSI routine to register the supported code sets
information in the name service database. Recall that a server can use the NSI to
store its binding information (information about its interfaces, objects, and
addresses) into its own namespace entry, called a server entry. The new RPC NSI
routine adds the supported code sets information as an attribute that is associated
with the server entry, which the server created when it used the NSI export
operation to export its binding information into the name service database. Placing
the code sets information into the name service database gives RPC clients access
to this information.
4. Before it calls the RPC NSI routines that locate a server that offers the desired
remote procedure, the client calls a new RPC routine that sets up a character and
code sets compatiblity evaluation routine.
5. The client calls RPC NSI routines to locate a compatible server. The RPC NSI
routines invoke the character and code set compatibility evaluation routine set up
by the client to evaluate potential compatible servers for character and code set
compatibility with the client.
6. The evaluation routine imports the server’s supported code sets information from
the name service database, retrieves the client’s supported code sets information
from the client host, and compares the two. If the client and the server are using
the same local code set—the code set that processes on the host use to encode
character data—then no code set conversion is necessary, and no data loss will
result.
If client and server are using different local code sets, then it is possible that the
server is using a different character set than the client. The client does not want to
bind to a server that is using a different character set, since significant data loss
would result during character data conversion. Consequently, the evaluation
routine uses the server’s code set information to determine its supported character
sets, and rejects servers using incompatible character sets. For example, if a client
is using the Japanese Kanji character set (such as JIS0208), the evaluation routine
rejects a server that offers the desired remote procedure but which is using the
Korean character set (such as KS C 5601).
124245 Tandem Computers Incorporated 15−5