HP OpenVMS Systems Documentation

DECnet-Plus supports the asynchronous devices listed in Table B-4.

The following sections provide information about using the delay factor and delay weight attributes when configuring NSP and OSI transport.

C.1 delay factor and delay weight

On class 4 transport connections, the transport service retransmits transport protocol data units (TPDUs) if the remote host does not acknowledge them within a certain period; this period is known as the retransmission time. If the remote host fails to acknowledge a TPDU after a certain number of retransmissions, the local transport service assumes that the network connection has failed, and disconnects the transport connection.

The transport service controls this aspect of its operation by using a retransmission timer. The values of the delay factor and delay weight attributes are used in the algorithm for calculating the value of the retransmission timer.

• delay factor---This attribute affects the retransmission time. For example, when you increase the value of the delay factor attribute, you increase the average round-trip delay time, thus increasing network delay.
• delay weight---This attribute determines the value of the weighting factor. The delay weight value determines how quickly the retransmission timer responds to variations in actual round-trip delay times. A low value of delay weight means that the retransmission timer responds very quickly to each sample of the round-trip delay time; a delay weight of 0 means that an estimate will be nearly the same as the last actual sample of the round-trip delay. A high value for delay weight reduces the impact of recent variations in network delay; the higher the value, the closer each estimate of round-trip delay will be to the average of all estimates.

The default values of delay factor and delay weight should be suitable for most networks. However, consider increasing their values if wide variations in round-trip delay times exist on your network.

The transport service uses the following algorithm to calculate the value of the retransmission timer:

1. Calculate an average round-trip delay for each TPDU. The round-trip delay is the time that elapses between sending a TPDU and receiving an acknowledgment of that TPDU from the remote host.
   See Section C.2 for information on how the average round-trip delay is calculated.
2. Calculate the retransmission timer value using the formula:

   retransmission timer = (average round-trip delay * delay factor) + remote acknowledgment time

The effect of delay factor is to increase the retransmission time by increasing the average round-trip delay time, thus allowing for additional network delay. The default value of delay factor is suitable for most networks. You might want to increase its value if there is considerable variation in round-trip delay from one TPDU to another.

The remote acknowledgment time is the maximum time for which the remote transport service will wait before acknowledging a TPDU that it has received. The remote transport service tells the local transport service the value of its acknowledgment time when the transport connection is established.

The value of the retransmission timer is, therefore, the sum of the estimated round-trip delay (weighted by the delay factor) plus the time taken for the remote transport service to acknowledge a TPDU.

C.2 Estimating the Round-Trip Delay

The transport service continuously recalculates its estimate of the average round-trip delay by taking into consideration recent samples of actual round-trip delay. This ensures that the retransmission timer is adjusted to suit current network conditions. The factors used in the calculation are:

• An actual sample of a round-trip delay
• The most recent calculated estimate of average round-trip delay
• A weighting factor, which determines how much effect the most recent actual sample of round-trip delay has on the new estimate for average round-trip delay

When a transport connection is being set up, the initial value for an actual sample of round-trip delay is provided by the initial retransmit time attribute of the transport template used to set up the connection.

The value of the weighting factor is given by the delay weight attribute. Basically, delay weight determines how quickly the retransmission timer responds to variations in actual round-trip delay times. A low value of delay weight means that the retransmission timer responds very quickly to each sample of round-trip delay time; a delay weight of 0 means that an estimate will be nearly the same as the last actual sample of round-trip delay. A high value for delay weight reduces the impact of recent variations in network delay; the higher the value, the closer each estimate of round-trip delay will be to the average of all estimates.

The default value of delay weight should be suitable for most networks. However, consider increasing its value if there are wide variations in round-trip delay times on your network.

This appendix provides an alphabetical command reference for the following decnet_migrate commands:

collect
convert
convert dcl_file
convert ncp_file
create_ipl_initialization_file
edit
report
show path

D.1 Running decnet_migrate on Your System

Invoke decnet_migrate by entering the following command:

$ run sys$update:decnet_migrate

The collect command collects information from network nodes and places that information in a data file, which is later used by the report command. The collect command collects information from only those nodes that are currently reachable.

You can use this command to determine the current configuration of the network, or to track the configuration changes during transition.

You must have network management privileges that allow you to display information about remote systems.

Each time you use the collect command, a data file is created. To consolidate multiple data files into one data file, use the convert system utility command as follows:

$ convert /merge input_file_1[,input_file_n] output_file

The input_files argument specifies the files to be consolidated, and the output_file argument specifies the name of the consolidated file. Doing this is most useful when you are consolidating data from different areas.

Syntax

collect data_file [routing_type=routing_type | areas=area_id | nodes=node_list_file | status=status_report_count | retry=connection_retry_count | recover]

Arguments

