The following example shows how to convert a single NCP command to its closest equivalent.

decnet_migrate> convert command "ncp-command"

To convert to NCL, replace ncp-command with the NCP command exactly as if it were entered at the NCP> prompt and enclose the command in quotation marks. After you execute the command, the output of the convert command appears on your terminal.

For more information about the convert command, see Appendix C, decnet_migrate Commands.

The following example shows how to convert NCP commands contained within a DCL command procedure to their closest NCL command equivalent within the procedure.

decnet_migrate> convert dcl_file input_file [to output_file]

For more information about the convert dcl_file command, see Appendix C, decnet_migrate Commands.

The following example shows how to convert NCP commands contained within an NCP command procedure to their closest NCL command equivalent within the procedure.

decnet_migrate> convert ncp_file input_file [to output_file]

For more information about the convert ncp_file command, see Appendix C, decnet_migrate Commands.

The following example shows how to invoke the Language-Sensitive Editor (LSE) with the edit command. You automatically set up LSE by specifying .COM or .NCL file extensions for the NCL command file that you are editing.

The initial placeholder used to start expanding a command is {NCL_SCRIPT}.

decnet_migrate> edit file-name

For more information about the edit command, see Appendix C, decnet_migrate Commands.

To display information about the search path maintained for forward translation or naming (node name to address translation), use the following NCL command (descriptions of the display follow the example):

$ ncl show session control naming search path
Node 0 Session Control
AT 2019-03-19-10:26:03.809-05:00I49.474
Characteristics
   Naming Search Path =
    (
      [
        Directory Service = Local , 
        Template = "*"
      ] ,
      [
        Directory Service = Local , 
        Template = "local:.lky.*"
      ] ,
      [
        Directory Service = Local , 
        Template = "LOCAL:*"
      ] ,
      [
        Directory Service = DECdns , 
        Template = "*"
      ] ,
      [
        Directory Service = Domain , 
        Template = "*"
      ]
    )

Note that each name 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 NCL command (descriptions of the display follow the example):

$ ncl show session control backtranslation search path
Node 0 Session Control
AT 2019-03-19-11:00:57.490-05:00I49.712
Characteristics
   Backtranslation Search Path =
    (
      [
        Directory Service = Local , 
        Template = "*"
      ] ,
      [
        Directory Service = DECdns ,
        Template = "local:.DNA_BackTranslation" 
      ] ,
      [
        Directory Service = Domain ,
        Template = "*" 
      ]
    )

VSI 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).

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 Session Control’s address update interval attribute. See the backtranslation directory status attribute under the session control entity for the current full name of the backtranslation directory used by Session Control.

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.

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.

VSI 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:

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 has known problems when run during a LAT terminal session (on an LT device). A workaround is to issue the DCL spawn command first.

You can use a logical name table (CDI$SYSTEM_TABLE) to define node synonyms. You should use the following commands to create and examine logical names in the CDI$SYSTEM_TABLE logical name table. In the following command examples, the node bks.pub.dec.com has the synonym bks.

To define the CDI$SYSTEM_TABLE logical name table, enter the following command:

$ create/name_table/exec/parent=lnm$system_directory cdi$system_table

To define a synonym, enter the following command:

$ define/table=cdi$system_table bks bks.pub.dec.com

To examine a synonym, enter the following command:

$ show logical/table=cdi$system_table bks

The system displays the synonym information:

$ "bks.pub.dec.com" = "bks" (cdi$system_table)

SYSNAM system privileges are required.

The common directory interface (CDI) has been enhanced to resolve an IP fully- qualified node name to a Phase IV-style node synonym. CDI resolves the fully- qualified node name to the IP short name. For example, the fully-qualified name mynode.cmp.com resolves to the Phase IV-style node synonym mynode. Normally, CDI returns the synonym only if the following conditions are satisfied:

If the preceding conditions are not met, or if the node is using another synonym (for example, the node this.vsi.com is using the synonym that), you must make an entry for the node in the TCP/IP software’s local hosts database.

If you are using VSI TCP/IP Services for OpenVMS software, you would need to enter a command similar to the following:

$ tcpip set host mynodelong.cmp.com/address=100.50.75.20/alias=mynode

To view what was in the CDI cache the last time a CDI checkpoint was taken, issue the following command:

$ run sys$system:cdi_cache_dump

The dump utility first displays summary information about the cache file:

  CDI Cache Checkpoint file dumper
[Checkpoint filename = "SYS$SYSTEM:DECNET$CDI_CACHE.DAT;1"]
Reading file...
224926 bytes (of 4) loaded from checkpoint file
Computing checksum...
cache size (except checksum) (in words): 56231
Checksum correct
Cache checksum: file: C0E2F780, computed: C0E2F780
CDI cache successfully loaded from ckpt file...
  Cache id............. 950022
  Cache version........ 2.4
  cache_init_flag...... 1
  cache_size........... 211
  Cache Max Size....... 4096
  Cache Increments .... 40
  Total entries........ 211

Next, the dump utility displays each entry in the cache in most recently used (MRU) order (usually the local node, cluster alias, if present, and other cluster members are the first entries displayed):

*********************** Cache Entries (MRU order) *********************
- ptr - Dir s.name
Ent Svc off len Input name Synonym Fullname
0 2 9 6 VSI:.MA.ASHFLD ASHFLD VSI:.MA.ASHFLD 1
| tower 1: "DNA_NODE"/"SC3"/"TP4=DEC0"/NS+49+0018AA000400246021
| tower 2: "DNA_NODE"/"SC3"/"NSP"/NS+49+0018AA000400246020
| created: Fri Sep 17 18:10:35 2019
1 3 0 6 ASHFLD ASHFLD VSI:.MA.ASHFLD 1
| tower 1: "DNA_NODE"/"SC3"/"TP4=DEC0"/NS+49+0018AA000400246021
| tower 2: "DNA_NODE"/"SC3"/"NSP"/NS+49+0018AA000400246020
| tower 3: "DNA_NODE"/"SC2"/"TP4=DEC0"/IP+123.456.789.123
| created: Fri Sep 17 18:10:36 2019
2 3 0 5 WMASS WMASS VSI:.MA.WMASS 0
| tower 1: "DNA_NODE"/"SC2"/"NSP"/NS+49+0018AA000400246020
| tower 2: "DNA_NODE"/"SC2"/"TP4=DEC0"/IP+123.456.789.120
| created: Fri Sep 17 18:10:37 2019
3 3 0 6 IP$123.456.789.123 ASHFLD ASHFLD.MA.USA
| tower 1: "DNA_NODE"/"SC2"/"TP4=DEC0"/IP+123.456.789.123
| created: Fri Sep 17 18:10:37 2019
4 3 0 6 CONWAY CONWAY VSI:.MA.CONWAY 0
| tower 1: "DNA_NODE"/"SC2"/"NSP"/NS+49+0018AA000400246120
| tower 2: "DNA_NODE"/"SC2"/"TP4=DEC0"/IP+123.456.789.124
| created: Fri Sep 17 18:12:27 2019

The preceding example shows the entries for the local node ashfld under both its DECdns name and its node synonym. Next, is the entry for the cluster alias, wmass, followed by an entry for the IP address for the local node, IP$123.456.789.123. Finally, is an entry for another member of the cluster, conway.

The NET$LOCAL_CLOSE logical name controls whether the common directory interface (CDI) closes its local namespace database (normally, SYS$SYSTEM:NET$LOCAL_NAME_DATABASE.DAT) after each use. If CDI keeps the database open continuously, this can create problems (in the form of unwanted file merges) if the CDI database is moved to a disk other than SYS$SYSTEM: and that disk is a member of a shadow set.

If the NET$LOCAL_CLOSE logical name is defined with a value of 1, CDI closes the database after each use. The default is for the NET$LOCAL_CLOSE logical name to be undefined (that is, CDI keeps the local namespace database open continuously). See Section 6.3, “Defining Logical Names That Modify Network Operation” for information about how to define this logical name in the NET$LOGICALS.COM file.

Session Control bypasses the CDI cache when the existing cache entry causes a node unreachable condition. When the node unreachable condition is detected, Session Control makes a second call to CDI with an indication that CDI should bypass the cache and look up the name directly in the appropriate naming service. In addition, the new address is used to update the CDI cache for future lookups. Without this feature, if a node’s address changed and the CDI cache was not flushed to force the new address into the cache, CDI would return the stale address information to Session Control. Session Control would then return a node unreachable error to the caller.

