OSF DCE Application Development Guide--Introduction and Style Guide

Introduction to DCE Application Programming
a procedure in terms of their data types, access method, and call order, and declares
the data type of the return value (if any).
The skeletal interface definition produced by the uuidgen utility provides an interface
header that contains the newly generated UUID for the interface, a version number, and a
dummy string INTERFACENAME. Replace this dummy string with the name of your
interface, then add any additional interface header attributes your application requires.
(See the for a complete description of interface header attributes).
The skeletal interface definition file also provides an interface body, which consists
solely of {}, that is, an empty pair of braces. You fill in the space between the braces
with your RPC interface’s import, constant, type, and operation declarations, written in
IDL. The explains this process in more detail. In addition, the same volume for a
complete description of the IDL syntax for specifying import, constant, type, and
operation declarations.
Note that a server can implement more than one interface. In this case, you define each
interface in a separate .idl file and compile it separately with the IDL compiler. You then
link the implemented interface operations in various source code files with the IDL
output.
1.4.3 Writing the Attribute Configuration File
The attribute configuration file (.acf) is an optional additional input file to the IDL
compiler, that, if present, affects the IDL compiler’s output in various ways. The
difference between the purpose of the .idl and an .acf file is that while the .idl file defines
how the network communications between the client and server are handled, the .acf file,
if one is present, affects only the interaction between the stub code modules and the
developer code that they support. In other words, changing the contents of an .acf file
has no effect on the network communications between the client and server.
Nevertheless, some of the features offered by an .acf file are very important, and they
cannot be obtained by any other means. For example, The comm_status attribute
configuration file attribute allows the status code of a communications failure that occurs
in an RPC to be stored as a parameter or returned as a result, rather than being raised to
the caller code as an exception. This attribute can only be declared in an .acf file; it
cannot be declared in an .idl file. Another very important function of the .acf file is the
specification of a binding method to be used by remote clients of the application. Three
methods are available, as follows:
• auto_handle
• implicit_handle
• explicit_handle (the default)
These binding methods are described in Chapter 4 of this guide. The binding method
you choose determines how much attention your server’s clients will have to devote to
the upkeep of their binding handles.
See the for a description of the attribute configuration file attributes available for use in
attribute configuration files.
124246 Tandem Computers Incorporated 1− 11