1 MAIN_MENU ! 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. ! ! Under MAIN_MENU 2 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. ! ! ! Under MAIN_MENU 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. ! ! Under MAIN_MENU 2 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. ! ! Under MAIN_MENU / Initialization_Command_File 3 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. ! ! Under MAIN_MENU / Initialization_Command_File 3 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. ! ! Under MAIN_MENU 2 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. ! ! Under MAIN_MENU 2 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. ! ! Under MAIN_MENU 2 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 - ::-:: OSI format - + Where: - The AFI (Authority and Format Identifier) - The IDI (Initial Domain Identifier) - The prefix portion of the DSP (Domain Specific Part) - The local area portion of the DSP - The node id portion of the DSP - 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) ! ! Under MAIN_MENU 2 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: . .+ Where: - The area number, from 1 to 63 - The node id within the area, from 1 to 1023 - 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) ! ! Under MAIN_MENU 2 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 - :: OSI format - + Where: - The AFI (Authority and Format Identifier) - The IDI (Initial Domain Identifier) - 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. ! ! Under MAIN_MENU 2 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. ! ! Under MAIN_MENU / Names_and_Directories 3 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. ! ! Under MAIN_MENU / Names_and_Directories / Node_Names ! ! Under MAIN_MENU / Names_and_Directories / Node_Names 4 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: :... Where: : is the name of the namespace for this naming hierarchy. For example, this could represent the organization. . 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. . 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 ! ! Under MAIN_MENU / Names_and_Directories / Node_Names ! ! Under MAIN_MENU / Names_and_Directories / Node_Names 4 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 ! ! Under MAIN_MENU / Names_and_Directories / Node_Names 4 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. ! ! Under MAIN_MENU / Names_and_Directories 3 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. ! ! Under MAIN_MENU / Names_and_Directories / Reverse_Address_Mapping ! ! Under MAIN_MENU / Names_and_Directories / Reverse_Address_Mapping 4 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... Where: is the value of the binary NET up to the local area field. is the value of the local area field in the binary NET. 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. ! ! Under MAIN_MENU / Names_and_Directories / Reverse_Address_Mapping ! ! Under MAIN_MENU / Names_and_Directories / Reverse_Address_Mapping 4 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. ! ! Under MAIN_MENU / Names_and_Directories / Reverse_Address_Mapping 4 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. ! ! Under MAIN_MENU / Names_and_Directories 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. ! ! Under MAIN_MENU / Names_and_Directories / Synonym_Mapping ! ! Under MAIN_MENU / Names_and_Directories / Synonym_Mapping 4 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. Where: is the Phase IV synonym name. For example, for the synonym "MYSYN", the fully specified soft link name is: .DNA_NodeSynonym.MYSYN ! ! Under MAIN_MENU / Names_and_Directories / Synonym_Mapping ! ! Under MAIN_MENU / Names_and_Directories / Synonym_Mapping 4 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. ! ! Under MAIN_MENU / Names_and_Directories / Synonym_Mapping 4 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. ! ! Under MAIN_MENU 2 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. : 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. ! ! Under MAIN_MENU / Export_File 3 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). =Type DECnet Node =Version 1 These lines specify the file contents and version. The values shown above are the only currently recognized values. ! ! Under MAIN_MENU / Export_File 3 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). =All Address Prefix ??? =LocalFile Name Template ???* =DECdns Name Template ???:.???.* =DECdns Synonym Directory .??? =DECdns Reverse Address Directory .??? =PhaseIV Name Template * 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. ! ! Under MAIN_MENU / Export_File 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} ! ! ! Under MAIN_MENU / Export_File / Node_Registration_Information 4 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". ! ! ! Under MAIN_MENU / Export_File / Node_Registration_Information 4 Address_Tower_Field ! This field indicates the node address. This can be specified using either Phase IV format or NSAP format. Phase IV format: . .+ DNA NSAP format: ::-:: OSI NSAP format: + See PHASE_IV_ADDRESSES and NSAP_ADDRESSES for more details. ! ! Under MAIN_MENU / Export_File / Node_Registration_Information 4 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} !