Select Option 7 at the decnet_register main menu to create a text file that can be edited and contains the node information extracted from the name service. Press Ctrl/Z to cancel the export operation. Output is similar to the following example:

Export 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: LocalFile
Specify the node names to export using a wildcard name, NSAP, Phase IV
synonym, or Phase IV address.
* Node name or address: T*
Specify the file name to export data into.
* File name: export_nodes.txt
Press Return to export, Ctrl/Z to cancel
Exporting node name information using: T*
1) LOCAL:.TOYBOAT
2) LOCAL:.TOPAZ
3) LOCAL:.TROY
4) LOCAL:.TROUBLE

Select Option 8 at the decnet_register main menu to import the node information contained in a text file in to a name service. Press Ctrl/Z to cancel the import operation. Output is similar to the following example:

Import 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: LocalFile
Specify the file containing the data to import into the directory service.
Specify the error log file (if none, errors go to the terminal).
* Data file name: export_nodes.txt
* Error file name:
Specify the name template, with "*" where the node names should be inserted.
Specify the function as either update, register, modify, replace, deregister,
or verify.
* Template: *
Specify either update, register, modify, replace, deregister, or verify.
* Import function to perform: verify
Press Return to import, Ctrl/Z to cancel
Directory Service: Local name file
Verifying nodes listed in export_nodes.txt
1) TOYBOAT
2) TOPAZ
3) TROY
4) TROUBLE

DECnet-Plus includes a local namespace that replaces functionality previously provided by the LNO namespace, the DECdns Local Naming Option.

The decnet_register_lno tool translates an existing LNO text file into a new local namespace file.

Run decnet_register_lno with the following command:

$ mcr sys$system:decnet_register_lno

This tool is supplied for backward compatibility only. You must have an existing LNO text file to use this procedure.

Every DECdns namespace must be initialized for DECnet use at least once. This involves creating certain required namespace directories and the .DNA_Registrar access control group. The namespace is automatically initialized when the DECnet-Plus advanced configuration procedure creates the namespace.

Initialization creates the following directories:

The DECnet-Plus advanced configuration procedure also creates the access control group .DNA_Registrar. This access control group contains a list of network users with read, write, delete, test, and control access to all namespace objects, soft links, and directories created using decnet_register and decnet_register_decdns.

You can reinitialize the namespace for DECnet at any time; if the namespace directories already exist, the tool does not overwrite them. You need to reinitialize the namespace if, for example, a backtranslation directory was accidentally deleted.

To manage the DECdns namespace for DECnet-Plus, select Option 10 on the decnet_register main menu. The following messages and prompts appear, one by one. Enter decdns as the name service to manage. Enter ? for help. Press Ctrl/Z to cancel the operation and return to the decnet_register main menu. Output is similar to the following example:

Manage the node name storage aspects of a directory service
  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 DECdns.
* Directory Service: decdns

This function executes the "SYS$MANAGER:DECNET_REGISTER_DECDNS.COM" procedure
to perform management operations for the specified directory service.

This provides management of only those aspects of the directory service
that affect the storage of node name data.

Press Return to execute the procedure, Ctrl/Z to cancel

Starting the directory management procedure for the DECdns directory service

The procedure name is "@SYS$MANAGER:DECNET_REGISTER_DECDNS.COM"

DECnet-Plus node directory management for DECdns

Type a question mark (?) at any prompt to obtain help.
Press Ctrl/Z at any prompt to exit from the function.

Enter the name of the DECdns namespace to use.
The default is the system default namespace (bb_ns:).

* Namespace name: bb_ns:
Checking the bb_ns: namespace.

Choose one of the following functions by specifying its function number, or request help by typing HELP or a question mark (?).
  0 - Exit
  1 - Create a directory to hold registered node names
  2 - Create a directory for Phase IV Synonyms
  3 - Create a directory for address-to-name translations
  4 - Create the directory for the DECdts Time Services
  5 - Replicate a node name or synonym directory
  6 - Replicate an address-to-name translation directory
  7 - Create an access control group
  8 - Add members to an access control group
  9 - Remove members from an access control group
 10 - Show members of an access control group
 11 - Allow node autoregistration into a directory
 12 - Disallow node autoregistration into a directory
* Function to execute:

Your namespace will probably include many directories in which nodes are registered. Only the smallest networks should have all nodes registered in the root directory. For a more detailed discussion of this strategy, refer to the VSI DECnet-Plus for OpenVMS DECdns Management Guide.

To create a directory, select Option 10 at the decnet_register main menu. Enter decdns as the name service to manage and enter the name of the DECdns namespace to use. Then select Function 1 from the decnet_register_decdns function menu.

The following messages and prompts appear, one by one. Press Ctrl/Z to exit. Output is similar to the following example:

Create a directory to hold registered node names.
Press Ctrl/Z when done.
Enter the name of the node name directory to create.
* Directory name: .xyz
Enter the name of the clearinghouse for the master copy of the directory.
The default is the parent directory’s clearinghouse.
* Master replica clearinghouse: .mgv460_bb_ch
Enter the names of the access control groups to apply to the directory,
separated by commas.
* Access control groups [Def=DNA_Registrar]: .worldread_group
Creating the bb_ns:.xyz directory.
* Directory name:

For help answering the prompts, refer to the following:

Directory Name

Specify the full name for the directory to be created. This should not include a node or user name; for example, .Japan.Osaka.

Master Replica Clearinghouse

Specify the name of the clearinghouse where the master directory replicas should be created. Include any required directory information; for example, if your clearinghouse is in the root directory, you might type .MAS_CH.

If you do not specify a clearinghouse name, the parent directory’s clearinghouse is used (this is the DECdns default).

Access Control Groups

Enter the names of one or more DECdns access control groups that you want to include in the access control set for the directory (or directories) you create.

Using groups other than .DNA_Registrar allows you to control user access to the directories by listing those users who have read, write, delete, test, and control access to directories created using decnet_register_decdns. The specified access control groups are propagated to all node names registered in the created directories.

To specify more than one group name, separate them by commas.

The .DNA_Registrar group is included automatically in the list, whether or not you specify it.

The .DNA_Registrar group is created and populated by decnet_register_decdns. You are responsible for creating and populating any additional groups that you specify.

When you initialize the namespace for DECnet use, the DECnet-Plus configuration procedure creates backtranslation directories in the namespace for your network IDP and preDSP and for each network area that you specify.

If you add an IDP, preDSP, or network area to your network, you must create new backtranslation directories. Also, if you plan to change the network’s IDP or preDSP or a node’s area, first create new backtranslation directories.

To create a directory for a new DECnet area or IDP and preDSP, select Function 3 at the decnet_register_decdns function menu. The following messages and prompts appear, one by one. Press Ctrl/Z to exit. Output is similar to the following example:

Create a directory tree to hold address-to-name translation information.
Press Ctrl/Z when done.
Enter the name of the base address-to-name translation directory.
The current default is ".DNA_BackTranslation".
* Directory name: .DNA_BackTranslation
* Create the base directory [y/n, def=no]: y
Enter the name of the clearinghouse for the master copy of the directory.
The default is the parent directory’s clearinghouse.
* Master replica clearinghouse: major2:.nyc_ch
Enter the names of the access control groups to apply to the directory,
separated by commas.
Enter "." to reset the default to no access control groups.
The current default is ".dna_registrar".
* Access control groups: .dna_registrar
Creating the MAJOR2:.DNA_BackTranslation directory.
Enter the OSI area prefix, using either of the formats:
  <afi>:<idi>:<predsp>
  <afi><idi>+<predsp>
The current default is "49::"
* OSI area prefix: 49::
* Create the OSI area prefix directory [y/n, def=no]: y
Enter the name of the clearinghouse for the master copy of the directory.
The default is the parent directory’s clearinghouse.
* Master replica clearinghouse: major2:.nyc_ch
Enter the names of the access control groups to apply to the directory,
separated by commas.
Enter "." to reset the default to no access control groups.
The current default is ".dna_registrar".
* Access control groups: .dna_registrar
Creating the MAJOR2:.DNA_BackTranslation.%X49 directory.
Enter the local area, using either of the formats:
  A decimal value, from 1 to 63
  A hexadecimal value, from %x0001 to %xFFFE
