DCE Servers to Use (_s(xxx))

_s(sec)
This variable holds the name of the security server you want to use for the next registry operation. If you set this to specify a read-only replica and the operation (such as principal create) requires a master replica, the dcecp program ignores the variable and tries to bind to the master registry. Registry operations that use the _s(sec) variable include principal, group, organization, registry, account, and xattrschema.

DCE control program operations use the _s(sec) variable in conjunction with the _b(sec) variable which holds the name of the most recent registry used. A registry operation uses the following order to select a security server:

1. Use the server passed as a name argument to the registry operation.

2. If the operation lacks a name argument, use the server named in the _s(sec) variable.

3. If the _s(sec) variable has not been set, use the server named in the _b(sec) variable.

4. If the _b(sec) variable has not been set (that is, this is the first registry operation since the dcecp program was initialized), the service provides an arbitrary server that is suitable for the operation.

_s(cds)
This variable holds the name of the CDS server you want to use for the next directory service operation. When set, CDS operations attempt to use the specified server. The operation fails if the attempt is unsuccessful - such as when the server is unavailable for some reason. To overcome such a failure you must unset this variable or make the server available.

It makes sense to use the _s(cds) variable when all of your application needs can be satisfied by the clearinghouse named in the variable. Consider not using the _s(cds) variable when name lookups in CDS are likely to traverse directories in several clearinghouses. In this case, you'll get lookup errors because the _s(cds) variable limits the lookup operation to using just the named clearinghouse.

_s(dts)
This variable holds the name of the DTS server you want to use for the next time service operation. When set, DTS operations attempt to use the specified server. The operation fails if the attempt is unsuccessful - such as when the server is unavailable for some reason. To overcome such a failure you must unset this variable or make the server available.

One use of this variable is to restrict DTS operations to a single DTS server for monitoring purposes. Normally, time service operations can use any available DTS server.

_s(aud)
This variable holds the name of the audit daemon you want to use for the audit operation. By default, audit operations affect the local host's audit daemon. You can operate on a remote host's audit daemon by specifying its name as the value of the _s(aud) variable.

dcecp> set _s(aud) /.:/hosts/planets/audit-server
/.:/hosts/planets/audit-server
dcecp>

When _s(aud) is set, audit operations attempts to use the specified audit daemon. The operation fails if the attempt is unsuccessful - such as when the specified audit daemon is unavailable for some reason. To overcome such a failure you must unset this variable or make the audit daemon available.

You can specify a DCE server or audit daemon as any of the following:

· A DCE name. An example of a global registry name is /.../my_cell.goodco.com/subsys/dce/sec/oddball. An example of a cell-relative CDS clearinghouse name is /.:/Paris_CH.

· The string binding for the host where the server resides. String bindings can represent security servers, DTS servers, and audit daemons. They cannot represent CDS servers. An example of a string binding is {ncacn_ip_tcp 110.15.22.131}. The DCE control program resolves the binding to the appropriate service on the host.

· The name of the cell. For a remote cell, specify a global cellname such as /.../my_cell.goodco.com. For the local cell you can specify the root as /.:. These operations use an arbitrary server that is suitable for the operation.