HP OpenVMS Systems Documentation
Backtranslation soft links enable Session Control to translate a node address to the full name of a node object entry. For example, end user applications often require the node name of the source of incoming connect requests. A DECnet-Plus node can include its name in the data it sends to request a connection, but a Phase IV node provides only an address. A backtranslation soft link contains the data necessary to make the translation from an address to a DECdns node name.
Backtranslation soft links are stored in a hierarchy of directories beginning with a directory named .DNA_BackTranslation. The .DNA_BackTranslation directory contains one child directory for each IDP in the network. Each IDP directory contains one child directory for each local area defined within that IDP. Each local area directory contains one soft link for each node in that area.
Unlike DECdns, the Local namespace does not use backtranslation directories for address to node name translation. In a DECdns namespace, the decnet_register tool automatically creates the .DNA_BackTranslation directory, as well as IDP and area directories derived from all existing Phase IV addresses. In addition, the tool has an option for creating new IDP and area directories for DECnet-Plus nodes.
The following illustration shows a backtranslation soft link:
The %X symbols in the IDP, area, and node ID segments of the soft link indicate to DECdns that the numbers that follow are in hexadecimal notation. For a complete explanation of the DECnet Phase V address structure, see Section 1.3.1.
When you register a Phase IV node in a distributed namespace, decnet_register constructs a backtranslation soft link based on whatever address the user specifies in the node registration information. When you register a DECnet-Plus node, the node creates its own backtranslation soft link.
When you register a node in a local namespace using
decnet_register, you can specify a Phase IV address and/or one
or more towers in the local name file. Backtranslation information is
maintained in the database.
5.5.3 Node Synonyms
A node synonym is a soft link that points to the full name of a node object entry. Node synonym soft links, in the form of a Phase IV-style node name, exist so that Phase IV applications that do not support the length of DECdns full names can continue to use six-character node names. A node synonym is optional; the system manager can supply it during DECnet-Plus configuration. Node synonyms are stored in a required directory called .DNA_NodeSynonym, which decnet_register creates automatically during DECnet-Plus configuration of a distributed namespace. In the Local namespace, synonym mapping is maintained by the database.
When DECnet-Plus Session Control receives a node name of six characters or fewer that does not include a leading dot or namespace nickname, it tries to look up that name in the .DNA_NodeSynonym directory in a distributed namespace. Suppose, for example, DECnet-Plus is given the node name MIS01. Session Control sends a request to DECdns to look up .DNA_NodeSynonym.MIS01. The node synonym exists and points to the full name of the node, ABC:.Geneva.Admin.MIS01. Session Control can then ask DECdns to look up the node object entry named ABC:.Geneva.Admin.MIS01 and get the address information it needs to contact the node.
Node synonyms are not for users to avoid typing the DECdns full name of
a node. Local names, and a feature called the local
root, offer that capability on a per-node basis. For details,
see the DECnet-Plus DECdns Management guide.
5.6 How DECdns Protects Names
The decnet_register tool manage command lets you
control access to clearinghouses, directories, and their contents.
Access to clerks and servers is determined by operating system rights
5.6.1 Access Rights
The DECdns access rights are read, write, delete, test, and control. Each right has a slightly different meaning, depending on the kind of name with which it is associated. In general, the meanings are as follows:
You assign access in the form of an access control entry (ACE), which consists of two parts: the principal portion and the list of access rights that the principal has to the associated name in the namespace. The principal part of the ACE can be the name of an individual user, a group name, or a name with one or more wildcard characters to denote several users. For example, the following wildcard notation denotes all users on all nodes in the specified namespace:
A name can have multiple ACEs associated with it. The complete set of
ACEs for a particular name is called an access control
set (ACS) and is an attribute of that name.
5.6.2 Access Control Groups
It is often useful to set up an access control policy when you plan your namespace, choosing a select group of users who will have control over the root of the namespace and deciding how to delegate access to other directories. Two DECdns groups are available to help you implement such an access control policy: .DNS_Admin and .DNA_Registrar.
The .DNS_Admin group is an access control group meant to contain the names of people responsible for managing the entire namespace. The DECnet configuration procedure creates this group when it creates a new namespace. If you want to use the .DNS_Admin group, you must explicitly add members and create ACEs for the directories that you want the group to control.
You can create ACEs for the .DNS_Admin group that propagate from the root directory down to all subsequent child directories and their contents. Propagating access rights allows .DNS_Admin members to monitor any changes or problems in the namespace. Consider a policy requiring that the .DNS_Admin group also be given access to all clearinghouses. A clearinghouse is named in a directory but not contained in that directory, so it does not inherit access control from a directory's ACS. See the DECnet-Plus DECdns Management guide for details on creating ACEs, managing groups, and implementing a namespacewide access control policy.
The .DNA_Registrar group is an access control group for people who manage node object entries and node soft links. You must explicitly add members to this group as well. You might want to add the .DNS_Admin group as a member of this group, thereby automatically giving .DNS_Admin members access to whatever .DNA_Registrar members can manage.
The decnet_register tool creates the .DNA_Registrar
group and grants the group full access to all directories, object
entries, and soft links that the tool creates. Section 7.4 describes
the access rights that the tool automatically assigns, and suggests
ways to modify the default access control policy.
5.7 DECdns Management
DECdns provides two user interfaces for examining and managing the
components of a namespace: a windows-based Browser utility and a DECdns
Control Program, called DNS$CONTROL on OpenVMS systems and
dnscp on DIGITAL UNIX and ULTRIX systems. The DECdns Control
Program is an interface that accepts commands targeted for specific
entities, such as clerks, clearinghouses, or directories. The browser
is a tool for viewing the content and structure of a namespace. It runs
on workstations with DECwindows or Motif software.
5.8 How DECnet-Plus Uses DECdts
DECnet-Plus software includes DECdts. DECdts is self-configuring, but offers a command-line management interface that allows system managers to display and update the time on any system in the network.
The DECdts application programming interface (API) allows applications (DECdns, for example) to obtain, modify, and compare timestamps. DECdts servers also accept time values from external sources through the DECdts time-provider interface; these sources can be radio receivers, data communications software, or other time services, such as NTP (Network Time Protocol). Sample time-provider programs are also supplied with the DECdts software.
DECdts consists of software components on a group of cooperating systems. In a typical DECdts implementation, a few servers supply the time to many client systems and applications through intermediaries called clerks. Clerks reside on their client systems.
Because no device can measure the exact time at a particular instant, DECdts expresses the time as an interval containing the correct time. DECdts clerks obtain time intervals from several servers, and compute the intersection where the intervals overlap. Clerks then adjust the system clocks of their client systems to the midpoint of the computed intersection. When clerks receive a time interval that does not intersect with the majority, they declare the nonintersecting value to be faulty. Clerks ignore faulty values when computing new times, thereby ensuring that defective server clocks do not affect clients.
DECdts offers all the features generally provided by a time service,
but it also has several unique features that enhance network
performance. This section describes these DECdts features.
5.9.1 Applications Support
Operating systems and distributed applications require synchronized time measurements to coordinate their processes. DECdts synchronizes the system clocks in a network with each other, and in the presence of an external time-provider, to the UTC time standard. Any distributed application that reads the system clock (the majority of applications) needs DECdts. As the number of distributed applications and systems in a network increases, DECdts becomes increasingly vital to process coordination.
For new applications, DECdts provides an application programming
interface (API) that provides routines applications can use to obtain
and manipulate binary timestamps. For example, routines are available
to convert the OpenVMS local time format used in DECnet-Plus for
OpenVMS systems to UTC. The DECdts API supports ANSI C language
constructs; you can use the same calls on DECnet-Plus for OpenVMS and
DECnet-Plus for DIGITAL UNIX systems.
5.9.2 Automatic Time Zone Changes
On DECnet-Plus systems, DECdts automatically sets the system time
according to the time zone rule you specify during the initial
configuration procedure. DECdts communicates by using
UTC; it uses the time zone rules to translate from UTC to local time.
In addition, the time zone rules can define seasonal time changes. For
example, you can specify that when daylight saving time takes effect,
the system clock should be updated automatically.
5.9.3 External Time-Provider Support
For most networks, it is desirable to synchronize the system clocks
with the UTC time standard. Many commercial devices are available for
obtaining the UTC time provided by standards organizations; these
devices receive signals by short-wave radio, satellite, and telephone.
If your network is larger than a single LAN, DIGITAL recommends that
you use at least one external time-provider in combination with the
DECdts software. Sample time-provider programs for use with various
time-providers are supplied with the DECdts kit and are available on
line. The DECdts kit also contains a time-provider interface that
describes the interprocess communications between a DECdts server and a
5.9.4 Quantitative Inaccuracy Measurement
Unlike other network time services, DECdts uses manufacturer's
specifications and direct observation to determine the inaccuracy of
system clocks relative to UTC. DECdts appends an inaccuracy measurement
to each time value that it uses internally; this measurement takes into
account cumulative clock error, communications delays, and processing
delays. DECdts uses combined time and inaccuracy measurements from one
or several sources to calculate the most accurate new clock settings
for client systems.
5.10 How DECdts Works
DECdts has two major software components:
The following sections describe each of these components and tell how
they interact to provide time to client applications and to synchronize
Any system that is not a DECdts server is a DECdts clerk; most network systems run clerk software. Clerks are the intermediaries between clients and servers. Clerks also maintain server lists and perform the synchronization functions for DECdts client systems. Clerks send multicast queries to all servers and build server lists from the servers that respond. Clerks contact known servers for new server lists periodically, or whenever the number of servers on their lists falls below the minimum specified by the servers required attribute. (This attribute is one of several settable DECdts characteristics available through the management interface.)
After building a server list, a clerk can directly request time values
from the number of servers determined by the servers
required management parameter. The clerk then receives these
time values and uses them to compute a new system time for its client
Servers provide many of the communications functions for DECdts. They provide time intervals to clerks and other servers, and advertise their presence on the LANs of which they are members.
External time providers can be connected to servers, which then
propagate the precise time intervals they obtain from the time-provider
throughout the network. The rest of this section describes the three
types of DECdts servers.
18.104.22.168 Local Servers
A set of local servers reside on the same LAN and maintain their clocks by synchronizing with each other. Local servers use the IEEE 802.2 (CSMA-CD) protocol to communicate; due to the high throughput on this type of network, the skews between the local servers on the LAN are normally maintained at under 200 milliseconds. If at least one of the servers in the local set synchronizes with an accurate external time-provider, inaccuracies at each server may be even less.
Each local server advertises itself on the LAN by sending multicast
messages containing its address. Each server builds lists of the other
servers in the LAN by listening to the multicast messages. When a
server synchronizes, it queries all the other servers on its server
list for time values. Servers that do not respond are deleted from the
list of servers. Local servers perform time-interval computations,
adjust their clocks, and provide time values to each other for
synchronization purposes. Each server must synchronize with every other
server in the local set at periodic intervals.
22.214.171.124 Global Servers
WANs and many extended LANs require global servers. Local servers are available only to the servers and clerks in a single LAN, but global servers are available across an extended LAN or WAN. Any server can be configured as both a local and a global server. The number of global servers is usually small, but global servers have several important functions that enable DECdts to synchronize every node in the network. Global servers are necessary in the following situations:
A list of DECdts global servers is always available to network systems through DECdns, which maintains a list of the DECdts global servers. All DECdts clerk and server systems are also DECdns clients. DECdts servers and clerks also maintain their own lists of global servers, which are periodically refreshed from the directories maintained by DECdns.
Local servers and clerks request time values from global servers when
they cannot obtain the number of local server responses mandated by the
servers required attribute. Certain local servers also
regularly request the time from global servers; see the following
Designated local servers called couriers regularly communicate with global servers. Couriers are local servers that request time values from one global server at every synchronization. To ensure that all parts of the network contribute their time values to the LAN, couriers randomly select a global server from the DECdns namespace before each synchronization. Couriers use the responses of both local and global servers when synchronizing their own clocks.
For a network containing multiple LANs or point-to-point links, configure one server on each LAN or segment as a courier; this configuration ensures that various portions of the network remain synchronized and are not isolated from each other.
Using the management interface, you can also designate one or more
servers to be backup couriers. These local servers
temporarily assume courier functions in the event that no courier
servers are available on the LAN. In such a case, the backup courier
with the lowest numbered Ethernet address regularly synchronizes with
global servers until a courier is again available.
5.11 DECdts Management
DECdts is managed with NCL. System managers can adjust system clocks, change the values of the DECdts management parameters, and add or subtract servers from the network. To aid in solving problems with system clocks, DECdts also provides event reporting that notifies system operators and managers in the rare event that a system clock is inaccurate or fails to synchronize.