It is assumed that local area child directory needs to be created. 
* Local area: 4
Enter the name of the clearinghouse for the master copy of the directory.
The default is the parent directory’s clearinghouse.
* Master replica clearinghouse: major2:.nyc_ch
Enter the names of the access control groups to apply to the directory,
separated by commas.
Enter "." to reset the default to no access control groups.
The current default is ".dna_registrar".
* Access control groups: .dna_registrar
Creating the MAJOR2:.DNA_BackTranslation.%X49.%X0004 directory.
Enter the local area, using either of the formats:
  A decimal value, from 1 to 63
  A hexadecimal value, from %x0001 to %xFFFE
It is assumed that local area child directory needs to be created.
* Local area:

For help answering the prompts, refer to the following:

Directory Name

Enter the name of the base backtranslation directory. This directory is commonly called .DNA_BackTranslation.

Enter YES to create the base backtranslation directory.

Master Replica Clearinghouse

Specify the name of the clearinghouse where the master directory replicas should be created. Include any required directory information; for example, if your clearinghouse is in the root directory, you might type .MAS_CH.

If you do not specify a clearinghouse name, the parent directory’s clearinghouse is used (this is the DECdns default).

Access Control Groups

Enter the names of one or more DECdns access control groups that you want to include in the access control set for the directory (or directories) you create. Using access control groups allows you to control user access to the directories by listing those users who have read, write, delete, test, and control access to directories created using decnet_register_decdns. The specified access control groups are propagated to all backtranslation soft links.

To specify more than one group name, separate them by commas. You are responsible for creating and populating any access control groups that you specify.

OSI Area Prefix

Specify the IDP (initial domain part) and preDSP (domain-specific part) value for the network. Specify either the default value (49::) or a value explicitly allocated for this network.

The format is afi:idi:predsp, where:

The default of 49:: means that both the idi and predsp are null. When the AFI equals 49::, the network is not to be interconnected with other OSI networks.

If you specify an IDP with an AFI other than 49::, that value appears as the default the next time the prompt appears.

Enter YES to create the OSI area prefix directory.

Local Area Value

Specify the local area to use within the IDP. This is either of the following:

This function creates an access control group (for example, the .DNA_Registrar access control group). The .DNA_Registrar access control group lists those users who have read, write, delete, test, and control access to all directories, objects, and soft links created using decnet_register. This group is automatically placed in the appropriate access control list for every node registered using decnet_register.

If necessary, you can also use the DECdns Control Program to add additional users and groups to individual access control lists.

To create an access control group, select Function 7 at the decnet_register_decdns function menu. The following messages and prompts appear, one by one. Press Ctrl/Z to exit. Output is similar to the following example:

Create an access control group.
Press CTRL/Z when done.
Enter the name of the access control group to create.
* Group name: .biggroup

Creating the .WorldRead_Group

When you create a new namespace on an DECdns name server, a group called .WorldRead_Group is also created. This allows you to easily change from one namespace to another. This group allows READ and TEST access to node objects. Therefore, a node that is moving from one namespace to another can read old information from its previous namespace and move any of this information to the new namespace.

When the .WorldRead_Group is created, it contains members LOCAL:.*... and <ns>:.*..., where <ns> is the name of your namespace. The person managing the namespace determines which systems (or namespaces) will get READ and TEST access to the namespace. The namespace manager needs to explicitly remove the members from the .WorldRead_Group if the namespace manager does not want these members included.

Using the .WorldRead_Group Access Control Group

When decnet_register_decdns is first used to set up the directories for a namespace, it checks for the existence of the .WorldRead_Group access control group. This group is generally used when multiple namespaces are in use in the network (for example, multiple DECdns namespaces, or one or more DECdns namespaces plus the local namespace). The members of this group are automatically granted read access to any created directories and objects, regardless of the namespace they are in.

Without the .WorldRead_Group access control group, users in other namespaces would need to be granted access to any appropriate directories and objects individually. Members in the .WorldRead_Group group are usually of the form namespace:.*..., where namespace is your namespace nickname (for example, ACME:.*...). Individuals can also be listed.

If decnet_register_decdns does not find the .WorldRead_Group access control group, it asks whether to create the group. If so, decnet_register_decdns does the following:

If the access control group is not created, decnet_register_decdns does not ask this question again on subsequent invocations. To have the question repeated on a later invocation, edit the decnet_register_decdns.defaults file in the login directory, find the line that contains def_worrea or nrg_def_worrea, and remove the appropriate namespace from the value list.

It is important to note that this group affects only those directories and objects created after the group. Any directories and objects created before the group must have the access control set (ACS) explicitly set using the DECdns Control Program.

This function adds new members to an access control group (for example, the .DNA_Registrar access control group). The .DNA_Registrar access control group lists those users who have read, write, delete, test, and control access to all directories, objects, and soft links created using decnet_register. This group is automatically placed in the appropriate access control list for every node registered using decnet_register.

If necessary, you can also use the DECdns Control Program to add additional users and groups to individual access control lists.

To add members to an access control group, select Function 8 at the decnet_register_decdns function menu. The following messages and prompts appear. Press Ctrl/Z to exit. Output is similar to the following example:

Add members to the access control group.
Press Ctrl/Z when done.
Enter the name of the access control group to use.
The current default is "bb_ns:.biggroup".
* Group name: .DNA_Registrar
Enter the name of the group member to add.
* Member name: .Japan.Osaka.Sales.Yamamoto
Adding member ".Japan.Osaka.Sales.Yamamoto" to ".DNA_Registrar"
* Member name: GCsale::Obrien
Adding member ".DNS$IV.GCsale.Obrien" to ".DNA_Registrar"
* Member:

For help answering the prompt for a member name, refer to the following:

Member Name

Enter the name of the member you want to add, using the format:

node_full_name.user_name

where:

You can also specify members using the format:

node_name::user_name

where:

The preceding example shows two members being added to the access control group, the first by specifying the node’s full name, and the second by specifying the Phase IV node name.

This function removes members from an access control group.

To perform this task, select Function 9 at the decnet_register_decdns function menu. The following messages and prompts appear. Press Ctrl/Z to exit. Output is similar to the following example:

Remove members from the access control group.
Press Ctrl/Z when finished.
Note that removing a nonexistent member does not result in an error. This
is also true for member names that are entered incorrectly. For this reason,
it is recommended that you show the group members are finishing the remove
function, to verify that all members were removed correctly.
Enter the name of the access control group to use.
The current default is "".
* Group name: .DNA_Registrar
Enter the name of the group member to remove, as displayed by the Show
Member function.
* Member name: .Japan.Osaka.Sales.Yamamoto
Removing member ".Japan.Osaka.Sales.Yamamoto" from ".DNA_Registrar".
* Member name: GCsale::Obrien
Removing member ".DNS$IV.GCsale.Obrien" from ".DNA_Registrar".
* Member name:

For help answering the prompt, refer to the following:

Member Name

Enter the name of the member you want to remove. Specify the member’s name exactly as it appears when you use Function 10 of decnet_register_decdns function menu to list the members of the access control group.

If the member’s name was added using the format node_name::user_name, you can use this same format to remove it.

To delete all members of the group, enter an asterisk (*) at the prompt. This command re-creates the .DNA_Registrar access control group.

The preceding example shows two members being removed from the access control group, the first using the name as shown by Function 10, and the second using the Phase IV format.

Showing Members of an Access Control Group

This function shows the members of an access control group. Specifying the .DNA_Registrar group lists those users who are allowed to manage node names in the namespace.

To perform this task, select Function 10 at the decnet_register_decdns function menu. The following messages and prompts appear. Press Ctrl/Z to exit. Output is similar to the following example:

Show members of the access control group.
Press Ctrl/Z when done.
Enter the name of the access control group to use.
The current default is "bb_ns:.biggroup".
Group name:
               SHOW
              GROUP   bb_ns:.biggroup
                 AT   05-NOV-2019:14:41:25
  DNS$Members (set) = :
      (V) Principal = bb_ns:.mgv460.manager

Enabling and Disabling Autoregistration of DECnet Phase V Nodes

Some tasks in this chapter manually register nodes in the namespace. DECnet Phase V nodes — but not Phase IV nodes — can automatically register themselves in the namespace when they are configured. This is called autoregistration. With this option you can enable or disable autoregistration of DECnet Phase V nodes. (Autoregistration of DECnet Phase V nodes is disabled by default.)

Although convenient, autoregistration of DECnet Phase V nodes presents a potential security risk because allowing autoregistration into a specific directory adds write access for the world (.*...) to the access control set (ACS) for that directory. Therefore, all users in the network can create child directories, objects, and soft links in that directory.

If you disallow autoregistration in a directory, the namespace is more secure because only authorized users can create entries in that directory. However, node names in that directory must be registered by an authorized namespace manager.