data_file

Specifies the name of the collection data file.

The disk and directory names default to their current values, and the file extension defaults to .DAT.

routing_type=routing_type

Optional. Specifies the routing type of the nodes from which you want to collect information. You can specify one or more of the following:

L1_routers	Only level 1 routers
L2_routers	Only level 2 routers
routers	All routers
all	All nodes, including routers and end nodes (the default)

areas=area_id

Optional. Specifies the area or areas from which you want to collect information. You can specify one or more of the following:

node node_name	The area containing the node you specify by node_name. Use either the node's full name or its Phase IV synonym. If you do not want to use the default namespace, specify a namespace name before the node name. If you do not use the default namespace, the tool may not be able to determine the correct full name for every node.
local	The area in which your node resides.
all	All areas (the default)

The use of all is not recommended for large networks.

If you specify areas, you cannot also specify the nodes parameter. If you specify neither areas nor nodes, the default is areas=all.

nodes=node_list_file

Optional. Names a file with a list of specific nodes from which you want to collect information. Format this file so that:

1.	The nodes are listed one node per line.
2.	For each node, you can use its full name, its Phase IV synonym, its network entity title (NET), or its Phase IV address.

The disk and directory for the node-list-file parameter default to the same disk and directory you specify for the collection file. The file extension defaults to .INP.

If you specify nodes, you cannot also specify the areas parameter. If you specify neither nodes nor areas, the default is areas=all.

status=status_report_count

Optional. Specifies the number of nodes from which to collect information before displaying a collection status message. The collection status message provides information on the number of areas and nodes from which collect is obtaining information.

By default, collect provides a status message after every node. If you do not want a status report, specify status=none for this parameter.

retry=connection_retry_count

Optional. Specifies the number of times the collect command attempts to connect to a node.

By default, collect makes two connection attempts. If you do not want the collect command to retry connections, specify retry=none for this parameter.

Retrying connections is most useful when nodes might have network resource constraints. When collect retries connections, it waits one minute between connect attempts. If a connection cannot be made within the specified number of attempts, collect assumes that it cannot connect to the node. The collect command retries a connection only if the connection error might be transient in nature, such as resource errors. Other types of errors, such as privilege violations, are not retried.

recover

Optional. Continues an interrupted collection operation. Any parameters for nodes and areas that you specified for the interrupted operation are still in effect.

You must specify the data_file, and you cannot specify any of the other parameters.

Some interrupted collection operations cannot be recovered because the interruption corrupted the output file. In this case, you receive an error message and the recovery does not complete.

Examples

1. The following command collects information on all nodes in all areas of the network and puts the information in a file called netinfo.dat.

   decnet_migrate> collect netinfo.dat

2. The following command collects information on all level 2 routers in the area containing the node boston and puts the information into a file called netinfo.dat.

   decnet_migrate> collect netinfo.dat routing_type=l2 - _decnet_migrate> area=node:boston

3. The following command continues a collecting operation that was previously interrupted.

   decnet_migrate> collect netinfo.dat recover

4. The following command collects information on the nodes listed in a file called decnet_vax_nodes.inp.

   decnet_migrate> collect config_1_2_92.dat nodes=decnet_vax_nodes.inp

   
   The contents of decnet_vax_nodes.inp is as follows:

   net:.123.boeham netman fafnir .123.zamphir NET:.123.amaze 49::00-0C:AA-00-04-00-1D-30:00 49::00-0C:AA-00-04-00-22-30:00 49::00-0C:AA-00-04-00-0B-30:00 NET:.123.skgns1 NET:.123.mipsbx NET:.123.mouans 4.56

Converts a specified NCP command to its closest NCL equivalent. The output might consist of one or more NCL commands. See Table 2-1 for a list of the NCP commands that the decnet_migrate convert commands can convert to NCL.

Syntax

decnet_migrate> convert command "ncp-command "

Arguments

"ncp-command"

Specifies the NCP command you are converting. Specify the command exactly as if it were entered at an NCP> prompt and enclose the command in quotation marks.

Examples

1. In the following example, the convert command converts the NCP command show executor characteristics to its NCL equivalent:

   decnet_migrate> convert command "show executor char" ! * Converting the command: ! show executor char show node 0 session all char show node 0 nsp all char show node 0 routing all char

2. The following example shows how to convert a command for setting a circuit's cost:

   decnet_migrate> convert command "set circuit una-0 cost 20" ! *** Converting the following NCP command to NCL: ! set circuit una-0 cost 20 create node 0 session control enable node 0 session control create node 0 nsp enable node 0 nsp create node 0 routing enable node 0 routing create node 0 routing circuit {{{una-0}}} enable node 0 routing circuit {{{una-0}}} set node 0 routing circuit {{{una-0}}} l1 cost=20

   
   The first create and enable commands are included to show how the DECnet Phase V circuit would be created and enabled. Usually, circuits are created and enabled when you bring up a DECnet Phase V node.

