OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide

1.4.4 Processing the Files with the IDL Compiler

IDL’s input is an xxx.idl and (optionally) an xxx .acf ﬁle. Its default output is a header

(xxx.h) ﬁle, that contains deﬁnitions and declarations derived from the input for general

use in the development source code, and two stub ﬁles, one for the client and one for the

server, which contain runtime code for marshalling and unmarshalling, message

handling, and all the other details of managing network communications. The stub ﬁles

are output as object code (xxx_cstub.o and xxx _sstub.o) suitable for linking with the

developer’s compiled code. The IDL compiler generates C source code as an

intermediate step in the compilation process, and the output of this step can also be saved

in a pair of ﬁles (xxx_cstub.c and xxx _sstub.c).

In order for a pair of client and server stubs to interoperate, they should be generated

from the same interface deﬁnition (.idl) ﬁle, but they do not have to be generated with the

same attribute conﬁguration ﬁle (.acf). The compatibility rules for interface version

numbers also apply (see the ).

For further information on the IDL compiler, see the idl(1rpc) reference page.

1.5 Server Initialization

Servers must initialize some data and notify various DCE services about themselves

prior to servicing RPC requests. At a minimum, servers must register with DCE and then

go into a wait state listening for remote procedure calls. In addition to these minimum

tasks, your application may ﬁrst parse the input arguments, obtain information about how

it was started using dced API calls, and establish the proper message tables and locale

for internationalization.

DCE applications should be started in such a way that they can be controlled by dced.

When the server is installed, the dcecp server create operation (or a custom made server

management application) is commonly used to establish the server’s conﬁguration with

its host dced. This conﬁguration data includes among other things the program name

and its arguments, the CDS entry name to use for exporting to the name service, and the

valid starting methods. Installing your servers in this way does not compromise their

security because dced operations are protected with ACLs, and the major advantages

include the following:

• You do not have write any complex management code for each server

• Your servers are like other DCE servers in that they can all be managed consistently

Depending on how the server is conﬁgured, the dced can start it in the following ways:

• At boot time when the DCE daemon itself starts

• Explicitly via the dcecp server start operation (or from another application that

called dced_server_start())

• Automatically when a remote procedure call comes in for the server

1− 12 Tandem Computers Incorporated 124246