Allowing Autoregistration

To allow node autoregistration for a directory, select Function 11 at the decnet_register_decdns function menu. The following messages and prompts appear. Press Ctrl/Z to exit. Output is similar to the following example:

Allow node autoregistration into a directory.
Press Ctrl/Z when done.
Enter the name of the directory for which to allow autoregistration.
The current default is ".DNA_BackTranslation.%X49".
* Directory name: .Japan.Osaka
Modifying world write access to allow node autoregistration in this directory.

For help answering the prompt, refer to the following:

Directory Name

Specify the full name for the directory whose access is to be modified. This should not include a node name; for example, .Japan.Osaka.

Disallowing Autoregistration

To disallow node autoregistration for a directory, select Function 12 at the decnet_register_decdns function menu. The following messages and prompts appear. Press Ctrl/Z to exit. Output is similar to the following example:

Disallow node autoregistration into a directory.
Press Ctrl/Z when done.
Enter the name of the directory for which to disallow autoregistration.
The current default is ".DNA_BackTranslation.%X49".
* Directory name: .Japan.Osaka
Modifying world write access to disallow node autoregistration in this directory.
* Directory name:

If a source user’s connection request does not contain access control information, the following conditions must be met for proxy to be approved:

Use the Authorize utility to create and modify the permanent proxy database, NETPROXY.DAT (or NET$PROXY.DAT), at your node. Each proxy database entry can map a single source user to multiple proxy user names on the target node (one default proxy user name and up to 15 additional proxy user names). The proxy database entry identifies the source user by a six-character node synonym in the form of nodename::username or nodename::[group,member]. (For information on using the Authorize utility, refer to the VSI OpenVMS System Management Utilities Reference Manual, Volume 1: A-L.)

For example, to create a proxy database file at the target node and add a default proxy entry mapping source user martin on source node boston to local user allen at the target node, enter the following commands at the target node:

$ set default sys$system
$ run authorize
uaf> create/proxy
uaf> add/proxy boston::martin allen/default
uaf> exit 

uaf> create/proxy
uaf> add/proxy boston::martin allen/default
uaf> add/proxy acme:.boston.martin allen/default
uaf> add/proxy LOCAL:.boston.martin allen/default
uaf> exit 

Refer to the VSI OpenVMS System Management Utilities Reference Manual, Volume 2: M-Z for more information on establishing proxy accounts.

Using Wildcard Proxy Entries

You can use the wildcard symbol (*) when creating proxy database entries. You can use wildcards in the source user name field, the source node name field, the local user name field, and in any combination of fields.

When matching source node and user information against entries in the proxy database, only one entry is used and exact matches are preferred over wildcard entries. Therefore, care must be exercised when using wildcard entries. As an example, assume the proxy database has the following entry:

*::SYSTEM
   * (D) 

If the system manager on the target node wanted to add the alternate account USERX for user SYSTEM on source node LAMCHP while retaining the SYSTEM account as the default account, the manager would use the following command:

UAF> ADD/PROXY LAMCHP::SYSTEM SYSTEM/DEFAULT, USERX 

After the ADD command, the proxy database would contain the following entries:

UAF> SHOW /PROXY *
 Default proxies are flagged with (D)
 *::SYSTEM
    * (D)
LAMCHP::SYSTEM
   SYSTEM (D) USERX 

If the system manager omitted the local SYSTEM account from the previous ADD command (ADD/PROXY LAMCHP::SYSTEM USERX), the proxy database would contain the following entries:

*::SYSTEM
   * (D)
LAMCHP::SYSTEM
   USERX 

The preceding proxy database entries allow SYSTEM on source node LAMCHP access to the USERX account (and deny access to the SYSTEM account) on the target node. This occurs because the proxy processing prefers exact matches over wildcard matches.

The session control entity attribute incoming proxy allows you to control proxy access to the target node. The session control application attribute incoming proxy allows you to control proxy access to a particular application.

If proxy access is disabled, the system treats the request as if proxy access were not requested. To disable proxy access on a systemwide basis, set the session control attribute incoming proxy to false. The following example shows the command you need to disable proxy access for a system:

ncl> set session control incoming proxy false

For proxy access to a particular application, you must enable proxy access to both the node and the application. For example, to enable proxy access for particular applications, set the session control attribute incoming proxy to true and set the session control application attribute incoming proxy to true for those applications to which you want to allow proxy access.

The following example shows the commands you need to enable proxy access for the application cml and to disable proxy access for the application fal:

ncl> set session control incoming proxy true
ncl> set session control application cml incoming proxy true
ncl> set session control application fal incoming proxy false 

For examples of setting up session control application entities, refer to Appendix E, Examples of Network Management Tasks.

You should remove proxy access to the system when it is no longer needed. Invoke the Authorize utility and enter the following command to remove proxy access:

uaf> remove/proxy boston::martin

For information on using the Authorize utility, refer to the VSI OpenVMS System Management Utilities Reference Manual, Volume 1: A-L.

By default, the startup procedure displays a minimal amount of Network Control Language (NCL) information.

If you want to view the complete NCL output for troubleshooting purposes, you can define the following logical name in the SYS$MANAGER:NET$LOGICALS.COM file:

$ define/system/nolog net$startup_quiet_ncl false

For more information about the NET$LOGICALS.COM file, see Section 6.3, “Defining Logical Names That Modify Network Operation”.

NET$STARTUP.COM supports the startup_p2 SYSGEN parameter. The value is set using either SYSGEN or the SYSMAN STARTUP SET OPTIONS command. This parameter controls the output from STARTUP.COM (and now from NET$STARTUP.COM).

The network shutdown procedure, (NET$SHUTDOWN.COM), checks for the existence of the NET$APPLICATION_SHUTDOWN logical name. If this logical name is defined, NET$SHUTDOWN invokes the site-specific network application shutdown command procedure referenced by the logical name.

Support for this feature includes a template file SYS$MANAGER:NET$APPLICATION_SHUTDOWN.TEMPLATE that you can use to create a customized network application shutdown file. You should rename this file to a .COM file, edit the file as necessary for your site, and define the logical name NET$APPLICATION_SHUTDOWN to reference this file. See the template file for more information.

The NET$LOGICALS.TEMPLATE file includes this logical name. For more information about the NET$LOGICALS.TEMPLATE file, see Section 6.3, “Defining Logical Names That Modify Network Operation”.

The NET$APPLICATION_SHUTDOWN logical name does not change the function of the NET$AUX_CONTROL logical name.

Note that data link entities and other supporting entities are created automatically by certain scripts or procedures. For example, the NET$CONFIGURE.COM, NET$STARTUP.COM, and WANDD$STARTUP.COM procedures set up modem connect line and HDLC data link entities automatically. An automatically created entity can use resources needed for another entity. For instance, when you configure DECnet and X.25 together, the automatically created hdlc link entity uses the Modem Connect line, preventing you from enabling your LAPB link, which needs the modem connect line. Table 8.1, “Files That Automatically Create Data Links on OpenVMS I64 and Alpha Systems” and Table 8.2, “Files That Automatically Create Data Links on OpenVMS VAX Systems” list scripts and procedures that automatically create entities on OpenVMS I64 and Alpha systems and on OpenVMS VAX systems, respectively, and indicate how to delete these entities if they are not needed. All scripts and procedures listed here are located in SYS$STARTUP.

This section shows the commands to create the Modem Connect module to set up your lines. For the variables, substitute values appropriate to your configuration. VSI, however, recommends that you accept the default settings for the various attributes and change these only if you need to. For more information about these attributes, refer to the VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide. Figure 8.1, “Modem Connect Entity” shows the modem connect entity and subentities.

The following steps show the commands for creating the Modem Connect module to set up your lines:

The following steps show the commands to create a CSMA-CD data link for an end system. VSI, however, recommends that you accept the default settings (used in the example) for the various attributes and change these only if you need to. Refer to the VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide for more information about these attributes.

The following steps show the commands to create an FDDI data link for an end node. VSI, however, recommends that you accept the default settings (used in the example) for the various attributes and change these only if you need to. Refer to the VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide for more information about these attributes.

For information about creating LLC2 and X.25 over TCP/IP (XOT) data links, see the VSI X.25 for OpenVMS Management Guide.

