The DECNET_REGISTER utility provides network managers with functions to help manage node names in the directory service or services used within the network. - Register node names, synonyms, and addresses in a directory service - Modify a node registration's synonym or addresses - Add addresses to a node registration - Remove addresses from a node registration - Show a node registration and verify its internal consistency - Export node registration data from a directory service to a text file - Import node registration data from a text file into a directory service - Update a node's registered address information from the node itself - Rename a registered node in a directory service - Repair the synonym and address mapping links for registered nodes - Deregister a node from a directory service The supported directory services are: Local Naming Database DECdns Phase IV Database To obtain help on how to answer the questions in any form, enter a question mark (?) to any of the prompts in that form.
1 – Invocation
The DECNET_REGISTER utility is normally invoked using the RUN command.
It can also be invoked using a foreign command symbol. For example:
$ RUN SYS$SYSTEM:DECNET_REGISTER !Invoke the utility
$ NETREG :== $SYS$SYSTEM:DECNET_REGISTER !Foreign command symbol
$ NETREG !Invoke the utility
If a foreign command symbol is used, a command line can be passed directly
to DECNET_REGISTER on the invocation command line. For example:
$ NETREG SHOW NODE MyNode
If the utility is invoked by a foreign command symbol with a command line,
as shown above, it executes the command and exits after the command is
complete. If not, it brings the main menu up on the screen and starts
accepting function requests.
2 – Termination
To exit, press the Ctrl/Z key combination when in the main menu. If a command was specified on the invocation command line, the utility exits immediately after the command has been processed.
3 – Initialization Command File
On startup, the DECNET_REGISTER utility always attempts to execute an initialization command file if one is present. This is most useful for pre-setting the values in the preferences form to values other than the normal defaults.
3.1 – File name
DECNET_REGISTER checks for an initialization file using a default
name of:
SYS$LOGIN:DECNET_REGISTER.INI
If this file is found, it is automatically executed as a command file
containing a series of DECNET_REGISTER commands. If a different file
name is to be used, specify the file name using the logical definition:
$ DEFINE DECNET_REGISTER_INIT initialization-file-name
If this logical definition exists, #(NETREG_NAME) uses the
specified file name, rather than the default file name.
3.2 – Commands
The most useful commands to place in an initialization file are:
SET DEFAULT DIRECTORY_SERVICE dir-service
This sets the default directory service, where dir-service
can be either LOCAL, DECDNS, or PHASEIV.
SET DEFAULT DISPLAY_MODE display-mode
This sets the default show information display mode, where
display-mode can be either BRIEF, FULL, or NAMES.
SET DEFAULT NSAP_FORMAT format
This sets the default NSAP display format, where format
can be either DNA or OSI.
SET DEFAULT PHASEIV_PREFIX addr-prefix
This sets the default AFI, IDI, and preDSP to use when
constructing an NSAP from a Phase IV address. See the
MAIN_MENU PHASE_IV_PREFIXES topic for details about
Phase IV prefix values.
SET DEFAULT REVERSE_DIRECTORY rev-dir-name
This sets the default base directory or name entry to
use for the reverse address mapping links to the node
name (also called the back translation links). See the
MAIN_MENU NAMES_AND_DIRECTORIES REVERSE_ADDRESS_MAPPING
topic for more information.
SET DEFAULT SYNONYM_DIRECTORY syn-dir-name
This sets the default base directory or name entry to
use for the synonym mapping link to the node name. See
the MAIN_MENU NAMES_AND_DIRECTORIES SYNONYM_MAPPING
topic for more information.
For more information on using commands, invoke DECNET_REGISTER in
command line interface mode, and enter the HELP command. See the
MAIN_MENU iNTERFACE_MODES topic for information on entering command
line mode.
4 – Interface Modes
After DECNET_REGISTER is invoked, and after it has executed the
initialization command file (if any), it enters either forms
mode or command line mode.
Forms mode is used if the utility is invoked from a video terminal.
Command line mode is used if the utility is invoked from a command
file or from a hardcopy terminal.
The DECNET_REGISTER utility can be forced to always run in forms mode
or command line mode by using one of the logical definitions:
$ DEFINE DECNET_REGISTER_FORMS 1 !Force the use of forms
$ DEFINE DECNET_REGISTER_COMMANDS 1 !Force the use of command lines
If either of these is defined, DECNET_REGISTER uses the indicated
interface mode, regardless of how it is invoked.
The DECNET_REGISTER utility can also be forced to run in forms mode or
command line mode by supplying one of the following arguments on
the invocation command line:
$ NETREG /F !Force the use of forms
$ NETREG /C !Force the use of command lines
To use these arguments, DECNET_REGISTER must be invoked using a foreign
command symbol.
If supplied, these arguments override both the I/O mode and the
logical definitions.
5 – Entering Information
When entering information to a prompt:
- If entering a keyword, such as the directory service type, the keyword
can be entered using either upper or lower case, and can generally be
abbreviated to three, or sometimes fewer, characters.
- If entering user-supplied information, such as node names, enter the
string with no abbreviations. Some information, such as node names in
particular, must be entered in the appropriate case.
- Entering a question mark (?) to any prompt in a form provides help
information on that form, with sub-topics for the various fields in
that form.
6 – NSAP Addresses
NSAP addresses are used when registering or modifying node information.
They can also be used when specifying nodes to show, export, or
deregister.
The format for an NSAP address is either:
DNA format - <afi>:<idi>:<predsp>-<locarea>:<nodeid>:<nsel>
OSI format - <afi><idi>+<predsp><locarea><nodeid><nsel>
Where:
<afi> - The AFI (Authority and Format Identifier)
<idi> - The IDI (Initial Domain Identifier)
<predsp> - The prefix portion of the DSP (Domain Specific Part)
<locarea> - The local area portion of the DSP
<nodeid> - The node id portion of the DSP
<nsel> - The N-Sel (Network Selector) portion of the DSP
Each address field contains:
AFI 2 decimal digits
IDI some number of decimal digits, determined by the AFI
PreDSP some number of hex digits, determined by the AFI
Local area 4 hexadecimal digits
Node id 12 hexadecimal digits
N-Sel 2 hexadecimal digits
When using DNA format NSAPs, the preDSP, local area, and node id can
contain embedded hyphens ("-") to improve readability. Also, leading
zeros in the local area and node id fields can be dropped. For
example, the following two addresses are equivalent.
39:840:0001:AA-00-04-00-05-04:20
39:840:1:AA0004000504:21
When using OSI format NSAPs, embedded hyphens are not allowed, and
leading zeros cannot be dropped in any field. For example:
39840+0001AA000400050421
An N-Sel of "20" specifies the use of the DECnet Phase IV NSP
transport. Any other N-Sel value (such as "21") indicates the
use of the OSI Transport Class 4 protocol (TP4).
If used when indicating nodes to show, export, or deregister, wildcards
(indicated by asterisks) can be used to indicate multiple nodes. Either
the node id or the local area plus node id can be wildcarded. When using
a wildcard, do not specify the N-Sel, For example:
39:840:56A1-0001:* (all nodes in area 39:840:8056A1-0001)
39:840:56A1* (all nodes in all local areas under 39:840:56A1)
7 – Phase IV Addresses
Phase IV addresses are used when registering or modifying node
information. They can also be used when specifying nodes to show,
export, or deregister.
The format for a Phase IV address is either:
<area>.<nodeid>
<area>.<nodeid>+<prefix>
Where:
<area> - The area number, from 1 to 63
<nodeid> - The node id within the area, from 1 to 1023
<prefix> - The optional Phase IV prefix
For example:
1.5
1.5+39:840:
When a Phase IV format address is specified, it is combined with the
Phase IV prefix value to create an NSAP. This Phase IV prefix value
consists of the AFI, IDI, and preDSP fields of the NSAP. If the
Phase IV prefix is not specified with the Phase IV address, the value
set in the preferences form is used.
If a Phase IV address is used when indicating the nodes to show, export,
or deregister, wildcards (indicated by asterisks) can be used to
indicate multiple nodes. Either the node id or the area plus node
id can be wildcarded. For example:
1.* (all nodes in area 1)
*.* (all nodes in all areas)
8 – Phase IV Prefixes
A Phase IV prefix is used to convert a Phase IV address to an NSAP. It
consists of the AFI, IDI, and preDSP fields of the NSAP. The format is
either of:
DNA format - <afi>:<idi>:<predsp>
OSI format - <afi><idi>+<predsp>
Where:
<afi> - The AFI (Authority and Format Identifier)
<idi> - The IDI (Initial Domain Identifier)
<predsp> - The prefix portion of the DSP (Domain Specific Part)
Each address field contains:
AFI 2 decimal digits
IDI some number of decimal digits, determined by the AFI
PreDSP some number of hex digits, determined by the AFI
A Phase IV prefix can be specified for an individual Phase IV address
by adding it to the end of the address. For example:
1.5+39:840:
A default Phase IV prefix can be specified for all Phase IV addresses
using the preferences form.
The local area and node id values are built from the Phase IV address,
and the N-Sel value is generally "20" (for NSP), unless the Phase IV
prefix is being applied to an address tower that specifies the use of
TP4.
9 – Names and Directories
Node names are used to maintain node addressing information in the directory service, allowing addressing information to be kept in a global repository. For those directory services that support hierarchical naming, names are generally collected into groups using directories. Three types of directories are used for maintaining node information in a directory service. These are: Node name directories, containing node names that hold node information Reverse address mapping directories, used to map addresses to names Synonym mapping directory, used to map Phase IV synonyms to names The names and directories are described in the sub-topics.
9.1 – Node Names
Node names contain addressing data that is used when an application on one node needs to connect to an application on another named node. These names must be unique within the directory service. Some directory services support hierarchical naming. The names at the various levels of the hierarchy, except for the lowest level, are commonly referred to as "directories". The names at the lowest level identify the specific node within that part of the hierarchy, and contain the node's addressing information. For these directory services, it is the entire hierarchical name that must be unique.
9.1.1 – DECdns
This is a global directory service, where names are assigned within a
naming hierarchy. The entire name, including all of its hierarchical
levels, makes up the "full name". One possible format for a full name
is:
<ns>:.<dir>.<dir>.<node-name>
Where:
<ns>: is the name of the namespace for this naming hierarchy.
For example, this could represent the organization.
.<dir> is some directory name used to break the namespace down
into smaller, more manageable segments. For example,
this could represent an organization, an organizational
unit, or a location within an organization. There can
be as many levels of directory as needed.
.<node-name> is the terminating name for some node.
The actual name structure can be defined to suit the name usage of
the organization. If the above structure is used, an example of a
complete full name might be:
MYCO:.TOPEKA.MYNODE
9.1.2 – Local
The Local Naming Database uses flat naming, rather than hierarchical naming. Names can consist of any text string. Because long names are allowed, up to 100 characters for any name, a naming hierarchy can be simulated by using common name prefixes for related names. The Local Naming Database is private to a particular node or cluster. As such, it must be manually kept up to date on all nodes if they are to share the same set of names. This can be done by exporting the contents of a master copy of the Local Naming Database to a text file, copying the text file to other nodes as required, and importing the text file into the Local Naming Database for each such node. An example of a Local Naming Database name might be: TOPEKA.MYNODE
9.1.3 – Phase IV
The Phase IV Database uses flat naming, rather than hierarchical naming. Names can consist of up to 6 letters (A to Z) and decimal digits (0 to 9), with at least one letter. The Phase IV Database is private to a particular node or cluster. As such, it must be manually kept up to date on all nodes if they are to share the same set of names. This can be done by exporting the contents of a master copy of the Phase IV Database to a text file, copying the text file to other nodes as required, and importing the text file into the Phase IV Database for each such node. An example of a Phase IV Database name might be: MYNODE The Phase IV Database is supported primarily to allow the simple migration from DECnet Phase IV to DECnet-Plus and some other directory service.
9.2 – Reverse Address Mapping
Reverse address mapping allows a node name to be determined from an address (specifically from an NET). For directory services that support hierarchical naming, this is done by setting up directories and links within those directories, based on the NETs of the nodes in the network. Each link then points to the node name associated with the indicated NET.
9.2.1 – DECdns
Soft link names are used to map NETs to their respective node names.
The normal default value for the reverse address mapping directory in
the DECdns directory service is:
.DNA_BackTranslation
The default directory name can be changed using the preferences form.
There are two more levels of directory under this top level directory,
followed by the actual soft link name. The name structure is:
.DNA_BackTranslation.<prefix>.<locarea>.<nodeid>
Where:
<prefix> is the value of the binary NET up to the local area
field.
<locarea> is the value of the local area field in the binary NET.
<nodeid> is the value of the node id field in the binary NET.
For example, for an NET of "39:840:00-01:AA-00-04-00-05-04:20", the
fully specified soft link name is:
.DNA_BackTranslation.%X39840F.%X0001.%XAA0004000504
The "F" in the second level directory is a padding value that is
present in the binary form of the NSAP value, though it is not
visible in the user representation.
9.2.2 – Local
The Local Naming Database does not make use of reverse address mapping for mapping addresses to names. Instead, addresses are treated as keys within the indexed Local Database file.
9.2.3 – Phase IV
The Phase IV Database does not make use of reverse address mapping for mapping addresses to names. Instead, addresses are treated as keys within the indexed Phase IV Database file.
9.3 – Synonym Mapping
Synonym mapping allows a node name to be determined from a Phase IV synonym assigned to that node. For directory services that support hierarchical naming, this is done by setting up directories and links within those directories, based on the synonyms assigned to the nodes in the network. Each link then points to the node name associated with the indicated synonym.
9.3.1 – DECdns
Soft link names are used to map synonyms to their respective node names. The normal default value for the synonym mapping directory in the DECdns directory service is: .DNA_NodeSynonym The default directory name can be changed using the preferences form. This directory contains the actual soft link names. The name structure is: .DNA_NodeSynonym.<synonym> Where: <synonym> is the Phase IV synonym name. For example, for the synonym "MYSYN", the fully specified soft link name is: .DNA_NodeSynonym.MYSYN
9.3.2 – Local
The Local Naming Database does not make use of synonym mapping for mapping Phase IV synonyms to names. Instead, the Phase IV synonyms are treated as keys within the indexed Local Database file.
9.3.3 – Phase IV
The Phase IV Database does not make use of synonym mapping for mapping Phase IV synonyms to names. This is because Phase IV synonym names are the only names allowed in the Phase IV Database.
10 – Export File
An export file is created using the export function. This is a text
file containing node registration information read from some directory
service.
This file can be used as input to the import function to move node
information from one directory service to another, or to verify the
information in one or more directory services. It can also be edited
to change any information (such as the NSAP IDP used by the network)
and used to bulk modify the contents of the directory service.
The file contains the following sections.
<type-and-version>
<directory-service-information>
<node-registration-information>
<directory-service-information>
<node-registration-information>
:
<directory-service-information>
<node-registration-information>
The directory service and node registration information sections are
repeated as often as necessary to ensure that the appropriate directory
service information is associated with the correct node registration
information.
10.1 – Type and Version
This section contains the following information. Lines beginning with an equals sign (=) contain control information (the equals sign must be in the first character position, or it is treated as the first character of a node name). These lines specify the file contents and version. The values shown above are the only currently recognized values.
10.2 – Directory Service Information
This section contains the following information. Lines beginning with
an equals sign (=) contain control information (the equals sign must be
in the first character position, or it is treated as the first character
of a node name).
The information specified in this section provides default values for
use when importing into the indicated directory service ("All" indicates
information that is used for all directory services).
Lines from this section can be repeated further down in the file, to
change the supplied information. For example, this is useful when a
file contains node information that is to be registered into several
directories (specified using the Name Template value).
Initially, the value for each piece of information is set to "unknown",
by writing question marks (???) to the file. If the export function can
determine an appropriate value for any of these, it places that value in
the file instead. This is possible only for the directory service you
are exporting from.
When the file is read by the import function, only those lines intended
for the target directory service are examined. All others are ignored,
and can contain invalid values without causing an error. Also, each
line in this section has an equivalent import function form field. If
a value is specified in field, then the value contained in the file for
that field is ignored, and can contain an invalid value without causing
an error.
Enter a question mark (?) to the import form for an explanation of each
field value.
10.3 – Node Registration Information
This section contains the node registration information. These lines
must not begin with an equals sign (=) in the first character position.
If a node uses an equals sign as the first character in its name, indent
the name by at least one space.
The format for a node information line is:
name synonym {TOWER=tower, TOWER=tower, ..., TOWER=tower}
Where:
name The terminating part of the name for the node. This is
generally the part of the name that is the same regardless
of the directory service. For example, "MailHub" is the
terminating name for the following:
Local: MailHub
DECdns: MyCo:.Sales.MailHub
When importing into the Phase IV Database, this is ignored
and the synonym field used used, if a synonym is defined.
If a synonym is not defined, and the name is not Phase IV
compatible, an error results.
synonym The Phase IV synonym for the node, if any. This is optional.
tower A tower value for the node. Each address tower in the set
has the format:
transport/address
Fields can be omitted from left to right. Omitted fields
assume a default value. The format for an individual tower
is given in the sub-topics listed below.
All directory services except the Phase IV database support
multiple towers. If importing into the Phase IV Database,
the first Phase IV compatible tower is used.
The braces surrounding the list of towers are required.
For example:
MailHub MLHUB {Tower=12.2, Tower=37:840:0001:08-00-2B-0D-E9-B1:21}
10.3.1 – Transport Tower Field
This field indicates the Transport type. This can be either:
TP4 - OSI Transport Class 4
NSP - DECnet Phase IV Network Services Protocol
If TP4 is specified, it can be followed by an optional T-Sel value as
a series of hexadecimal digits after an equals sign. If an explicit
T-Sel value is not specified, the DECnet default of "TP4=DEC0" is
assumed. For example:
TP4=AB12 - The T-Sel is set to "AB12"
TP4=AB1 - The T-Sel is "AB10" (number of digits must be even)
TP4 - The T-Sel is assumed to be "DEC0"
If a transport type is not specified, the default depends on the
address.
NSP is used if the address is specified using Phase IV format,
or is an NSAP with an N-Sel value of "20".
TP4 is used if the address is an NSAP with an N-Sel value other
than "20".
10.3.2 – Address Tower Field
This field indicates the node address. This can be specified using
either Phase IV format or NSAP format.
Phase IV format: <area>.<nodeid>
<area>.<nodeid>+<prefix>
DNA NSAP format: <afi>:<idi>:<predsp>-<locarea>:<nodeid>:<nsel>
OSI NSAP format: <afi><idi>+<predsp><locarea><nodeid><nsel>
See PHASE_IV_ADDRESSES and NSAP_ADDRESSES for more details.
10.3.3 – Example Towers
Assuming that the Phase IV address prefix value is "49::", some
examples of address towers are:
Abbreviation: 1.5
Fully Specified: NSP/49::01:AA0004000504:20
Abbreviation: 39:840:01:AA0004000504:20
Fully Specified: NSP/39:840:01:AA0004000504:20
Abbreviation: 39:840:01:AA0004000504:21
Fully Specified: TP4=DEC0/39:840:01:AA0004000504:21
Abbreviation: TP4/39:840:01:AA0004000504:21
Fully Specified: TP4=DEC0/39:840:01:AA0004000504:21
Examples of address towers using normal default values for both a
DECnet Phase IV node and a DECnet-Plus node might be:
TOWERS={1.5}
TOWERS={2.54, 39:840:01:AA0004000504:21}