Do not edit the NET$SEARCHPATH_STARTUP.NCL script. If you need to change the naming search path information, use NCL or rerun NET$CONFIGURE.
Besides determining the order of searches, the naming search path describes how DECnet should interpret any abbreviated node names entered by users. The search path contains an ordered list of name service keywords, each followed by a naming template that specifies a "defaulting rule" so users can enter shorter node names. In each template, the user-supplied portion of the name (usually the node's terminating name or rightmost simple name) is indicated with an asterisk (*). For example, if the DECdns template is "ACME:.mgmt.*" and a user supplies the name accnt, then the full name ACME:.mgmt.accnt will be looked up in namespace ACME in the DECdns name service. See Section 5.1.3 for more examples.
You can use nclcommands to display information about the search path maintained for forward or backward translation.
To display information about the search path maintained for forward translation or naming (node name to address translation), use the following nclcommand. Descriptions of the display example follow:
# ncl show session control naming search path Node 0 Session Control AT 1996-03-19-10:26:03.809-05:00I49.474 Characteristics Naming Search Path = ( [ Directory Service = Local , (1) Template = "*" ] , [ Directory Service = Local , (2) Template = "local:.lky.*" ] , [ Directory Service = Local , (3) Template = "LOCAL:*" ] , [ Directory Service = DECdns , (4) Template = "*" ] , [ Directory Service = Domain , (5) Template = "*" ] )
Note that each naming service can have more than one entry, each template defining a different way for the name to be searched.
To display information about the search path maintained for backtranslation (address to node name translation), use the following command. An example and description of the information displayed follows:
$ ncl show session control backtranslation search path Node 0 Session Control AT 1996-03-19-11:00:57.490-05:00I49.712 Characteristics Backtranslation Search Path = ( [ Directory Service = Local , (1) Template = "*" ] , [ Directory Service = DECdns , Template = "local:.DNA_BackTranslation" (2) ] , [ Directory Service = Domain , Template = "*" (3) ] )
For DECnet-Plus for OpenVMS, Digital recommends that you rerun NET$CONFIGURE.COM to revise the standard search path NCL script (NET$SEARCHPATH_STARTUP.NCL) whenever it is necessary to reorder access to the name services on the node. To modify the standard search path startup script, run NET$CONFIGURE.COM and use Option 2 (Change node name/namespace name).
Note
Whenever you directly edit an existing NET$SEARCHPATH_STARTUP.NCL script, or when you use NCL set commands to change the script (rather than changing the script by rerunning NET$CONFIGURE.COM), your edits are overwritten by any new NET$SEARCHPATH_STARTUP.NCL scripts you subsequently generate by rerunning NET$CONFIGURE.COM.
The name of the backtranslation directory that Session Control uses is .DNA_BackTranslation with the same nickname as the node name in the current namespace. If the node name is changed, Session Control tracks the change within the number of seconds specified by the address update interval Session Control attribute. See the backtranslation directory statusattribute under the session control entity for the current full name of the backtranslation directory used by Session Control.
The name of the node synonym directory that Session Control uses is .DNA_NodeSynonym with the nickname of the default namespace at the time that Session Control was first created.
{default-namespace}:.dna_nodesynonym
If you change the default namespace name without reconfiguring, you must set the name of the node synonym directory. (Section 5.1.6 describes how to change the default namespace name.) Set the node synonym directory with the node synonym directory characteristic attribute under the session control entity. For example:
ncl> set session control node synonym - _ncl> directory default-namespace:.dna_nodesynonym
In very large or widely distributed networks you can use multiple directories to store node synonym soft links, rather than the single default .DNA_NodeSynonym directory.
To use an alternate node synonym directory on an OpenVMS system, edit SYS$MANAGER:NET$LOGICALS.COM and add the following line:
$ define/system/exec decnet_migrate_dir_synonym ".synonym_dir_name"
The defined directory is then used by NET$CONFIGURE, decnet_register, and decnet_migrate.
The DECdns namespace is the total collection of names that one or more DECdns servers know about, look up, manage, and share. You define the default namespace name during configuration of a DECdns clerk. Then, unless a user specifies otherwise, DECdns always assumes a name is in the default namespace. Use the following NCL set command to change the default namespace:
ncl> set dns clerk default namespace {namespace-name}
Note that this command will affect all users of DECdns on the system, including the Session Control module. Therefore, Digital recommends that you do not use this command, but instead use the DECnet-Plus configuration procedure.
In general, to manage the namespace, use the DECdns Control Program SYS$SYSTEM:DNS$CONTROL.EXE.
For more information about managing the namespace, refer to the DECnet-Plus DECdns Management guide.
DECnet Phase V software includes the common directory interface (CDI) as an interface between DECnet Phase V Session Control and all the supported name services (local namespace, DECdns, DNS/BIND). CDI performs the necessary switching between the various name servic during lookups, enabling the use of multiple name services.
Prior to the addition of the CDI, the DECdns clerk was the primary interface between DECnet Session Control and DECdns servers or the local namespace. Now most all DECnet-related calls to DECdns (or to any other naming service) are first handled by CDI.
The DECdns clerk receives requests for name/address information from client applications and looks up the requested information on the appropriate DECdns server or in the local namespace. The DECdns clerk caches (saves) pointers to DECdns servers discovered during these lookups. This saves the clerk from repeatedly connecting to a server for the same information. For lookups involving applications such as DECmcc and DFS, the DECdns clerk caches results of lookups. Caching improves performance and reduces network traffic.
On OpenVMS systems, CDI uses an in-memory naming cache to improve performance of name and address resolution for the supported name services. DECnet-Plus for OpenVMS requests CDI directly for name and address resolution. DECnet-Plus uses CDI for looking up information from all three name services: local namespace, DECdns, and DNS/BIND.
The DECdns clerk cache still exists. When CDI calls DECdns for node name information, DECdns searches the clerk cache to determine where to look up the requested information. DECdns continues to use the clerk cache to determine the location of servers in the DECdns namespace. DECnet-Plus for OpenVMS uses the DECdns clerk to parse the special namespace nicknames LOCAL: and DOMAIN:. These nicknames in a node full name indicate to DECnet-Plus the name service where the name and addressing information is stored. Note that DECdns clerks do not cache DECnet names for any namespace. The clerk caches pointers to the servers where node names are stored.
The DECdns clerk cache continues to be used by applications other than DECnet-Plus that use DECdns directly, such as the Distributed File Service (DFS) application.
Using NCL commands, you can manage two CDI naming cache parameters, the checkpoint interval and the timeout period, and you can flush entries from the in-memory naming cache. Note that these parameters do not affect DECdns; they only affect CDI.
To ensure that the information contained in the naming cache is preserved across system reboots, DECnet periodically saves (or checkpoints) a snapshot of the in-memory naming cache to disk. At system startup, the naming cache can be populated with the entries most recently saved to disk. Note that this means the naming cache is read into memory only during DECnet startup. Keep this in mind if you are copying the cache to other nodes in the network for updates.
The following NCL command changes the frequency of this checkpoint operation from the default of once every 8 hours to once every 12 hours:
$ mcr ncl set session control naming cache checkpoint interval 12:00:00
One advantage of resetting the checkpoint interval is that you force a new checkpoint to be written within the next 15 minutes, even if a checkpoint is not due at that time.
You can use either the Common Trace Facility or the CDI$TRACE program to obtain naming trace information.
Use the following command to invoke the Common Trace Facility:
$ Trace Start "SESSION CDI *"
Including the CDI parameter restricts trace facility output to node name and address resolution messages.
Use the following command to run CDI$TRACE, a program located in SYS$SYSTEM:
$ run sys$system:cdi$trace
You can use the following procedure to redirect CDI$TRACE output to a file:
$ cdi$trace == "$cdi$trace"
$ cdi$trace trace.log
CDI$TRACE has known problems when run during a LAT terminal session (on an LT device). A workaround is to issue the DCL spawn command first.
The naming cache includes a mechanism to remove old cache entries. When a naming cache entry reaches a preset age, the entry times out, or expires, and is eliminated from the cache. On the first lookup request for an entry after it has timed out, when DECnet does not find the entry in the in-memory cache, DECnet will retrieve up-to-date information from the name service. In this way, cache entries are periodically refreshed to accurately reflect the current network environment.
The following NCL command changes the length of the timeout interval from the default of 30 days. For example, this command decreases the timeout interval to once every 5 days:
$ mcr ncl set session control naming cache timeout 5-00:00:00
The default timeout value of 30 days is suitable for most networks. However, for stable networks in which node names are rarely changed or swapped with other names, you can increase the value. The only benefit of keeping a lower value is that more space is freed in the cache as each timed-out entry is deleted.
Reducing the timeout value may result in the sudden loss of cached entries. Use the NCL flush command to remove specific entries, as explained below.
Digital recommends that you do not change a node name or swap names of nodes until after the naming cache timeout period has passed. This allows time for the out-of-date node and addressing information to be flushed from the cache.
Consider the following scenario. Node .mgmt.accnt is assigned address 4.234 and this name and address information is stored in the name service. After DECnet has looked up node .mgmt.accnt, it stores this node name and address combination (.mgmt.accnt and 4.234) in its in-memory cache. When node .mgmt.accnt is subsequently reassigned to address 4.235, the following events can occur:
However, if after node .mgmt.accnt is assigned a new address, .mgmt.accnt's old address, 4.234, is subsequently reassigned to node .mgmt.pers before the timeout period has elapsed, the following can occur:
To prevent this scenario, do either of the following:
$ mcr ncl flush session control naming cache entry "entry-name" $ mcr ncl flush session control naming cache entry "*"
The decnet_register tool simplifies and centralizes management of namespace information. It runs on both OpenVMS and Digital UNIX systems.
The decnet_register manage command assists with setting up and managing DECdns distributed namespaces by creating the required hierarchy of directories, setting and altering access rights to these directories, and enabling and disabling autoregistration.
This section explains how to use decnet_register to manage and register node names in a DECdns or local namespace. In particular, this section explains how to use decnet_register to perform the following distributed namespace tasks. For an alphabetical command reference, see Appendix E.
Note
Do not register nodes in the DECdns namespace that do not use DECnet. Only DECnet-to-DECnet applications use node-name objects in the DECdns namespace. OSI applications use their own private naming databases, DNS/BIND, or X.500.The decnet_register tool does not manage information in DNS/BIND.
To invoke decnet_register, enter the run command:
$ run sys$system:decnet_register
You can also invoke decnet_register using a foreign command symbol:
$ netreg :== $sys$system:decnet_register $ netreg
Once invoked, decnet_register continues to accept commands until you enter the exit command.
If you have defined a foreign command symbol, you can include a decnet_register command on the invocation command line as follows:
% netreg show node mynode
With this command line, decnet_register executes the included command and immediately exits.
When you invoke decnet_register from a video terminal, decnet_register starts in forms mode by default. When you invoke decnet_register from a command procedure or from a hardcopy terminal, decnet_register starts in command mode by default. You can change this default behavior permanently by defining a logical name or for a single invocation only by using the /c and /f qualifiers on the command line.
To change the default behavior permanently, define one of the following logical names:
Note that only one logical name takes effect at a time. If you define both logical names, the last one defined takes effect.
To change the default behavior for the current invocation only, use one of the following switches:
Note
The decnet_register tool is not supported on a system booted with minimum startup.
The decnet_register tool has both command line and forms interfaces. When invoked from a video terminal, decnet_register is by default a forms-driven tool. You select a task and decnet_register prompts you for the information the task requires. The command line interface for decnet_register includes help information for all the tool's commands.
The following example shows the decnet_register main menu form.
DECNET_REGISTER - Manage node registrations in network directory services Use Return, Ctrl-N, and Ctrl-P to move between input fields Use "?" to obtain help, Ctrl-Z to cancel 1 - Show information about registered node names 2 - Register or modify node names 3 - Update registered node towers using information from the nodes 4 - Rename a registered node name 5 - Repair the synonym and address links for registered node names 6 - Deregister node names 7 - Export node names to a data file 8 - Import node names from a data file 9 - Set preferences and network values 10 - Manage the directory service 11 - Spawn to DCL * Option (use Ctrl-Z to exit):
To select a task, type the appropriate number and press Return. You can cancel any task and return to this main menu by pressing Ctrl/Z.
To perform certain tasks discussed in this chapter, you need access rights. For more information about the access rights, refer to the DECnet-Plus DECdns Management guide which also contains complete information about DECdns and the namespace and provides detailed namespace planning information. Note that when you use decnet_register to manage DECdns, these access rights are stored in the DECdns namespace rather than locally on your system. So, you might not be able to use certain decnet_register commands, even if you are logged in as a system account user.
Note
If the namespace has not yet been created on your network or its root directory cannot be read from your node, then decnet_register indicates this in a message. You cannot proceed if you cannot access the namespace. See your namespace manager to find out why the existing namespace is unavailable. If the namespace has not been created yet, the namespace manager should create a namespace following the instructions in the documentation for the platform on which you are using DECdns as well as in the DECnet-Plus DECdns Management.
Initializing the namespace consists of creating a backtranslation directory (commonly called .DNA_BackTranslation), a node synonym directory (commonly called .DNA_NodeSynonym), and the required DECdts directory (.DTSS_GlobalTimeServers). Some DECnet features do not work properly unless these directories exist; for example, you cannot use Phase IV node names if the node synonym directory (.DNA_NodeSynonym or equivalent) is not available.
Note
Digital strongly recommends that you create these directories immediately. See Section 5.3.12 for a description of these directories and the initialization procedure.
As part of your job as a network manager, you might at times need to review the information registered for a node in the namespace. This information includes the node's address tower and, for the DECdns namespace, the names of the synonym and address-to-name backtranslation soft links.
To view this information, select Option 1 at the decnet_register main menu and respond to the prompts as they appear, one by one. Press the appropriate control key sequence for your platform to exit. Output is similar to the following example:
Show registered node information Use Return, Ctrl-N, and Ctrl-P to move between input fields Use "?" to obtain help, Ctrl-Z to cancel Specify the directory service as LocalFile, DECdns, or PhaseIV * Directory service: Specify the node to show using an explicit or wildcard name, an NSAP, or a Phase IV synonym or address. * Node name or address: Specify the information to display as either brief, full, or names. Specify the output file name (a blank line indicates the terminal). * Display format: * Output file: Press Return to show the node values, Ctrl-Z to cancel
PROFILE_VMS_003.HTML OSSG Documentation 2-DEC-1996 12:34:50.44
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.