The following steps show the commands to create an HDLC data link for an end system. (As implemented by DECnet-Plus, HDLC is VSI’s variant of the HDLC protocol. It interoperates with some implementations of HDLC from other vendors.) VSI recommends that you accept the default settings for the various attributes and change these only if you need to. Refer to the VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide for more information about these attributes. You can configure the device and modem control entities using WANDD$STARTUP (NET$CONFIGURE automatically invokes WANDD$STARTUP if needed).

The following steps show the commands to create a DDCMP data link for an end system. VSI, however, recommends that you accept the default settings for the various attributes and change these only if you need to. For more information about these attributes, refer to the VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide.

For information about creating LAPB data links, see the VSI X.25 for OpenVMS Management Guide.

To configure routing, you first create the routing entity, specifying the routing type; set the routing attributes discussed in subsequent subsections; and then enable routing. To set up the routing type, use the routing type attribute as in the following example. The routing type attribute can be endnode, L1router, or L2router.

ncl> create routing type endnode [set routing attributes]
.
.
.
ncl> enable routing 

To set up your system as a host-based router (or an end system if it is currently set up as a host-based router), use the DECnet-Plus configuration procedure. Host-based routing is explained in Section 8.4.1.2, “Host-Based Routing”. Likewise, to modify the type of routing your system uses, integrated mode or segregated mode, use the DECnet-Plus configuration procedure or NCL (as explained in Section 8.4.1.3, “Segregated Mode Routing and Integrated Mode Routing”).

DECnet-Plus for OpenVMS supports host-based routing. An OpenVMS system can operate as a DECnet Phase V intermediate system in a routing domain (a collection of systems that automatically configure to each other and exchange network topology information using consistent network layer protocols).

DECnet-Plus for OpenVMS host-based routing includes support for:

Host-based routing is especially useful for those configurations where you need to route from a LAN to a WAN and want to use an existing system to do the routing rather than investing in a dedicated router. Host-based routing is not intended for use in network configurations that have high-throughput requirements.

The following commands were generated by NET$CONFIGURE to configure a level 2 router using the routing vector routing algorithm:

ncl> create node 0 routing type l2router
ncl> set node 0 routing phaseiv address = 23.14
ncl> set node 0 routing phaseiv prefix = 49::
ncl> set node 0 routing manual l1 algorithm = routing vector
ncl> set node 0 routing manual l2 algorithm = routing vector
ncl> set node 0 routing default eshello timer 600
ncl> set node 0 routing maximum path splits = 2
ncl> set node 0 routing phaseiv maximum address = 1023
ncl> set node 0 routing phaseiv maximum area = 63
ncl> set node 0 routing phaseiv buffer size = 576
ncl> enable node 0 routing

The following commands were generated by ISIS$CONFIGURE to configure a level 2 router using the link state routing algorithm:

ncl> CREATE NODE 0 ROUTING TYPE L2ROUTER
ncl> SET NODE 0 ROUTING MANUAL AREA ADDRESSES = {12:234}
ncl> SET NODE 0 ROUTING MANUAL L1 ALGORITHM = LINK STATE
ncl> SET NODE 0 ROUTING MANUAL L2 ALGORITHM = LINK STATE

For end systems, you have the option of using integrated mode routing or segregated mode routing.

Integrated mode routing works in the following way: It sends DECnet Phase IV messages across the network using DECnet Phase V Network layer protocols. Routers receiving DECnet Phase IV packets translate them to OSI CLNP format before forwarding them. Messages destined for DECnet Phase IV systems are translated to Phase IV format only on the last hop of their journey. Integrated mode routing allows routers to route both DECnet Phase IV and Phase V traffic while storing a single network topology in their internal databases.

Under integrated mode, DECnet-Plus systems attempt to send packets in DECnet Phase V format unless:

Integrated mode routing is the only mode supported on OpenVMS systems preceding DECnet/OSI for OpenVMS Version 5.8.

Segregated mode routing handles DECnet Phase IV and Phase V as independent protocols. Routers do not translate messages between DECnet Phase IV and Phase V format. The routers must maintain separate network topologies in their internal databases to handle each type of protocol.

Under segregated mode, DECnet-Plus end systems transmit messages in the Phase IV address format if they have a DECnet Phase IV translatable destination address. All other messages are sent in DECnet Phase V format. If you use non-VSI routers that do not support VSI’s technique of translating DECnet Phase V addresses to DECnet Phase IV, you may want to use segregated mode routing.

Integrated mode is the default routing mode. To configure segregated mode, use the advanced configuration procedure or NCL. With NCL, you can switch from the default to segregated mode by setting the routing mode attribute, as in the following commands:

ncl> disable routing
ncl> set routing routing mode = segregated
ncl> enable routing 

Use integrated routing mode in an integrated routing environment where the routers can handle Phase-IV-to-Phase-V or Phase-V-to-Phase-IV packet format conversions. Use segregated routing mode when the adjacent routers cannot perform Phase-IV-to-Phase-V or Phase-V-to-Phase-IV packet conversions.

A DECnet Phase V environment is a subnetwork where OSI systems, both end systems and intermediate systems (ES-IS), adhere to the DECnet Phase V routing protocol and support DNA-structured NSAP addresses, as defined in the VSI DECnet-Plus Planning Guide. When existing in a Network Architecture (NA) environment, an end system can determine (that is, autoconfigure) its network addresses from information sent by the routers in its subnetwork. In this environment, you do not have to manually set the local network service access point (NSAP) addresses. This is the default during configuration using NET$CONFIGURE.COM. In some networks, you must manually set the network address at configuration time.

An empty set for the manual network entity titles attribute indicates the use of autoconfiguration. If the set is non-empty, autoconfiguration does not take place. To change the value of this routing attribute from an empty set to a non-empty set, or from a non-empty set to an empty set, the routing entity must be disabled.

DECnet Phase IV nodes cannot recognize DECnet Phase V addresses. However, DECnet Phase V nodes can recognize Phase IV addresses. For a DECnet Phase V node to communicate with a Phase IV node, the DECnet Phase V node must have a Phase IV address that conforms to the normal Phase IV limits (area number less than or equal to 63 and node number less than or equal to 1023). You must configure this Phase IV address on your DECnet-Plus system.

Use the DECnet-Plus configuration procedure or the following command to set up a Phase IV address. For this command to succeed, routing must not be enabled.

ncl> set routing phaseiv address 12.1

The Phase IV address along with a Phase IV address prefix is used to construct a Phase IV-compatible NSAP address. This is done by concatenating the Phase IV address prefix, the area portion of the Phase IV address, the DECnet LAN address, and a transport selector. See Section 10.2.2 for information on how to convert the Phase IV address to a DECnet LAN address. For example, if a system’s Phase IV address is 12.1 and the Phase IV address prefix is 49::, the resulting NSAP addresses for NSP and OSI Transport are respectively (where 12 decimal is converted to 0c hexadecimal and 12.1 is converted to DECnet LAN address of aa-00-04-00-01-30):

49::00-0c:aa-00-04-00-01-30:20
49::00-0c:aa-00-04-00-01-30:21 

In the same way that they learn their OSI network addresses, end systems learn their Phase IV address prefix from the routers in the subnetwork. Only if there are no DECnet Phase V routers present, does the end system use its own routing attribute phaseiv prefix to construct its Phase IV-compatible NSAP address.

For an end system to learn its Phase IV address prefix, you must configure it into the routers of the subnetwork in which the system resides. The default prefix for all systems is 49::. If you want to use a different initial domain part (IDP) and pre-DSP (domain-specific part), you can override the default by setting the phaseiv prefix attribute as follows. For this command to succeed, routing must not be enabled.

ncl> set routing phaseiv prefix 37:1234:

For example, if you configure a router in area 41 with the phaseiv prefix 37:1234:, any DECnet-Plus end system with a Phase IV address in area 41 sets its Phase IV area as follows, where 41 decimal is converted to 29 hexadecimal:

37:1234:00-29: 

This results in a Phase IV-compatible NSAP address of the form:

37:1234:00-29:aa-00-04-00-nn-nn:ss

All systems in the subnetwork should have the same Phase IV prefix, but because DECnet Phase V systems autoconfigure, you only need to set the prefix on the routers used by the end system. VSI, however, recommends that you ensure that the phaseiv prefix attribute is consistently set on all DECnet Phase V systems.

If your end system is operating in an environment with one or more non-DNA routers, your DECnet-Plus end system cannot autoconfigure its network address or network entity title (NET). (The NET is the address that identifies the Network layer.) In this case, you can manually specify up to three NETs for your system. To do this, you need to know the following information about the node:

The following sequence of commands specifies the NET for a system:

