Guidelines for Constructing Names of Name Service Entries

A global name includes both a cell name and a cell-relative name that consists of a directory path name and a leaf name. The cell name is assigned to a cell root at its creation. When you specify only a cell-relative name to an NSI command, NSI automatically expands the name into a global name by inserting the local cell name. When returning the name of a name service entry, a group member, or member in a profile element, NSI operations return global names.

The directory path name and leaf name uniquely identify a name service entry. The leaf name should describe the entry; for example, by identifying its owner or its contents. The remainder of this topic contains guidelines for constructing leaf names. Note that directory path names and leaf names are case sensitive.

Naming a Server Entry
For a server entry that advertises an RPC interface or service offered by a server, the leaf name must distinguish the entry from the equivalent entries of other servers. When a single server instance runs on a host, you can ensure a unique name by combining the name of the service, interface (from the interface definition), or the system name for the server's host system.
For example, consider two servers, one offering a calendar service on host JULES and the other on host VERNE.
The server on JULES uses the following leaf name:
calendar_JULES

The server on VERNE uses the following leaf name:
calendar_VERNE

For servers that perform tasks on or for a specific system, an alternative approach is to create server entries in a system-specific host directory within the name service database. Each host directory takes the name of the host to which it corresponds. Because the directory name identifies the system, the leaf name of the server entry name need not include the host name, for example:
/.:/LandS/host_1/Process_control

To construct names for the server entries used by distinctive server instances on a single host, you can construct unique server entry names by combining the following information: the name of the server's service, interface, or object; the system name of the server's host system, and a reusable instance identifier, such as an integer.

For example, the following leaf names distinguish two instances of a calendar service on the JULES system:
calendar_JULES_01

calendar_JULES_02

Avoid automatically generating entry names for the server entries of server instances, for example, by using unique data such as a time stamp (calendar_verne_15OCT91_21:25:32) or a process identifier (calendar_jules_208004D6). When a server incorporates such unique data into its server entry names, each server instance creates a separate server entry, causing many server entries. When a server instance stops running, it leaves an obsolete server entry that is not reused. The creation of a new entry whenever a server instance starts may impair performance.

A server can use multiple server entries to advertise different combinations of interfaces and objects. For example, a server can create a separate server entry for a specific object (and the associated interfaces). The name of such a server entry should correspond to a well-known name for the object. For example, consider a server that offers a horticulture bulletin board known to users as horticulture_bb. The server exports the horticulture_bb object, binding information, and the associated bulletin-board interface to a server entry whose leaf name identifies the object, as follows:
horticulture_bb

Note that an RPC server that uses RPC authentication can choose identical names for its principal name and its server entry. Use of identical names permits a client that calls the rpc_binding_set_auth_info routine to automatically determine a server's principal name (the client assumes the principal name to be the same as the server's entry name). If a server uses different principal and server entry names, users must explicitly supply the principal name. For an explanation of principal names, see the DCE Security Service part of the DCE Application Development Guide.

Naming a Group
The leaf name of a group should indicate the interface, service, or object that determines membership in the group. For example, for a group whose members are selected because they advertise an interface named Statistics, the following is an effective leaf name:
Statistics

For a group whose members advertise laser-printer print queues as objects, the following is an effective leaf name:
laser-printer

Naming a Profile
The leaf name of a profile should indicate the profile users; for example, for a profile that serves the members of an accounting department, the following is an effective leaf name:
accounting_profile