Although the DCE control program, dcecp, is intended as an administrator's tool, developers will find it invaluable for examining and modifying many aspects of the DCE environment. It can be used in constructing installation scripts, as in the following examples:
· For exporting binding information to a namespace, instead of putting C code in your application to call the NSI routines, rpc_ns_*( ), you could write a dcecp script that calls rpcentry export and its related commands.
· For installation, you might need to create a principal name and/or set an access control list (ACL) on it. Instead of writing C code in your application's initialization section to call sec_rgy_pgo_*( ) and sec_acl_*( ), you could ship a dcecp script that includes the following:
principal create ...
acl mod /.:/sec/principal/...
· It is recommended that you have dced start your application by using server configuration information. It is generally better to do this by writing a dcecp script that sets up the server configuration information (the arguments to start the executable) rather than doing it with C code that calls the dced_server_create( ) API.
In general, dcecp scripts for server configuration allow better flexibility than embedded C code. Furthermore, unlike embedded code, the script does not persist after configuration is done.
The DCE control program can also be useful for debugging, as the following examples show:
· You can check exported information in the namespace with rpcentry show or rpcgroup, rpcprofile show.
· You can use server ping to see if your server is running and receiving requests.
· If your server was set up to be started by dced, you can start it by using the server start command and can view the startup parameters by using server show -executing.