ncl> create routing type endnode
ncl> set routing manual network entity titles -
_ncl> { 41:45418715:00-49:08-00-2b-00-01-02:00} 
ncl> enable routing 

To make this change permanent, rerun the advanced configuration procedure or add these commands to the NET$ROUTING_STARTUP.NCL script file after the line create routing type endnode. (Replace the string (41:45418715:00-49:08-00- 2b-00-01-02:00) with the correct NET for your node.) The next time you reboot the system, DECnet-Plus uses this new information.

DECnet Phase V end systems can operate over more than one data link. As such, traffic can be sent or received over any of the links, but protocol data units (PDUs) are not forwarded from one link to another. In other words, a multicircuit end system does not perform the functions of a router. Instead, this function provides network redundancy, as well as higher throughput, depending upon the configuration.

DECnet-Plus for OpenVMS supports up to 16 circuits. Hardware, OpenVMS, or WANDD software, however, can further limit the number of circuits you can have. For more information about possible limits, refer to your system and WANDD documentation.

When communicating with remote systems, data PDUs are sent over all circuits in turn. If the remote end system is directly connected on one or more circuits, only those circuits are used to reach the end system. Moreover, a single data PDU is transmitted over all circuits at the interval at which you set the probe rate.

The probe rate is a Routing module attribute that has a default value of 1000. Therefore, every thousandth data PDU bound for a specific end system is transmitted on all circuits. This helps ensure that all available paths are used.

When operating a DECnet-Plus end system in a multicircuit configuration, you must adhere to certain topology restrictions:

Failure to comply with these restrictions might result in unacceptable operation.

To create multiple circuits for an end system on a CSMA-CD LAN, use the DECnet-Plus configuration procedure. VSI recommends that you accept the default settings (used in the example in Section 8.4.2.2, “Sample NCL Script for Configuring Multiple Routing Circuits”) for the various attributes and change these only if you need to. Refer to the VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide for more information about these attributes.

The following example shows the contents of the file NET$ROUTING_STARTUP.NCL, located by default in SYS$SPECIFIC:[SYSMGR]. This file is created by the DECnet-Plus for OpenVMS configuration procedure. The file enables routing, creates the Routing module, and creates CSMA-CD and FDDI circuits.

create node 0 routing type endnode
set node 0 routing phaseiv address = 4.884
set node 0 routing phaseiv prefix = 49::
set node 0 routing dna address format true
set node 0 routing default eshello timer 600
enable node 0 routing
create node 0 routing circuit csmacd-0 type = csma-cd
set node 0 routing circuit csmacd-0 data link entity = csma-cd station csmacd-0
set node 0 routing circuit csmacd-0 enable phaseiv address = false
enable node 0 routing circuit csmacd-0
create node 0 routing circuit fddi-0 type = fddi
set node 0 routing circuit fddi-0 data link entity = fddi station fddi-0
set node 0 routing circuit fddi-0 enable phaseiv address = true
enable node 0 routing circuit fddi-0 

DECnet-Plus supports the inactive subset of CLNS, also known as null internet. An inactive subset PDU contains no Network layer addressing information; it is sent directly to the data link address derived from the destination NSAP address. Therefore, it cannot be routed by an intermediate system. This means that only LAN devices can support the inactive subset PDU, and the two communicating nodes must be on the same LAN. The inactive subset of CLNS allows communication with OSI systems that only implement the inactive subset.

Configuring CLNS with null internet is no different from configuring full CLNS, with the following restrictions:

For more information on configuring CLNS OSI transport to use the null internet, see Section 8.5.2.4.3, “Null Internet Information”.

You can turn the ability to transmit and receive inactive subset protocol data units (PDUs) on and off on a per circuit basis by defining a value for the circuit attribute inactive area address. The following example uses the default inactive area address attribute on a LAN:

ncl> create routing circuit csmacd-0 -
_ncl> type csma-cd
ncl> set routing circuit csmacd-0 -
_ncl> inactive area address {49::FF-00}
ncl> enable routing circuit csmacd-0 

You must do this after the circuit is created, but before you enable it. The value is the address of an otherwise unused area in your network.

If you want to change the transport, modify the Routing module’s preset attribute, inactive selector, with the selector of the transport you want to use. Only one transport may use the inactive subset and, by default, this is OSI transport (which has a default selector value of 33). To operate NSP over the inactive subset, before enabling the Routing module (and any circuits) enter the command:

ncl> set routing inactive selector 32

When using the inactive subset, destination NSAPs must contain the inactive area address followed by the data link address of the remote machine followed by the transport selector. For example:

49::FF-00:08-00-23-00-01-02:21

Reachable addresses allow the system manager to override the automatic routing mechanisms in DECnet-Plus. You can define reachable addresses for each circuit. Two types of reachable addresses are outbound and filter, as described below. (For information about routing reachable addresses used for X.25 routing circuits, see Section 8.8.2.2, “Configuring Routing Over X.25 Dynamically-Assigned Circuits”.)

You can use NCL to switch from the default (outbound) to filter by setting the reachable address entity type attribute to the value filter. You must disable the routing reachable address entity before changing the value of the type attribute.

The following reachable address attributes are supported by outbound reachable addresses:

The following example shows how to use NCL commands to create an outbound type of reachable address:

ncl> create routing circuit csmacd-0 reachable address to-area4 -
_ncl> address prefix 49::00-04:
ncl> set routing circuit csmacd-0 reachable address to-area4 -
_ncl> mapping manual
ncl> set routing circuit csmacd-0 reachable address to-area4 -
_ncl> type outbound
ncl> set routing circuit csmacd-0 reachable address to-area4 -
_ncl> data format phaseiv
ncl> set routing circuit csmacd-0 reachable address to-area4 -
_ncl> block size 500
ncl> set routing circuit csmacd-0 reachable address to-area4 -
_ncl> lan address aa-00-04-00-xx-xx 

The permitted lan addresses attribute applies to filter reachable addresses for broadcast circuits only. This attribute specifies a set of LAN addresses corresponding to routers that are permitted to forward to this prefix. The default is an empty set. You must specify at least one LAN address. Specify these LAN addresses within a pair of braces, separating the addresses by commas, as in the last command in the following example, which shows how to create a filter reachable address.

ncl> create routing circuit csmacd-0 reachable address to-area4 -
_ncl> address prefix 49::00-04:
ncl> set routing circuit csmacd-0 reachable address to-area4 -
_ncl> mapping manual
ncl> set routing circuit csmacd-0 reachable address to-area4 -
_ncl> type filter
ncl> set routing circuit csmacd-0 reachable address to-area4 -
_ncl> data format phasev
ncl> set routing circuit csmacd-0 reachable address to-area4 -
_ncl> permitted lan address {aa-00-04-00-xx-xx, aa-00-04-00-yy-yy} 

The Routing module stores information about remote systems (including NSAP addresses) to which data transfer is in progress. This information is known as the end system cache, and the data stored in this cache allows the Routing layer to quickly choose the correct data link address to which packets should be forwarded, as well as which format (Phase IV or OSI) should be used. The cache entries are created automatically, based upon the receipt of data and/or routing redirect packets, and indicate if the remote system is on-LAN (direct), or reachable by way of a router (indirect or reverse).

When an end system communicates to another node for the first time, the end system cache has no routing information for that node. The end system chooses at random an adjacent router and transmits the data to it, allowing the adjacent router to find a path to the destination node. The end system creates cache entries based on information about the routing path received from incoming data sent by routers and from advertisements sent directly from other end systems.

Cache entries are each assigned a precedence which determines the path chosen when two or more cache entries refer to the same destination. The Routing module assigns precedence as shown in Table 8–6, where 1 is the highest precedence. Direct reachability indicates the path is direct from source to destination without intermediary routers. Indirect indicates the path is through one or more intermediary routers. Reverse reachability implies the directness of the path is indeterminate at the time (whether a direct path exists will be resolved during subsequent communications).

A reverse path cache entry indicates that a data packet was received from an adjacent node on a specific circuit. The adjacent node could be the original sender or the last router that forwarded the packet. Given no other information, the most efficient path for sending response packets is usually the path the original data message followed.

The Routing module follows these rules for making a cache entry:

When multiple paths with the same precedence exist for the same destination, the Routing module selects the path based on round robin. This helps balance the load on the paths. On multicircuit end systems, if no direct path to the destination node exists on a broadcast circuit, a duplicate packet is sent periodically, as determined by the probe rate.