Converts NCP commands in a DCL command file to their closest NCL equivalents. Both the NCP and NCL commands are written to an output file.

The NCP commands in your DCL command file must appear in one of these formats:

$ ncp ncp-command $ mcr ncp ncp-command $ run device:[directory]ncp ncp-command . . . ncp-command $ $ ncp ncp-command . . . ncp-command $ $ mcr ncp ncp-command . . . ncp-command $

Anything else in your DCL command file is copied directly to the output file.

Syntax

decnet_migrate> convert dcl_file input_file [to output_file]

Arguments

input_file

Specifies the name of the DCL command file you are converting. The disk and directory names default to their current values. If you do not give a file extension, it defaults to .COM.

output_file

Optional. Specifies the name of the command file to contain the converted commands. If you do not specify an output file, the disk, directory name, file name, and file extension all default to those specified for input_file.

Examples

1. The following command converts the NCP commands in ncpsetup.com to their nearest NCL equivalents and puts the results in a file called nclsetup.com. See the convert command description for examples of how the converted commands appear in the output file.

   decnet_migrate> convert dcl_file ncpsetup.com to nclsetup.com

2. The following command converts the NCP commands in netstart.com to their nearest NCL equivalents and puts the results in a file with the same name:

   decnet_migrate> convert dcl_file netstart.com

Converts NCP commands in an NCP command file to their nearest NCL equivalents. Each NCP command is converted to an NCL command and both the NCP and NCL commands are written to an output file. The NCP commands are included as comments.

The commands in your NCP command file must appear exactly as they would be entered at the NCP> prompt.

Syntax

decnet_migrate> convert ncp_file input_file [to output_file]

Arguments

input_file

Specifies the name of the command file you are converting. The disk and directory names default to their current values. The file extension defaults to .COM.

output_file

Optional. Specifies the name of the command file to contain the converted commands. The disk, directory name, file name, and file extension all default to those of input_file.

Examples

1. The following command converts the NCP commands in the file ncpsetup.com to their nearest NCL equivalents and puts the results in a new file called nclsetup.com. See the convert command description for examples of how the converted commands appear in the output file.

   decnet_migrate> convert ncp_file ncpsetup.com to nclsetup

2. The following command converts the NCP commands in netstart.com to their nearest NCL equivalents and puts the results in a new file with the same name:

   decnet_migrate> convert ncp_file netstart

Creates a command file that the manager of a DECnet Phase V router product can use to create interphase link entries in the DECnet Phase V router's reachable address table. Interphase links enable a DECnet Phase V router running the DECnet Phase V link state protocol at level 2 to communicate with adjacent routers running the Phase IV routing vector protocol at level 2.

Whenever the level 2 network configuration changes, use this command to update the reachable address table on every DECnet Phase V level 2 router that has interphase links.

When you issue create ipl_initialization_file, the target DECnet Phase V routing node must be accessible and have a communication path to all areas in the level 2 link-state network. Additionally, the adjacent level 2 routers running the Phase IV routing vector protocol must have communication paths to all areas in their respective level 2 routing-vector networks.

The create ipl_initialization_file command creates three files:

• A DCL command file (named output_file) that contains a description of all the routing information gathered when you ran the create ipl_initialization_file command. When you run this command file, you are asked if you want to create or delete interphase link entries. Depending on your answer, the command file executes one of the other two files.
• An NCL command file that creates interphase link entries in the reachable address table on the target routing node. This file is named output_file_cre.
• An NCL command file that deletes interphase link entries from the reachable address table on the target routing node. This file is named output_file_del.

The following is one method for using the resulting NCL command file to set up interphase links on, for example, a DECnet Phase V router product:

1. Run the DECnet-Plus router configuration program to create the NCL script for the router's configuration.
2. Run the create ipl_initialization_file to create the NCL script for setting up interphase links.
3. Append the second NCL file to the first.
4. Compile the resulting NCL file into a CMIP file for loading into the router at reboot.

Before running the command file, you can edit output_file_cre to modify which interphase links are created. If you do this, you should make equivalent changes in output_file_del.

Syntax

decnet_migrate> create ipl_initialization_file output_file for node_name

Arguments

output_file

Specifies the name of the command file you are creating.

The disk and directory names default to their current values; the file extension defaults to .COM.

node_name

Specifies the full name (including any directories) or the Phase IV synonym of the level 2 routing node on which the interphase link entries are to be created.

Example

• In the following example, the create ipl_initialization_file command creates files called router_ini.com, router_ini.com_cre, and router_ini.com_del for the area09 router.

  decnet_migrate> create ipl_init router_ini for area09