The es cache holding time attribute determines how long an entry is held in the end system cache. The default is 600 seconds. The timer is refreshed each time a data packet is successfully received by the destination node over the path defined by the entry. The entry is deleted if no communication occurs between the source and destination nodes within the period defined by the timer. This maximizes the effectiveness of the end system cache.

Displaying Cache Entries

Use the System Dump Analyzer (SDA) to show cache entries, as in the following example:

$ analyze/system
OpenVMS (TM) System Analyzer
SDA> net show routing cache
%SDA-I-READSYM, 3361 symbols read from SYS$COMMON:[SYSEXE]NET$SYMBOLS.STB;1
DECnet-Plus for OpenVMS Routing ES Cache Dump
--------------------------------------------
Routing Prefix DataBase Address 816C63A8
Prefix Table Start: 825D5F0C , End: 825D610C, Size 0
Routing Cache DataBase Address 816C6390
Cache Table Start: 825D10CC , End: 825D12CC, Size 1
   Cache Entry at Address 825D256C
       NSAP:
                 4900 04AA0004 007F1321
            OSI Transport - (4.895)
       Cache Circuit Entry Count : 1, Probe Count: 992
       Cache Circuit List: 8260B500
       Cache Circuit Entry:
             Type:               BroadCast
             Format:             PhaseV
             Reachability:       Direct
             Blocksize:          Non-FDDI
             Remaining LifeTime: 005F
             Holding Time:       0258
             Data Link Address:
                                 137F 000400AA ª..... 00000000
                (4.895)
SDA>

DECnet Phase IV and Phase V end systems and routers regularly advertise their existence on their attached data links. DECnet-Plus nodes listen for these advertisements and automatically build (autoconfigure) an adjacency database. For LANs, the adjacency database contains the list of routers attached to each circuit. For WAN circuits, the adjacency database identifies the type of node attached to the other end of the circuit, router or endnode. DECnet-Plus also automatically records OSI systems from other vendors in its adjacency database as OSI-only nodes.

If the routers in a subnetwork do not adhere to the DECnet Phase V routing protocol (in other words, they are non-DNA routers), DECnet Phase V end systems are unable to create physical connections to them.

Normally, a DECnet Phase V end system learns about its routers through the ES-IS protocol. If your LAN has only routers that do not implement the ES-IS protocol, you must identify the LAN address of the routers that the DECnet Phase V end system uses. Included in the following sequence of commands is a command needed for specifying the LAN address for a CSMA-CD data link. The command is called out (1).

ncl> create routing type endnode
ncl> enable routing
ncl> create routing circuit csmacd-0 -
_ncl> type csmacd
ncl> set routing circuit csmacd-0 manual routers -
_ncl> { 08-00-2b-00-01-03, 08-00-2b-00-03-04 } 
ncl> set routing circuit csmacd-0 -
_ncl data link entity csma-cd station csmacd-0
ncl> enable routing circuit csmacd-0

Displaying Adjacencies

Display routing adjacencies by using the following NCL command:

ncl> show routing circuit circuit_name adjacency * all

The following example shows two adjacencies for circuit csmacd-0:

$ mcr ncl show routing circuit csmacd-0 adj * all
Node 0 Routing Circuit CSMACD-0 Adjacency RTG$0001
at 2019-07-24-09:48:29.181-04:00I22.051
Identifiers
   Name                = RTG$0001
 Status
    Type               = Autoconfigured 
    State              = Up
    LAN Address        = 08-00-2B-A2-08-B9
    Neighbor Node Type = Phase V Router 
    Router NETs        =
    {
      47:24:02-01-0A-04:08-00-2B-A2-08-B0:00 ,
      49::00-04:AA-00-04-00-F5-13:00 (DEC:.LKG.LKISL2)
    }
Node 0 Routing Circuit CSMACD-0 Adjacency RTG$0002
at 2019-07-24-09:48:29.191-04:00I22.051
Identifiers
   Name                = RTG$0002
 Status
    Type               = Autoconfigured
    State              = Up
    LAN Address        = AA-00-04-00-FF-13 (LOCAL:.A04NIS)
    Neighbor Node Type = Phase V Router
    Router NETs        =
    {
      47:24:02-01-0A-04:08-00-2B-A0-17-90:00 ,
      49::00-04:AA-00-04-00-FF-13:00 (LOCAL:.A04NIS)
    }

Networking with Routers That Do Not Support Phase IV Backward Compatibility

Connectivity from a DECnet Phase V end system to a Phase IV node through a router that does not support Phase IV backward compatibility is not possible. A non-DNA OSI router does not know how to translate a DECnet Phase V address to a Phase IV address, or convert Network layer data protocol data unit (PDU) formats. The following are possible solutions to consider:

If you have configured your DECnet-Plus end systems to have a Phase IV- compatible address and you are operating in a non-DNA environment, you must ensure that all level 2 non-DNA OSI routers advertise the complete set of area addresses for the level 1 networks to guarantee connectivity between your DECnet-Plus end systems.

The following example shows the NCL commands you can use to create the osi transport entity on your system, setting attributes applicable to all types of network services. Section 8.5.2.3, “Configuring OSI Transport to Use CONS” gives examples of commands required to configure CONS support. VSI recommends that you accept the default settings used in the examples for the attributes. Change them only if necessary. For more information on these attributes, refer to the VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide.

ncl> create osi transport
ncl> set osi transport delay factor 4, delay weight 5,- 
_ncl> maximum remote nsaps 64, - 
_ncl> maximum transport connections 33, maximum window 20 
ncl> enable osi transport 

You must disable the osi transport entity before modifying attributes that affect operation.

When DECnet-Plus is configured, templates are set up for the OSI Transport module. Each template is an NCL database entry that manages network access. Each template includes a group of attributes that supply default values for certain parameters that influence the operation of a port on a transport connection.

The templates store information and also may reference information located elsewhere.

Each OSI transport template corresponds to a specific type of network service to which OSI transport can direct outbound messages and from which it can receive inbound messages.

OSI transport supports three network services:

Table 8.7, “Templates Set Up for OSI Transport on OpenVMS Systems” describes the templates that are set up for OSI transport on your system. Note that the null internet does not require a template.

Do not modify listed attributes of the default template. The other templates are defined in the NCL initialization script SYS$MANAGER:NET$OSI_TRANSPORT_STARTUP.NCL.

The following sections describe how to configure the Connection-Oriented Network Service (CONS). CONS is a network service that operates according to a connection-oriented model. Before data can be exchanged, a connection must first be established. X.25 provides this type of service.

By default, DECnet-Plus automatically configures OSI transport to use the Connectionless-Mode Network Service (CLNS). CLNS is a network service that operates according to a datagram model. Each message is routed and delivered to its destination independently of any other. When using CLNS, only transport protocol class TP4 is available in the default configuration.

You can configure OSI transport to use RFC 1006, allowing use of OSI applications over TCP/IP, and to use RFC 1859, allowing use of DECnet applications over TCP/IP. For details, see Section 8.5.3, “DECnet and OSI Applications over TCP/IP”.

After configuring OSI transport on an OpenVMS system, you can use the [SYS$TEST]OSIT$IVP OSI transport installation verification procedure to verify correct operation.

This procedure (the test initiator) communicates with the passive OSI transport application OSIT$IVP which invokes OSIT$IVPRESP.COM (the test responder) on the target system. The target system may be either your system or some other system running DECnet-Plus for OpenVMS. (Start the initiator by executing the SYS$TEST:OSIT$IVPINIT.COM file.)

You must supply the VOTS-address of the target system. A VOTS-address has the form template%network address, where:

You can list the OSI transport NSAPs for a system using the following command:

ncl> show osi transport local nsap * 

As an alternative to specifying a VOTS-address explicitly, you can specify a logical name defined in the table OSIT$NAMES.

By default, the DECnet-Plus OSI transport sends the preferred maximum tpdu size, request acknowledgment, and implementation id parameters in its CR TPDU (connect request transport protocol data unit).

According to ISO 8073, OSI transport providers should ignore unknown parameters while processing a CR TPDU. However, some vendor implementations do not conform to ISO 8073. Therefore, their OSI transport does not ignore unknown parameters in a CR TPDU. This nonconformance results in a connection failure when unknown parameters are detected (such as the three parameters sent by the DECnet-Plus OSI transport). The following example provides a way to prevent issuance of these unknown parameters in a CR TPDU:

NCL> set osi transport template template-id -
_NCL> send preferred maximum tpdu size false
NCL> set osi transport template template-id -
_NCL> send request acknowledgment false
NCL> set osi transport template template-id -
_NCL> send implementation id false 

One feature of OSI transport is the ability to use the Congestion Experienced field in the Connectionless-Mode Network Service (CLNS) routing header, and to implement a congestion avoidance scheme in heavily congested networks. The CLNS Congestion Experienced field is used by routers that support this feature (such as DECNIS) to give an early indication of congestion. When OSI transport receives data that passed through a network path where the Congestion Experienced bit is set, OSI transport reduces the transmit rate of the sending end system to help alleviate network congestion.

This feature works well in networks where all protocols support congestion avoidance mechanisms. However, in heavily congested multiprotocol networks that include network protocols that do not support the congestion avoidance mechanism, the performance of DECnet can be impaired. VSI recognizes that most of its customers have multiprotocol networks and that not all network protocols have congestion avoidance mechanisms. Therefore, VSI has set the default for this attribute to be disabled.

If you operate in an environment where you can take advantage of congestion avoidance mechanisms, enable this feature.

To change transport congestion avoidance values, invoke NET$CONFIGURE ADVANCED and use Option 4 (Configure Transports). Answer no to the following question:

Is this System operating in a Multi-Protocol Network? [YES] :.

This section describes how to configure applications to receive connection requests from remote hosts. One of the attributes of a transport connection request is a transport service access point identifier (TSAP-ID), which uniquely identifies the transport application on the remote host to which the connection request is to be passed.

An application that expects to receive a connection request must therefore associate itself with a particular TSAP-ID, so the transport service knows which application a particular connection request is intended for.

There are two ways in which an application can associate itself with a TSAP-ID: active association or passive association.

Active association is entirely under the control of the transport user, and requires no support from you. Passive association, on the other hand, requires that you configure the osi transport application entities that describe the association between TSAP-IDs and applications.

In active association, the transport application issues a $qio(io$_acpcontrol) system service call in which it requests an association with a specified TSAP- ID. When a connection request arrives with that TSAP-ID, a mailbox message containing details of the connection request is sent to the associated application, which can then process the request, either accepting or rejecting it.

OSI transport dynamically creates the osi transport port entity so that the active association is available by means of network management.

In passive association, you create an osi transport application entity, whose characteristics specify:

When a connection request arrives with a TSAP-ID that is associated with an osi transport application entity, the transport service creates a new process in which it runs loginout.exe. loginout.exe validates any access control information and invokes DCL to execute the image or command file associated with that TSAP-ID. Details of the connection request are passed in the logical name sys$net.

The following command example shows the commands to configure an osi transport application entity. For the variables, substitute values appropriate to your configuration. VSI, however, recommends that you accept the default settings (used in the example) for the various attributes and change these only if you need to. Refer to the VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide for more information about these attributes.

ncl> create osi transport ncl> enable osi transport
ncl> create osi transport application application-name
ncl> set osi transport application application-name -
_ncl> called tsels set-of-hex-string,- 
_ncl> file name file-spec, user name user-account 
ncl> enable osi transport application 

The following examples show how you can use DECnet over TCP/IP to connect to any of the remote hosts on the network shown in Figure 8.7, “Sample Multiprotocol Network”, a multiprotocol network that includes OpenVMS and Tru64 UNIX systems and a PC system.

If you plan to use RFC 1006 and/or RFC 1859 software, TCP/IP software is a prerequisite. The TCP/IP software used on your system must support the PATHWORKS Internet Protocol (PWIP) interface. For more information about required TCP/IP software, see the DECnet-Plus for OpenVMS Release Notes.

When DECnet over TCP/IP has successfully completed a listen on the defined rfc1006 listener ports, you will see the following OPCOM message in the OPERATOR.LOG file for each TCP Listen Port:

%%%%%%%%%%% OPCOM 30-MAR-2019 11:25:46.74 %%%%%%%%%%%
Message from user TPCONS on YPP4
-- TPCONS: Listen to PWIP Done 

To configure your system so you can use DECnet over TCP/IP or OSI applications over TCP/IP, use Option 4 of the advanced configuration procedure (NET$CONFIGURE.COM ADVANCED), as explained in the VSI DECnet-Plus for OpenVMS Installation and Configuration. You can then create a new OSI transport NCL script (or replace an old script). You must also include Domain in your session control naming search path as described in Section 5.1.1, “Determining the Order for Name Service Searches”.

Use Option 4 as well for creating templates in addition to the default RFC 1006 template.

You must rename your node using a Domain secondary node name. Use Option 2 of the advanced configuration procedure to do this.

For the changes to take effect, either disable the osi transport entity and invoke the new OSI transport NCL script, or reboot the system.

ncl> disable osi transport
ncl> do sys$manager:net$osi_transport_startup.ncl 

When configuring RFC 1006, RFC 1859, or both, each element in the set of rfc1006 listener ports attribute corresponds to a TCP listener port. By default, NET$CONFIGURE sets the osi transport rfc1006 listener ports attribute to {102, 399}.

The rfc1006 port number attribute of the osi transport template subentity must contain a TCP port number that is one of the chosen rfc1006 listener ports.

The default value for the rfc1006 port number attribute is 102. If you create an osi transport template subentity to use with DECnet over TCP/IP (using RFC 1859), then set the rfc1006 port number attribute to 399.

DECnet-Plus will only try to locate TCP/IP if the rfc1006 listener ports attribute set of the osi transport entity is not empty.

To disable DECnet over TCP/IP, issue the following command:

ncl> set osi transport rfc1006 listener ports {}

CTF can be used to trace all PDUs transmitted and received by DECnet over TCP/IP and OSI applications. See the DECnet/OSI for VMS CTF Use for a list of events that are recognized at this trace point.

Use the following command to invoke the CTF tracing utility:

$ TRACE START "trace-point"

where trace-point is the trace point to be started, such as "TPCONS TPKT *".

If you have problems getting DECnet over TCP/IP to start up properly, check the following:

If IP addresses work but IP names do not, use your TCP/IP management tool to verify that your BIND server knows about the name.

You can audit incoming connections for those connections that are made using DECnet over TCP/IP. The audit alarm is displayed as follows:

%%%%%%%%%%% OPCOM 9-FEB-2019 12:26:11.64 %%%%%%%%%%%
Message from user AUDIT$SERVER on PETERB
Security alarm (SECURITY) and security audit (SECURITY) on PETERB, system id:
12
331
Auditable event:         DECnet logical link created
Event time:              9-FEB-2019 12:26:11.59
PID:                     000000A6
Process name:            FAL_14010028
Username:                SYSTEM
Process owner:           [1,3]
Image name:              SYS$COMMON:[SYSEXE]FAL.EXE
Remote node id:          1560286224
Remote node fullname:    MYNODE.LKG.ACME.COM
Remote username:         CAISSON
DECnet logical link ID:  335609896
DECnet object name:      FAL

DECnet over TCP/IP allows you to use fully qualified domain names in your OpenVMS proxy database. For example:

UAF> add/proxy mynode.lkg.acme.com::caisson caisson/default

A node can have more than one full name for a node. This means that proxy records for each of the possible node names need to be added using the Authorize utility. For example, if your system is set up to use both DECdns and BIND (and you can see a remote node’s name as either of these), then you need to add proxy records for both nodes. To represent the remote node stir, you would need to add these proxy records: STIR.ENET.ACME.COM and DEC:.ZKO.STIR.

If the osi transport entity is deleted and subsequently recreated, you must issue the following directives to inform session control that the OSI transport service is available:

ncl> delete session control transport service osi
ncl> create session control transport service osi protocol %x05 

You cannot issue the delete session control transport service osi command while osi transport port entities exist.

If the nsp entity is deleted and subsequently recreated, you must issue the following directives to inform session control that the NSP transport service is available:

ncl> delete session control transport service nsp
ncl> create session control transport service nsp protocol %x04 

You cannot issue the delete session control transport service nsp command while nsp port entities exist.

You cannot actively manage active addresses; NCL creates the necessary management entities when OSAK sends or receives an appropriate programming call. You use NCL to register passive addresses. This section describes how to register active and passive addresses.

Active

An application registers an active address by passing that address on a call to osak_open_responder or osak_open_initiator. NCL creates the appropriate entities. You can use the NCL show command to show attributes of these entities.

Passive

You register an application address using Network Control Language (NCL) commands to create an osak application entity and an osak application invocation entity. Use the startup information attribute of the osak application invocation entity to specify the values in Table 8.10, “Startup Information Values”.

Further Information

For more information about the OSAK module, refer to the VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide.