Message packets sent over Ethernet are called datagrams. Because there is no guarantee that a datagram will be received by the intended destinations, reliable connections (in the form of virtual circuits) may be provided by a protocol being interposed between the user and the Ethernet datagram service. In DNA, this virtual circuit is provided by the Network Services Protocol (NSP) in the End Communication layer.

An Ethernet is a single shared network channel, with many nodes demanding equal access. The technique used to mediate these demands is Carrier Sense, Multiple Access with Collision Detect (CSMA/CD). CSMA/CD performs Ethernet Data Link layer access control.

The LAN term multiaccess refers to the ability of any station on the LAN to use the communications medium. On Ethernet, any station may begin transmitting if it senses that no other station is transmitting.

CSMA/CD is like a social gathering in that one person speaks at a time. Before speaking, one listens to determine if another person is speaking. If two or more people, detecting silence, begin speaking at the same time, they notice this and stop speaking. After a short interval, they each try to speak again. Because the length of this interval is randomly determined, usually one person starts before the other. The second person waits for the first to conclude.

The carrier sense function enables Ethernet stations to determine if the communication medium is already in use. Messages are said to be initially deferred if they are not sent on the Ethernet because a transmission is in progress.

If two or more stations begin transmitting at the same time, they detect this and stop transmitting. This is called collision detect. They wait for a random period of time before trying again; on Ethernet, this situation is known as backoff and retransmission, and a random delay before retransmission eventually clears the collision situation.

While Ethernet stations can hear every message, some messages are intended for all stations (broadcast address), some are intended for a subset (multicast address), and some are intended for individual stations (physical address).

The FDDI Data Link layer uses a timed token-passing protocol. The FDDI Data Link layer is divided into two sublayers: Media Access Control (MAC) and Logical Link Control (LLC).

FDDI requires LLC for proper ring operation. The LLC sublayer resides above the MAC sublayer. LLC controls the transmission of a frame of data between two nodes. LLC frames carry user information between nodes on an FDDI or other network. Each FDDI frame containing user data includes LLC information for the destination node. These frames cross bridges and can be transmitted to nodes on the extended LAN.

MAC functions include the following:

To gain the right to transmit on the FDDI LAN, stations must first acquire the token, which is a unique symbol sequence that circulates around the ring following a data transmission. Once a station acquires the token, it removes the token from the ring and begins transmitting data. At the end of tranmission, the station issues a new token onto the ring, providing other stations with the opportunity to transmit.

In VSI’s FDDI implementation, all attached stations use asynchronous data transmission to pass data around the ring. In asynchronous transmission, all attached stations are dynamically allocated a transmission time based on the TTRT. Stations acquire the token and transmit until the token holding time expires.

A point-to-point configuration consists of two systems connected by a single communication channel. Figure 1.3, “DDCMP Point-to-Point and Multipoint Connections” illustrates DDCMP point-to-point and multipoint configurations.

A multipoint configuration consists of two or more systems connected by a communications channel, with one of the systems (called the control station) controlling the channel. All other systems on the communications channel are known as tributaries. (Note that, if only two systems are connected in a multipoint configuration, one is the master and one is the tributary. However, this is not a very efficient use of the communication channel.) The control station is responsible for telling the tributaries, in turn, when they may use the channel; this procedure is known as polling. Tributaries are not allowed to use the channel until they are polled. The control station, however, may use the channel whenever it is available. Also, the tributaries on a multipoint line are not allowed to communicate directly with each other, but only through the master.

Point-to-point circuits and multipoint circuits perform as virtual circuits. Nodes on these circuits interact as though a specific circuit were dedicated to them throughout the transmission. However, the actual physical connection is allocated by the routing mechanism. Initialization of nodes on DDCMP circuits involves guaranteed delivery of routing messages. Also, individual nodes on DDCMP circuits must be addressed directly; no multicast or broadcast addressing capability is available as with an Ethernet or FDDI circuit.

You use synchronous communications devices for high-speed point-to-point or multipoint communication (for example, connecting two VAX–11/780 systems).

The synchronous DDCMP protocol can run in full- or half-duplex operation. This allows DDCMP the flexibility of being used for local synchronous communications, or for remote synchronous communications over a telephone line using a modem. DDCMP has been implemented in microcode in such devices as the DMC11 and DMR11 to run at speeds up to one megabit per second in a point-to-point configuration. The DDCMP multipoint protocol (point-to-point also) has been implemented in microcode in the DMP11 device to run at speeds up to 500 kilobits per second. For the DMF32, DDCMP has been implemented in the driver software for the synchronous communications port.

Asynchronous connections provide for low-speed, low-cost, point-to-point communication (for example, as an inexpensive way of connecting a MicroVAX system to a VAX–8000 series system). Asynchronous DDCMP is implemented in software and can be run over any directly connected terminal line that the VMS system supports. The asynchronous DDCMP protocol provides for a full-duplex connection and can be used for remote asynchronous communications over a telephone line using a modem. Asynchronous connections are not supported for maintenance operations or for controller loopback testing.

A static asynchronous DDCMP connection is a permanent DECnet connection between two nodes physically connected by terminal lines. You convert the terminal lines to static asynchronous DDCMP lines by issuing commands to set the lines to support the DDCMP protocol. The user at each node then turns the appropriate circuits and lines on for DECnet use. After the communications link is established, it remains available until a user turns off the circuit and line and clears the entries from the DECnet database.

Static asynchronous DDCMP configurations require the asynchronous DDCMP driver to be connected. The asynchronous DDCMP protocol can run in full-duplex operation on local asynchronous communication devices. Examples of these devices are the DZ11 and the DMF32 asynchronous communications port.

You can configure a dialup line as either a static or dynamic asynchronous line, but may find the dynamic connection more secure and convenient to use.

A dynamic asynchronous connection is a temporary connection between two nodes, generally over a telephone line using modems. The terminal lines at both ends of the connection can be switched to asynchronous DDCMP communications lines and then switched back to terminal lines.

You can use dynamic asynchronous connections to establish a DECnet link to another computer for a limited time or to create links to different computers at different times.

For example, as a user of a personal computer (non-VMS), you can cause a dynamic asynchronous connection to be made for the length of the telephone call to a VAX–8000 series system. First establish a process on your system as a terminal emulator (enabling the remote connection to look like a local connection). You dial in over a telephone line to a process on the other system (which is established as a virtual terminal) and log in. You can then enter a command that causes the terminal lines at each end of the connection to be switched to DDCMP mode for DECnet use. When you hang up the telephone or turn off the circuit, the lines are automatically switched back to terminal lines.

Security measures provide protection against a caller at an unauthorized node forming a dynamic asynchronous connection with another node (see Section 2.8.6, “Security for DDCMP Point-to-Point Connections”). Before a dialup node can establish a dynamic connection with a remote node, the remote node verifies that the dialup node is authorized to make a connection. It checks that the node is of the appropriate type (router or end node), and, without revealing its own password, verifies the routing initialization password sent by the dialup node. Also, for increased security, the connection is ended automatically when the telephone is hung up, if your modem and system are set up and wired to enable this to occur..

You can establish a dynamic asynchronous connection over a hardwired terminal line. The connection is maintained for the duration of the DECnet session. The dynamic connection permits the system to be used as a terminal emulator when not switched to DECnet use.

If you use only one physical link to connect each VAXcluster node to the network, use the Ethernet or FDDI link instead of the CI data link, to get better performance. In this case, the CI should perform the functions of a system bus and not be enabled as a DECnet data link.

If the nodes in the cluster are not connected to a LAN, use the CI as the DECnet data link between the nodes. CI circuit devices are configured as though they were multipoint devices, but each node on the CI can talk directly to every other node and no polling is involved.

Configure at least one node as a router if more than two cluster nodes use the CI to communicate. If the VAXcluster has two nodes, both can be end nodes. For a cluster of four or more nodes, configure at least two routers to prevent the loss of communications capability between the remaining nodes if one router fails. Also, you can provide backup circuits between end nodes in case of router failure.

You can configure a VMScluster so that the whole cluster appears to other network nodes as though it were a single node, with an address different from that of any DECnet node within the cluster. This address usually has a node name associated with it. Thus, you can access the cluster as a whole by an alias node identifier, which can be either its node name or its node address.

All or some of the nodes in a cluster can elect to use this special node identifier as an alias, while retaining their unique individual node names and addresses.

Each node that assumes the alias node identifier can specify whether it will accept incoming connections directed to the alias address. It can also specify the network services for which the cluster alias node identifier is to be used on outgoing connections and the network services that will accept incoming calls.

At least one of the nodes in the cluster that uses the alias node identifier must be a router. The router informs other nodes in the network of the alias node address for the cluster. When the router receives packets addressed to the alias node address, it forwards them to the appropriate nodes in the cluster. The cluster alias node identifier can be very useful in network operations involving shareable resources. Network users outside the cluster can access cluster resources without knowing which nodes are active in the cluster. For example, if a user on a cluster node sends a MAIL message, it does not matter whether that particular node is active when a reply to the message is received.

At the outset, the system manager is responsible for configuring the network from the perspective of local node network operation. This involves supplying information at the local node about various network components such as nodes, circuits, lines, and objects. This information constitutes the configuration databases for the local node. Each node in the network has configuration databases. You supply information about the configuration databases through NCP.

If you are configuring a DECnet for OpenVMS node for the first time or want to completely rebuild the configuration databases for your local node, you can use the interactive NETCONFIG.COM procedure in SYS$MANAGER to configure your node.

If supplied on your system, you can use the interactive NETCONFIG_ UPDATE.COM procedure in SYS$UPDATE to alter your system’s default access options for network objects. The NETCONFIG_UPDATE.COM procedure performs no other network configuration. When you use the NETCONFIG_UPDATE.COM procedure to specify changes to default access for network objects, everything else in the configuration database remains unchanged.

To update an existing node database to contain current information about other nodes in the network, you can copy the information from the node database of another node to which you have access.

Chapter 3, Managing and Monitoring the Network discusses the function of the configuration database and the general use of NCP and most NCP commands. Chapter 5, Configuring a Network describes how to use the NETCONFIG.COM procedure to configure your node, and presents sample configuration commands for various network configurations. The VSI OpenVMS DECnet Network Management Utilities contains a summary description of NCP operation, command prompting, and the syntax of all NCP commands.

Figure 1.5, “Topology of a Single-Area DECnet Network” illustrates a hypothetical network topology in a single area. Figure 1.6, “Topology of a Multiple-Area DECnet Network” illustrates the same topology for a network that has been divided into multiple areas. These configurations are referred to as the “network examples” throughout this manual.

These components, the DECnet software modules and databases, and the hardware make up the network. NCP command examples in this manual relate to the components illustrated in the network example.

DECnet for OpenVMS supports network applications programming to access remote files and create tasks that exchange information across the network. You can use:

The way you access the network is directly related to the language you use and the network operation you perform.

For example, you may want to use standard VMS RMS calls in a VAX MACRO program to access remote files, then use system service calls to communicate between MACRO programs in a task-to-task communication application.

Figure 1.7, “DECnet for OpenVMS Programming Interfaces and Network Access Types” shows three access levels and the corresponding network operations. The various levels of network access provide a convenient context in which to discuss typical user operations over the network.

DCL and RMS are entirely transparent to the network user. Because you use standard DCL commands and RMS service calls to access remote files, no DECnet-specific calls are required at these levels of access. You need only specify in your file specification the remote node on which the file resides. Likewise, higher-level language tasks can use a variation of the standard OpenVMS file specification in conjunction with standard I/O statements to access remote tasks and exchange information; thus, this form of task-to-task communication is also transparent. As with device-independent I/O operations, transparent network access allows you to move data across the network with little concern for the way this operation is performed.

System services provide both a transparent and a nontransparent user interface to the network. Transparent communication at the system-service level provides all the basic functions necessary for two tasks to exchange messages over the network. As with the higher-level language I/O interface, these operations are transparent because they do not require DECnet-specific calls. Rather, you use standard system service calls to implement them. Nontransparent communication extends this basic set of functions to allow a nontransparent task to receive multiple inbound connections and to use additional network protocol features such as optional user data and interrupt messages. As with devicedependent I/O, nontransparent communication allows you to exploit certain network-specific characteristics to coordinate a more controlled communication environment for exchanging information.

TRNTO"SMITH JOHN"::WORK_DISK:TEST.DAT;1

This file specification contains explicit access control information and can be used to access the file TEST.DAT, which resides in user Smith's top-level directory on the device WORK_DISK on node TRNTO.

TRNTO::DBA1:[SMITH]TEST.DAT;1

For more information about file specification strings, including format examples, see the VSI OpenVMS User's Manual.

BOSTON::"TASK=TEST2"

BOSTON"JONES KC"::"0=TEST2"

This task specification string also identifies the task TEST2. Note that, in this case, explicit access control information is also included in the node specification string. For more information about task specifications, see Chapter 8, Performing Network User Operations.

Access control is the control that a node exercises over inbound logical link connections. The terms inbound and outbound refer to the direction of the logical link connection request. A node receives and processes inbound requests; it processes and sends outbound requests. This distinction is useful for discussing access control as it relates to VMS nodes in a network. If the node to which you want to connect is not on a VMS operating system, refer to appropriate DECnet documentation.

When DECnet software sends an outbound connection request in response to either a remote file access or a task-to-task communication operation, you may need certain access control information to connect successfully to the remote node and to log in. As in logging in at your local node, you can supply specific access control information in the form of a user name and password that the remote node recognizes. The remote node processes inbound connection requests containing this information to verify that you are a valid user of the system. For more information about inbound and outbound connection requests, see Section 2.8.2, “System-Level Access Control”.

Figure 1.8, “Remote File Access Using Access Control String Information” illustrates the access control processing that takes place for a DCL command.

When you do not provide explicit access control information in the connection request, DECnet for OpenVMS software uses the remote node name specified in the connection request as a key to locate the appropriate record in the local configuration database. This record contains default access control information applicable to the remote node. Your system manager creates this entry when establishing the configuration database. (For additional information about the configuration database, refer to Chapter 3, Managing and Monitoring the Network.)

Depending on the privileges required by the object to which you want to connect and those of the user process (see Figure 1.9, “Remote File Access Using Default Access Control Information”), one of three possible sets of default access control information is sent to the remote node: default privileged, default nonprivileged, or null.

Because these defaults are node parameters, all privileged operations requested with default access control for a given node run under the same default account. The same is true for nonprivileged operations requested with default access control.

If the target node is running DECnet for OpenVMS, it can associate incoming connect requests with specific accounts other than a default nonprivileged DECnet account. See Section 2.6, “Objects” and Section 5.2.2, “Using NETCONFIG.COM” for details.

Figure 1.9, “Remote File Access Using Default Access Control Information” illustrates the access control processing that takes place for the same DCL command as in the example in Figure 1.8, “Remote File Access Using Access Control String Information”, except that the DCL command does not specify an access control string.

Using logical names for network operations allows you to refer to network file and task specifications without using actual names that you give these elements. Logical names serve as a kind of shorthand for specifying all or a portion of a full file specification. By using logical names, you can pass file specifications defined at the DCL level to an executing image at runtime. For example, logical names allow a program to access local or remote files without changing the program. You can also use logical names to conceal access control information from other users by embedding it in a logical name defined in the process logical name table. Logical names provide convenient and powerful multilevel access control specification.

For more information about logical names, including examples of logical names that can be used for network applications, see the VSI OpenVMS User's Manual.

To update your configuration database with current information about remote nodes in your network, you can copy the names and addresses of remote nodes from the database of another node to which you have access. Specify the node database (volatile or permanent) to be copied, and the local node database (volatile, permanent, or both) to which information is to be copied.

If you clear or purge your local node database before copying the remote node data, you can avoid possible conflicts between original and updated data. The executor node information is preserved during the clear or purge operation.

Copying a permanent node database permits you to keep your network information current even if you are part of a large network that changes frequently. Alternatively, if you configure your node without a permanent node database, you can obtain current information on other nodes in the network by copying it from another node (for example, from a node on your Ethernet that serves as a master by keeping its node database up to date).

You can limit use of the alias for incoming and selected outgoing connections.

You then have the option of indicating whether you want to use the alias for incoming and selected outgoing connections.

You can indicate whether your node will accept incoming connection requests directed to the alias node address. By default, a node that assumes the alias is available to receive incoming connections addressed to the alias, but a small node that uses the alias for outgoing traffic may elect not to handle the extra incoming traffic. You can also select which DECnet for OpenVMS objects (software components that provide network services) are to use the alias by specifying in the object database that the alias address is to be used for outgoing connections originated by those objects. In addition, you can specify which objects will receive incoming connect requests directed to the alias node address.

MAIL is an example of a network object that can effectively treat the cluster as a single node. Ordinarily, replies to mail messages are directed to the node that originated the message; the reply is not delivered if that node is not available. If the node is in a cluster and uses the cluster alias, an outgoing mail message is identified by the alias node address rather than the individual address of the originating node. An incoming reply directed to the alias address is given to any active node in the cluster and is delivered to the originator's mail file.

Objects that involve multiple incoming links (such as PHONE) should not use the alias node address because each incoming link may be routed to a different node that uses the same alias. Also, objects whose resources are not accessible clusterwide should not be allowed to receive incoming connect requests directed to the alias node address. Section 2.6, “Objects” describes network objects and discusses the type of object for which the alias node identifier is suitable.

The alias node identifier permits you to set a proxy to a remote node for the whole cluster rather than for each node in the cluster. The clusterwide proxy can be useful if the alias node address is used for outgoing connections originated by the object FAL, which accesses the file system.

At least one of the VMScluster nodes that uses the alias node identifier must be a router. It can be a level 1 router, because all cluster nodes sharing the same alias node address must be in the same area.

The cluster router informs other nodes in the network of the existence of the alias node address. Other routers in the network perceive the cluster router as the shortest path to the cluster node address and send the router packets addressed to the cluster node address. If the cluster router receives a packet addressed to the alias node address, it forwards the packet to the appropriate cluster node. If the packet is for an existing logical link, the link identifier in the packet is sufficient to select the node. If the packet is initiating a new logical link, the router selects a participating node in circular fashion.

The network manager or cluster manager should select a suitable alias node name and address for the cluster nodes. You can specify either the alias node name or address as an executor parameter in your node database. If you specify the alias node name, you must first have associated the name with the agreed-upon alias node address. You can then assign the same parameters to this node as to other nodes, except that routing initialization passwords are not required. No point-to-point initialization can occur because a node cannot set up a circuit to an alias node address. The alias node address and name appear in the node databases of other nodes in the network.

You can optionally set a maximum value on the number of logical links that your node can initiate using the alias node identifier (see Section 2.5, “Logical Links”).

The DMC11 and the DMR11 are point-to-point line devices and are considered identical. The DMP11 can be either a point-to-point, multipoint control, or multipoint tributary line device. The DMV11 is similar to the DMP11; DECnet refers to either device as the DMP11. The DMB32 and DSB32 synchronous line units are point-to-point devices.

The asynchronous line devices are point-to-point line devices used for static or dynamic asynchronous connections.

Asynchronous DDCMP lines need not be predefined for dynamic connections. They are established automatically when a dynamic asynchronous DDCMP connection is made (see Section 2.3.2.3, “Dynamic Asynchronous Lines”).

Every DDCMP line provides a point-to-point connection between two nodes. Circuits, the actual communications path, operate over the line. The DMP11 and DMV11 also provide a multipoint connection between two or more nodes. In Figure 2.2, “Multipoint Lines” a multipoint line controlled by the DMP11 provides the physical connection between a control node and several tributary nodes.

You can connect two multipoint lines to the same node. The node could then serve as the control station for one multipoint line and as a tributary for another multipoint line.

Because a heterogeneous network may have DDCMP line devices other than one of the preceding, become familiar with the entire range of devices and their impact on network management. If a node in your network uses a line device other than these, refer to the appropriate DECnet documentation.

A static asynchronous DDCMP connection is a permanent connection established between two nodes (such as a router node and an end node). The two nodes are connected by either a modem or by a physical line attached to a terminal port at each end (for example, port TTA0 on the end node and port TXB7 on the router).

A static asynchronous connection can also be made over a dialup line.

Before the DECnet connection is made, the terminal lines must be converted to static asynchronous DDCMP lines. Each terminal port must have an asynchronous DDCMP line device installed, and the system manager at each node must load the asynchronous DDCMP driver, NODRIVER.

The commands required to install static asynchronous lines and the NCP commands to configure a network using static asynchronous lines are given in Section 5.2.3.3, “Installing Static Asynchronous Lines”.

A dynamic asynchronous line differs from a static asynchronous line or other DECnet for OpenVMS line in that it is normally switched on for network use only for the duration of a dialup connection between two nodes. When the telephone is hung up, the line reverts to being a terminal line.

Dynamic switching of terminal lines to asynchronous DDCMP lines can occur provided both nodes have DECnet installed. Assuming that both the remote node and the local node are VMS operating systems, the system manager at each node must have loaded the asynchronous driver NODRIVER and installed the privileged shareable image DYNSWITCH. (If the local node is a personal computer, there is no need to load NODRIVER and install DYNSWITCH.)

The commands required to install static asynchronous lines and the NCP commands to configure a network using static asynchronous lines are given in Section 5.2.3.4, “Installing Dynamic Asynchronous Lines”.

An area can contain many level 1 routers and end nodes, and must contain at least one level 2 router to provide the connection to other areas. A level 1 router acts as a standard routing node. It keeps information on the state of nodes within its own area. Level 1 routing nodes and end nodes obtain access to nodes in other areas through a level 2 router residing in their own area.

If there are two or more routers on the same LAN, one of them is elected as the designated router. By convention, the router with the highest numerical priority (the router priority parameter is set as a CIRCUIT characteristic in its database) is elected router for the circuit. In case of a tie, the node with the highest address is elected as the designated router. The function of the designated router is to route messages over the Ethernet on behalf of end nodes. A designated router is elected even if there are no end nodes currently on the Ethernet.

End nodes can also exchange messages directly without using a router. Routers are needed, however, when messages are to be routed to nodes off the LAN.

End nodes are informed of the identity of the designated router on that LAN. End nodes transmit multicast hello messages, so that routers know of their presence on the LAN. End nodes keep no information about the network configuration, except that they are permitted to keep a cache of nodes within their area that they may address directly on the LAN, rather than going through a router (see Section 2.4.5.2, “Ethernet or FDDI End Node Caching”). Thus, an end node may send a packet directly to another Ethernet end node, if the address has been cached, or it may send a packet to the designated router for forwarding.

End nodes can exist on a LAN without a router. When an end node on the LAN wants to communicate with another end node, and notes that no designated router exists, it always sends the packet directly to the addressed node using the LAN address derived from the DECnet address. If the addressed node is active, the sender receives a reply; if the addressed node is not available, a timeout occurs.

End nodes normally send packets by means of a router. To minimize the space and time overhead involved in the routing function on Ethernet or FDDI LAN circuits, a caching mechanism is available that takes advantage of the fact that nodes on a LAN are logically one hop away from each other (one hop is the distance between two adjacent nodes).

An end node maintains a cache of limited size of the addresses of the target nodes with which it has had contact. When a designated router is present and an end node is ready to send a packet to a specific target node for the first time, the end node sends the packet to the designated router, which in turn forwards the packet to the target node. When there is no designated router on the circuit, the end node sends the packet directly, because it expects that the other node is there.

By means of the acknowledgment messages it receives, the end node builds its cache of addresses of specific nodes. If a response is received from the target node, the end node examines the received packet for the existence of specific bits (the bits are checked even if the first packet went to the designated router).

If the intra-LAN bit is set, which indicates that the target node is on the same LAN as the end node, then the next packet can be sent directly, rather than by means of the designated router. If the received packet has the intra-LAN bit clear (which indicates that the target node is not on the same LAN as the end node, but is reachable through a routing node that is on the LAN), then the next packet can be sent from the end node to the target node via a routing node, rather than by means of the designated router.

In summary, the end node uses the acknowledgment messages it receives to build a cache of addresses of target nodes that either are on the same LAN or can be reached through a node on the LAN. This mechanism is called reverse path caching.

All nodes on an Ethernet bus or FDDI ring need not be in the same area; you can configure more than one area on a single LAN. The areas on the same LAN are logically separate from each other.

When you configure two level 1 routing nodes on a LAN in different areas, the nodes do not communicate directly with each other. Each level 1 router communicates with a level 2 router in its own area, which sends the message to a level 2 router in the other area. The level 2 router that receives the message then transmits it to the second level 1 router.

You can configure a two-node VAXcluster that uses a CI data link using end nodes only, but at least one router is required if additional nodes are configured in the cluster. The CI protocol does not include the multiaccess capabilities of the Ethernet or FDDI protocols.

One or more CI routers are necessary if a VAXcluster consists of three or more nodes. CI circuit devices are treated as though they were multipoint devices (like the DMP device) rather than as multiaccess devices such as the Ethernet or FDDI circuit device. Although only one router is required in a cluster of more than two nodes, having more routers in the cluster environment increases the overall availability of the network within the cluster.

If the cluster configuration includes end nodes as well as routers, a backup, higher-cost circuit could be provided for each end node. This backup circuit could take over if the primary circuit connecting the end node to its router fails (see Section 3.7.6, “CI End Node Circuit Failover”).

End nodes communicating through a router send all data through that router even though they are connected to the same CI. You achieve the best performance and availability by defining all cluster nodes as routers if the CI is used as the data link.

The number of nodes that Phase IV DECnet can support in a single-area network was increased to a maximum of 1023 from the limit of 256 for Phase III DECnet. This increase was due to changes in the routing update messages. In Phase III, a legal network was restricted in size to the number of nodes for which cost and hop information could be fit into a single routing update message. Furthermore, Phase III routers had to send complete updates containing information about all nodes, whether or not their reachability had changed. Phase IV allows segmented routing messages to be sent, that is, messages that contain only the information that has been changed. Phase IV also permits routing updates to be sent in multiple messages. Therefore, the size of the routing messages and the number of buffers required to receive them are reduced.

The network manager can set a timer for transmission of routing messages, controlling the intervals at which nonconfiguration change routing updates are transmitted. The routing timer controls the frequency of transmission of these messages on non-LAN circuits. The broadcast routing timer controls their frequency for Ethernet or FDDI broadcast circuits. Expiration of the broadcast routing timer causes the local node to send a multicast routing configuration message to all routers on the LAN.

The system manager can specify default access control information for outbound connections. This enables the local node to send outbound logical link requests with default access control information when that information is not explicitly provided. The remote node stores the access control information in its configuration database. The default access control information can include privileged and nonprivileged names and passwords to be used in connecting to a particular remote node.

The system manager at a node can specify a list of privileges required for connection to a particular object, such as NML. When the local node requests connection to an object for which privileges have been specified, it sends the default privileged access control string to the remote node. If the system manager does not specify privileges for an object, such as FAL, the object is accessible to all users. When the local node requests connection to this object, it sends the nonprivileged access control string.

Figure 2.4, “Access Control for Inbound Connections” illustrates the local node's access control options for inbound connection requests.

Regardless of the source, the remote node uses this access control information to determine whether a logical link can be established. The way this validation process works is important for both the system manager and network users. This section discusses access control in terms of network management. Chapter 8, Performing Network User Operations discusses access control as it relates to user-level operations such as remote file access and task-to-task communication.

Access control information is not used where the connection is to a program that has declared a name or object number and has started independently of DECnet.

Access control information allows users on remote nodes to gain access to resources on the local node. The system manager must establish access control information in both the configuration database (for objects) and the UAF (for default network accounts) on the local node. Chapter 1, Overview of DECnet for OpenVMS briefly describes the necessity for these default accounts. Chapter 5, Configuring a Network explains how to create a default nonprivileged DECnet account.

Whenever NETACP on the local node receives an inbound logical link connection request, it creates a process and starts the LOGINOUT image, which verifies the user's access rights by checking the UAF. When the VMS operating system starts a user process as a result of an inbound connection request, the privileges with which that process runs are determined by the UAF record associated with the access control information passed in the connection message. This function is almost identical to the one that occurs whenever a local user starts a batch job; the difference is that the resulting LOG file is neither printed nor deleted. Section 2.6, “Objects” discusses this process in detail.

You can maintain password security in a network environment by protecting the network configuration files from unauthorized access. The most convenient way to do this is to require SYSPRV to access these files. NML must have access to network configuration files. NML on the remote node accesses these files when it sees the NCP commands that access the permanent database (DEFINE, PURGE, LIST, and SET “component” ALL).

Table 5.1, “Privileges for NCP Operations” lists the privileges you need to perform network operations.

Avoid assigning privileges beyond those normally used. In particular, do not give the default privileged account SYSPRV. Place these default accounts in their own group to avoid extending group access to other directories on the local node. You can protect sensitive files and directories against world access by requiring explicit access control to reach them.

Another form of access control specific to network objects is default account information used by inbound connects from remote nodes that send no access control information. Because no access control information is supplied, the default information you specify for the object is used to allow the logical link connection to be made.

Proxy accounts permit users on remote nodes to obtain access rights on other nodes without having private accounts on those nodes. The remote user can enter commands to access data that is accessible by one or more local accounts to which that remote user has proxy access.

LARK::KELLEY
RSTS::[23,55]

In the first example, the remote user is identified by the node name LARK and user name KELLEY. The second example specifies that a UIC is to be used instead of a user name to identify the user as member 55 in group 23.

In the permanent proxy database, each remote user may be mapped to one default proxy account and up to 15 additional proxy accounts on the local node. With a default proxy account, the remote user does not need to specify a user name or password when requesting proxy login. With a nondefault proxy account, the remote user must include a user name only.

For a summary description of proxy accounts and how to create them, see the VSI OpenVMS Guide to System Security.

The permanent proxy database resides in NETPROXY.DAT. All management and maintenance of this database is handled through the Authorize Utility. NETPROXY.DAT is updated automatically any time you use the Authorize Utility to make any changes to proxy logins. When DECnet is started up, the information in NETPROXY.DAT is used to construct a volatile database in the NETACP process. NETACP consults this volatile database when incoming proxy login requests are received at the local node. When you change the proxy database, the volatile database is updated if DECnet is running.

When the local node receives a request for initiation of an inbound connection, and if no access control string is supplied and the remote node is enabled for outgoing proxy login access, the local system checks to see if the object has incoming proxy enabled. If proxy access is enabled, NETACP checks its volatile database to determine whether the user should be allowed to log into a designated account.

By default, both incoming and outgoing proxy login access are enabled at the local (executor) node. Consequently, incoming and outgoing proxy login access is permitted with all remote nodes. These default values are established by DECnet for OpenVMS to permit proxy logins to be initiated by the local node or by the remote node. These default values are the recommended settings.

Just as you can control proxy login access by individual accounts, you can control proxy login access by network objects. You control proxy login access to a specific network object by setting the value of the object parameter PROXY in the configuration database. The database contains defaults for each object. Permitting proxy login access to an object is recommended only if the proxy access serves some useful purpose. For example, by default MAIL is set to prevent incoming proxy login, while FAL is set to allow both incoming and outgoing proxy login.

Note that whatever you declare for the object proxy database takes precedence over the values declared in the executor proxy database.

Note that there are advantages to disallowing incoming proxy access to an object (such as MAIL) that does not require it. Whenever possible, incoming connect requests are matched up with compatible existing NETSERVER processes, to avoid the overhead of unnecessary process creation. If the object disallows incoming proxy access, incoming connect requests will use default access control, with a higher probability of being matched with an existing NETSERVER process.

The SET EXECUTOR NODE command sets the executor to the node at which you want the commands to execute. One use of this feature is to display information about the configuration database of the remote node. Figure 3.1, “Remote Command Execution” illustrates this use of a remote executor node.

NCP> SET EXECUTOR NODE TRNTO

NCP executes commands that you enter at your local node, BOSTON, at the remote executor node, TRNTO. The executor node interprets each command with its own network management software, and then performs the NCP function. In this example, any information output that results from the execution of a command is displayed at node BOSTON.

NCP> CLEAR EXECUTOR NODE

The executor is always the local node when NCP is activated. Several users at one node can set their executor to different nodes.

NCP> TELL TRNTO SHOW KNOWN LINES

Remote execution in this case applies only to the one command entered with the TELL prefix. Again, you can specify or default to access control information.

You establish an alias node identifier for the local node using the SET EXECUTOR command with the ALIAS NODE parameter. When the local node includes an alias node identifier in its database, it can be accessed by either the cluster alias or its individual node name or node address.

NCP> DEFINE NODE 2.13 NAME CLUSTR

NCP> DEFINE EXECUTOR ALIAS NODE CLUSTR

By entering these commands, you establish a node (CLUSTR) whose address is 2.13. This is the cluster alias node. Its address and name appear in the database like those of all other nodes. From the viewpoint of any node in the network outside the cluster, address 2.13, which is named CLUSTR, appears to be a real DECnet node that can participate in two-way communication. This cluster alias acts as a single node identifier that all participating nodes in the cluster can use to communicate with other nodes in the DECnet network.

When you manage the cluster alias node, you must decide whether participating nodes will accept incoming connect requests directed toward the cluster alias node identifier. You use the executor parameter ALIAS INCOMING to specify how incoming connect requests are to be handled. This parameter must be either enabled or disabled. To permit the node to accept incoming connect requests directed to the cluster alias node identifier, specify the ENABLED option. Otherwise, specify the DISABLED option to avoid receiving incoming connect requests directed to the cluster alias node identifier.

NCP> DEFINE EXECUTOR ALIAS INCOMING DISABLED

By default, the ALIAS INCOMING parameter is enabled for a node if an alias node identifier has been defined for the node.

Several executor parameters regulate various aspects of transport operation. Specify the size of NSP receive buffers and transmit buffers (segment buffers) and the number of buffers used to transmit on all circuits. NCP provides three executor parameters for this purpose: BUFFER SIZE, SEGMENT BUFFER SIZE, and MAXIMUM BUFFERS. Be careful to set the values for these parameters to a reasonable level, or system performance may suffer. The parameters all have reasonable default values.

Setting Buffer Sizes

NCP> SET EXECUTOR BUFFER SIZE 576

This parameter also controls the maximum segment size of all NSP messages that the local node can receive and forward. The buffer size value that you select is used for all lines. You cannot use the BUFFER SIZE parameter to select individual values for individual lines. You can, however, use the BUFFER SIZE parameter in the SET LINE command to override the BUFFER SIZE value set in the executor for specific lines, such as a particular Ethernet or FDDI line. (see Section 3.6.2.2, “Buffer Size”).

The default BUFFER SIZE value is equal to the SEGMENT BUFFER SIZE if specified; otherwise, the default size is 576 bytes. At a minimum, the buffer size must be 192 bytes. For more information in this area, refer to Chapter 5, Configuring a Network and to the Network Services Protocol Functional Specification.

Changing Buffer Sizes

You can change the size of the buffers on all nodes without bringing down the entire network by performing a two-pass conversion process involving a second parameter, the SEGMENT BUFFER SIZE, as well as the BUFFER SIZE parameter. The conversion process requires only that you set the local node to the OFF state while changing the buffer size.

NCP> SET EXECUTOR SEGMENT BUFFER SIZE 576

NCP> SET EXECUTOR BUFFER SIZE 576

The SEGMENT BUFFER SIZE normally has the same value as the BUFFER SIZE, but may be set to less in order to perform the buffer size conversion process.

This two-step process ensures that all nodes are able to receive and forward larger messages before any node is able to transmit a larger message.

This process ensures that the size of messages that can be transmitted across the network is decreased before the size of the buffers that receive and forward messages is decreased.

NCP> SET EXECUTOR BUFFER SIZE 1000

NCP> SET EXECUTOR SEGMENT BUFFER SIZE 1000

Each node will first be able to receive and forward 1000-byte messages, and then will be able to transmit them.

Maximum Number of Buffers

NCP> SET EXECUTOR MAXIMUM BUFFERS 20

If you do not specify a value for this parameter, DECnet for OpenVMS provides a default value of 100. Thus, you do not have to specify a value unless you want to limit the amount of nonpaged pool used by DECnet for OpenVMS. For most operations, DECnet for OpenVMS allocates only as many buffers as it needs (even if you specify a greater number than the amount needed), and does not allocate more than the number of buffers you specify.

Maximum Number of Circuits

NCP> SET EXECUTOR MAXIMUM CIRCUITS 3

The default value for this parameter is 16.

You cannot change the value of the MAXIMUM CIRCUITS parameter while the executor is in the ON state.

Any network user with the OPER privilege can initiate or confirm a logical link connection even though the local node is in the RESTRICTED or SHUT state. Thus, a system manager can use NCP and NML when the network is in either of these states.

The COPY KNOWN NODES command causes the names and addresses of remote nodes to be copied from a remote database to the local node database or databases you specify. The FROM node-id parameter in the COPY command specifies the remote node from which the node database information is to be copied.

NCP> COPY KNOWN NODES FROM BOSTON"BROWN PASS123"

To indicate which node database at the remote node is to be copied, specify the USING VOLATILE or USING PERMANENT qualifier. If you do not specify the USING qualifier, the default value is USING VOLATILE.

NCP> COPY KNOWN NODES FROM BANGOR USING VOLATILE TO BOTH

If you do not specify the TO qualifier, the local database defaults to VOLATILE.

NCP> COPY KNOWN NODES FROM BANGOR USING PERMANENT -
_ TO PERMANENT WITH PURGE

During a copy operation, if the volatile database is to be cleared, the entries for the executor node and any loop nodes are not cleared. If the permanent database is to be purged, however, the entry for the executor node is purged. Therefore, before the purge occurs, the copy operation causes the executor node characteristics to be saved: a LIST EXECUTOR CHARACTERISTICS command is executed and the executor characteristics are stored. After the purge is executed, the executor characteristics are reinserted in the local node database.

In addition, the local node must retain the name and address of the remote node from which it is to copy the data. Before the clear or purge operation is performed, the name and address of the remote node are saved. This information is reinserted in the local node database after the clear or purge operation is completed. Thus, to purge your database without purging your executor database, use the COPY KNOWN NODES command with the WITH PURGE qualifier.

Note that if the executor or remote node is not defined in the local node database, an error results.

If an error occurs during execution of the LIST EXECUTOR CHARACTERISTICS command, the purge is aborted. After the LIST operation is performed, purging continues even if errors are encountered.

Clearing or purging the local database as part of a copy operation is recommended. If a clear or purge operation is not performed before the remote node data is copied, conflicts can occur between original node entries in the local database and node entries being copied from the remote node database. A node must be identified uniquely, by one name and one address. A conflict exists when the entries being copied on an existing database would cause one node address to be associated with two node names or two node addresses with one node name. When such a conflict occurs during the copy operation, the original node entry is not updated and an informational message is displayed. For example, if the local node database identified node A with address 3.1 and node B with address 3.3, an attempt to copy an entry that defines node A with address 3.3 would fail, and an informational message would be issued.

When the name and address of the remote node from which the data is being copied is returned, the entry indicates that it is the executor node. When the remote node is defined in the local database, however, it is not listed as an executor node. Loop node names listed in the node database at the remote node are not defined in the local database.

After the COPY operation begins defining the remote nodes, it continues trying to define the nodes despite any errors it may encounter. It displays informational messages for errors in individual node entries.

The following examples illustrate how to use the COPY command to copy remote node entries from the permanent node database at node ROBIN to the permanent node database at node LARK without purging the local node database. In this example, node LARK has not defined the executor node or remote node ROBIN in its database; therefore, error messages are displayed. Note that the copy operation is not performed for nodes A and C, because of a conflict between existing and updated addresses for these nodes. Informational messages display for the entries for nodes A and C. (In the first example, only the node entries resulting from the LIST commands are displayed.)

NCP> LIST KNOWN NODES
    Remote node = 2.1 (C)
    Remote node = 2.3 (A)

NCP> TELL 2.20 LIST KNOWN NODES
    Executor node = 2.20 (ROBIN)
    Remote node = 2.1 (A)
    Remote node = 2.2 (B)
    Remote node = 2.3 (C)

NCP> COPY KNOWN NODES FROM 2.20 USING PERMANENT
%NCP-W-UNRCMP, Unrecognized component, Node
%NCP-W-EXEABO, Executor characteristics not defined.
%NCP-W-UNRCMP, Unrecognized component, Node
%NCP-W-REMABO, Remote node not defined.
%NCP-W-INVPVA, Invalid parameter value, Address
Remote node = 2.1 (C)
NODE  2.1    NAME A
%NCP-W-INVPVA, Invalid parameter value, Address
Remote node = 2.3 (A)
NODE  2.3    NAME C

The error messages generated during the copy operation are displayed on your screen directly under the COPY command. Note that remote node entries successfully copied to the local node database (such as node B) are not displayed under the COPY command. The COPY command ignores these error messages because they do not affect the copy operation.

NCP> LIST KNOWN NODES
    Remote node = 2.1 (C)
    Remote node = 2.2 (B)
    Remote node = 2.3 (A)
    Remote node = 2.20 (ROBIN)

Rather than using the NCP command COPY KNOWN NODES to copy node database information, you can use the DCL COPY command to obtain the contents of an existing permanent node database residing on a remote node in the file SYS$SYSTEM:NETNODE_REMOTE.DAT. You must have the required privileges on the remote node to access this file.

$ COPY BOSTON::SYS$SYSTEM:NETNODE_REMOTE.DAT *

NCP> SET KNOWN NODES ALL

dev-cdev-c-udev-c.tdev-c-u.t

DDCMP Point-to-Point Addressing

NCP> SET CIRCUIT DMB-0 STATE ON

NCP> SET CIRCUIT TT-0-0 STATE ON

Dynamic asynchronous DDCMP circuit names are supplied automatically when you establish a dynamic connection. Note that you must load the asynchronous driver NODRIVER before establishing a dynamic connection.

The DECnet for OpenVMS maps network management circuit names to system-specific circuit names (for example, DMB–0 maps to SIA0). Network management circuit names provide network-wide circuit identification independent of individual operating system conventions.

DDCMP Multipoint Tributary Addressing

NCP> SET CIRCUIT DMP-0.1 STATE ON

Use the SET CIRCUIT command to turn on the DMP circuit device as a multipoint tributary device.

NCP> SET CIRCUIT DMP-0.1 TRIBUTARY 5

NCP> SET CIRCUIT DMP-1.0 TRIBUTARY 5

The logical tributary number (0 in this case) is not to be confused with the tributary address. Refer to the description of logical tributary numbers in the circuit identification at the beginning of this section.

NCP> SET CIRCUIT CI-0.1 TRIBUTARY 1

The tributary node address is the CI port number of the remote CI node, not the DECnet node address.

Note that you must load the CNDRIVER before running DECnet over a CI (see Section 2.2.3, “CI Circuit Devices”).

Ethernet and FDDI circuit identification takes the following format:

NCP> SET CIRCUIT SVA-2 ON

The following command identifies the circuit device MFA and the controller number 2 for an FDDI circuit:

NCP> SET CIRCUIT MFA-2 STATE ON

NCP> SET CIRCUIT SVA-0 STATE ON

DECnet for OpenVMS may automatically change the state of a DDCMP circuit for certain functions. For example, assume that you have set a DDCMP circuit to ON. Later, someone performs a circuit-level loopback test on that circuit without first setting the circuit state to SERVICE. Network management software automatically turns the circuit to the appropriate internal state (or substate) for the test. If the circuit state were displayed at that point, it would register as ON-LOOPING. When the circuit is in this state, it is in use for an active circuit loop test. This test is termed active because it was initiated on the local node. The local node enters the passive loopback state (ON-REFLECTING) whenever a remote node initiates a loopback test with the local node. When the test finishes, the circuit returns to the ON state. For a complete list of circuit states, substates, and their transitions, refer to the VSI OpenVMS DECnet Network Management Utilities.

Several circuit substates have the prefix AUTO. These substates can occur when an adjacent node is or is about to be in an automatic downline loading or triggering stage. For example, if circuit SVA–0 is in the ON state and the local node (BOSTON) receives a request for a downline load on that circuit, the network software on the local node automatically sets the circuit to the ON-AUTOSERVICE state.

NCP> SET CIRCUIT SVA-0 SERVICE ENABLED

To disable service operations on a circuit, set the SERVICE parameter to DISABLED, which allows you to restrict the operation of a circuit for network users. The default for the SERVICE parameter is DISABLED.

Two timers exist for controlling message transmissions and checking the status of adjacent nodes. The first is a hello timer, which defines the frequency of Routing layer Hello (“I'm still here”) messages sent to the adjacent node on the circuit. The second is a listen timer, which controls the maximum amount of time allowed to elapse before the Routing layer stops waiting for either a Hello message or a user message from the adjacent node on the circuit. You cannot set the listen timer with an NCP command; the value of the listen timer is always twice the value of the hello timer at the local node.

NCP> SET CIRCUIT SVA-0 HELLO TIMER 15

This command sets a limit of 15 seconds between Hello messages from the executor node to the adjacent node on circuit SVA–0. The listen interval is 30 seconds between messages from the node on circuit SVA–0 adjacent to the executor node. For the HELLO TIMER parameter, you must specify a value between 1 and 8191 seconds. The default value for the HELLO TIMER parameter is 15 seconds.

The value of the HELLO TIMER parameter should be the same on all adjacent nodes over the same circuit.

Digital recommends that you accept the default value for the HELLO TIMER parameter.

The VERIFICATION parameter applies to DDCMP circuits.

The VERIFICATION parameter controls whether the local node checks the Routing layer passwords (RECEIVE PASSWORD and TRANSMIT PASSWORD) in the database entry for the remote node before it completes a node initialization request from that node.

NCP> SET CIRCUIT DMB-0 VERIFICATION ENABLED

NCP> SET CIRCUIT DMB-0 VERIFICATION DISABLED

The default is DISABLED, which means that you need not specify a node in the configuration database to complete Routing layer initialization. To include a remote node in the configuration database, you must specify the NODE NAME and ADDRESS parameters; you can optionally specify the RECEIVE PASSWORD and TRANSMIT PASSWORD parameters.

The VERIFICATION INBOUND parameter applies to any DDCMP point-to-point circuit. When you specify VERIFICATION INBOUND, the remote node submitting an initialization request to the local node must supply a transmit password that matches the receive password for that node in the local node database. The local node, however, does not send its initialization password to the requesting node. The VERIFICATION INBOUND parameter provides added security for the local node, which can verify the password of a node requesting a connection without revealing its own password.

NCP> SET CIRCUIT DMB-0 VERIFICATION INBOUND

The VERIFICATION INBOUND parameter is supplied automatically for a dynamic asynchronous DDCMP circuit. When a dialup node requests a dynamic connection to the local node and the VERIFICATION INBOUND parameter is set for the circuit, you must specify the INBOUND parameter for the dialup node in the node database. If you do not specify VERIFICATION INBOUND, the INBOUND parameter in the dialup node entry is ignored.

Several circuit parameters enable you to regulate and control tributaries. Some of these parameters apply to polling, others to timers. Note that you specify these circuit parameters on the control station, not on the tributary itself.

Polling Over DDCMP Circuits

NCP> SET CIRCUIT DMP-0.3 DYING THRESHOLD 5

NCP> SET CIRCUIT DMP-0.1 INACTIVE THRESHOLD 12

The control station attempts to poll its active tributary 12 times. If it receives only acknowledgments, but no data responses, the control station changes the active tributary's polling state to INACTIVE. The values for the INACTIVE THRESHOLD parameter range from 0 to 255 and the default is 8.

NCP> SET CIRCUIT DMP-0.1 POLLING STATE DEAD

NCP> SET CIRCUIT DMP-1.2 ACTIVE BASE 225

After a poll, this command resets the base priority of the tributary on circuit DMP–1.2 to 225. The values for all BASE parameters range from 0 to 255. The defaults are ACTIVE, 255; INACTIVE, 0; and DYING, 0.

NCP> SET CIRCUIT DMP-2.2 INACTIVE INCREMENT 200

This command adds 200 to the base priority of the tributary on circuit DMP–2.2. The increment values range from 0 to 255. The defaults are ACTIVE, 0; INACTIVE, 64; and DYING, 16. Note that, if you set a 0 increment on a tributary with a base priority lower than 128, the tributary will never be polled. Active tributaries usually have a high base priority and, therefore, do not need a high increment value.

NCP>SET CIRCUIT DMP-0.2 MAXIMUM BUFFERS 10

NCP> SET CIRCUIT DMP-0.1 MAXIMUM TRANSMITS 2

DDCMP Tributary Circuit Timers

NCP> SET CIRCUIT DMP-0.1 BABBLE TIMER 8000
NCP> SET CIRCUIT DMP-0.1 TRANSMIT TIMER 4000

The first command limits transmission time to 8 seconds (8000 milliseconds) for the circuit's tributary. Values for the BABBLE TIMER parameter range from 1 to 65,535; the default is 6000 (6 seconds).

The second command sets a delay of 4 seconds (4000 milliseconds) between each transmission from the tributary. Values for the TRANSMIT TIMER parameter range from 0 to 65,535; the default is 0.

To create or modify Ethernet configurator module parameters in the volatile database, use the SET MODULE CONFIGURATOR command. The SURVEILLANCE ENABLED parameter in this command causes the configurator module to begin listening to system identification messages transmitted by all systems on the circuit or circuits specified in the command. The configurator collects this information and constructs a list of systems and their capabilities in the volatile database.

NCP>SET MODULE CONFIGURATOR KNOWN CIRCUITS -
_ SURVEILLANCE DISABLED

After the configurator ceases surveillance of all Ethernet circuits it has been monitoring, the list of system information is deleted.

If you do not specify a line protocol, the default values apply, according to the device specified. See Chapter 2, DECnet for OpenVMS Components and Concepts for device lists.

You do not specify any protocol for a CI line. The CI uses its own private protocols for communication between nodes.

The SET LINE PROTOCOL examples that follow specify line protocols in the configuration database at the local node and on remote nodes other than DECnet for OpenVMS, such as DECnet-RSX. For example, the following command identifies line DMP-0 as a multipoint control station:

NCP>SET LINE DMP-0 PROTOCOL DDCMP CONTROL

You set this parameter in the database of the local node at the controlling end of this line. You could specify a tributary for this line, as follows:

NCP>SET LINE DMP-1 PROTOCOL DDCMP TRIBUTARY

You set this parameter in the database of the remote node connected to the tributary end of the control station for that line.

The ON and SERVICE states have substates; see the VSI OpenVMS DECnet Network Management Utilities for a complete list of line states, substates, and their transitions.

NCP> SET LINE DMC-0 STATE ON

The STATE parameter is optional and, by default, is set to OFF.

You can increase the maximum size of receive buffers (and therefore the size of NSP messages) that can be transmitted over a particular line by specifying the BUFFER SIZE parameter in the SET LINE command. For certain logical links established over the line to adjacent nodes, this BUFFER SIZE value overrides the executor node BUFFER SIZE limit specified in the SET EXECUTOR command (see Section 3.3.4.1, “Logical Link Control”).

If you specify the BUFFER SIZE parameter for a line, the adjacent node on any new logical link initiated over that line can optionally accept an NSP message segment size that is based on the BUFFER SIZE value. If the remote node accepts the segment size, the logical link to that node is then tied to that circuit. If the circuit fails, the logical link does not automatically route the packet through an alternate circuit; that is, the logical link becomes non adaptive.

NCP> SET LINE SVA-0 BUFFER SIZE 1400

If the adjacent node does not accept a segment size based on the BUFFER SIZE value, the default is the executor node’s BUFFER SIZE value. The maximum and default line buffer size for an Ethernet or FDDI line is 1498 bytes. A large value for BUFFER SIZE will achieve maximum performance because all logical links between adjacent nodes will use this message size.

This feature can also be used to maximize performance over the CI. However, on a CI the BUFFER SIZE parameter must be less than or equal to the SYSGEN parameter SCSMAXDG. Failure to do this will result in an unusable CI circuit.

Increasing line BUFFER SIZE may require that additional buffered I/O byte count quota (BYTLM) be allocated to the NETACP process. See Section 5.4.3, “CPU Time Requirements” for information about adjusting NETACP’s BYTLM quota.

NCP> SET LINE TT-0-0 RECEIVE BUFFERS 4

Values for this parameter range from 1 to 32. The number of buffers you set depends on throughput requirements and available memory pool. A value in the range of 2 to 4 is adequate for line speeds of less than 56K bits. For asynchronous lines, a value of at least 4 is recommended. Megabit line speeds may require eight or more buffers, depending on the observed errors.

$ RUN SYS$SYSTEM:NCP
NCP> SHOW CIRCUIT TT-0-0 COUNTERS

NCP> SHOW LINE TT-0-0 CHARACTERISTICS

\Line Volatile Characteristics as of 30-DEC-2020 9:32:50
   Line = TT-0-0
   Receive Buffers        = 4
   Controller             = normal
   Duplex                 = full
   Protocol               = DDCMP point
   Retransmit timer       = 3000
   Line speed             = 9600
   Switch                 = disabled
   Hangup                 = disabled

NCP> SET LINE TT-0-0 STATE OFF
NCP> SET LINE TT-0-0 RECEIVE BUFFERS 6
NCP> SET LINE TT-0-0 STATE ON

To change the number of receive buffers in the permanent database as well, use the NCP command DEFINE LINE. Increasing the number of line RECEIVE BUFFERS may require that additional buffered I/O byte count quota (BYTLM) be allocated to the NETACP process. Refer to Section 5.4.3, “CPU Time Requirements” for information about adjusting NETACP’s BYTLM quota.

NCP> SET LINE DMC-1 DUPLEX FULL

Generally, you use full-duplex mode for local lines and permanently wired telephone lines; you usually use half-duplex mode for dialup remote telephone lines used with half-duplex synchronous modems. If you use a modem, consult the manufacturer's documentation for full- or half-duplex characteristics.

The DMP11 automatically handles message retransmission for normal operations. However, when a DDCMP circuit is in the SERVICE state, a line retransmission timer is necessary because the DMP11 does not handle retransmission in maintenance operation protocol (MOP) mode.

RETRANSMIT TIMER = (20000 * buffer-size * number-of-buffers)/bps-of-line

In general, use this formula to calculate the best value for the retransmit timer (in milliseconds).

The number of buffers is the value specified for the MAXIMUM TRANSMITS parameter in the SET CIRCUIT command; it represents the maximum number of data messages that the tributary can transmit in a single poll interval (see Section 3.5.3.2, “DDCMP Tributary Control”).

RETRANSMIT TIMER = (20000 * 576 * 4)/56000 = 820 milliseconds

NCP> SET LINE DMP-2 RETRANSMIT TIMER 820

This command sets the retransmission frequency for line DMP–2 to 820 milliseconds. If a message is not acknowledged in 820 milliseconds, it is retransmitted.

The preceding formula does not apply to the DMF32 tributary mode. The value of the retransmit timer is the maximum time the tributary will hold the line before returning control to the control station. For DMF32 tributary mode, therefore, the more active the tributary, the higher the value to which you should set the retransmit timer (a value of 2000 is recommended). For inactive tributaries, set the timer value lower (a value of 500 milliseconds is recommended).

NCP> SET LINE DMC-2 ... TRAMSMIT PIPELINE 10

The TRANSMIT PIPELINE parameter is optional and, by default, takes the value 7.

messages = (delay*rate)/(size*8)

0.67*9600
/(40*8) = 20 

For this example, the optimum value for TRANSMIT PIPELINE is 20 messages.

The LINE SPEED, HANGUP, and SWITCH parameters apply only to asynchronous DDCMP lines. Values for these parameters are provided automatically when a line is switched dynamically from a terminal line to an asynchronous DDCMP line. When you initiate a dynamic connection between two nodes over a telephone line, these parameters are included in the line entries supplied to the line database. For static asynchronous DDCMP lines, these parameters usually assume their default values.

The LINE SPEED parameter specifies in baud the speed of an asynchronous DDCMP line. The parameter defaults to the current speed of the line. If two asynchronous lines are connected, both lines must have the same line speed.

If a dynamic connection is made, this value is supplied automatically for each line. For a static asynchronous line, the default line speed value is the value of the /SPEED qualifier in the DCL command SET TERMINAL you specified to cause the terminal line to be converted to an asynchronous line.

The HANGUP parameter determines whether the modem signal is dropped when the line is shut down. When you shut down a dynamically switched asynchronous line, the modem carrier is dropped if the value of the parameter is ENABLED. This value, supplied automatically, corresponds to the /HANGUP qualifier in the SET TERMINAL command you specified to cause the terminal line to be switched to an asynchronous line. If the value supplied for the parameter is DISABLED, the modem signal is not dropped when the line is shut down. For a static asynchronous line, the parameter defaults to ENABLED.

The SWITCH parameter indicates whether an asynchronous DDCMP line is to be switched back to a terminal line after it is disconnected from the network (when the channel to the network is deassigned). The SWITCH parameter is enabled automatically for a dynamic asynchronous line so that the line can be switched back to a terminal line when the dynamic connection is broken. The parameter defaults to DISABLED for a static asynchronous line, which remains available as a communications line even when not assigned a channel to the network. Generally, you do not need to set the SWITCH parameter manually.

The FDDI address associated with the FDDI line device hardware is displayed as a read-only parameter, hardware address, in response to the SHOW LINE command.

NCP>SHOW LINE MFA-0 CHARACTERISTICS
Line = MFA-0
Receive buffers = 10
Controller = normal
Protocol = FDDI
Service timer = 4000
Hardware address = 08-00-2B-1C-12-16
Device buffer size = 1498
Requested TRT = 0
Valid transmission time = 32768
Restricted token timeout = 0
Ring purger enable = off
NIF target = 00-00-00-00-00-00
SIF configuration target = 00-00-00-00-00-00
SIF operation target = 00-00-00-00-00-00
Echo target = 00-00-00-00-00-00
Echo data = 00
Echo length = 0

See the discussion of physical and hardware addresses in Section 3.6.2.2, “Buffer Size”.

To display the FDDI line status enter the following command:

NCP>SHOW LINE MFA-0 STATUS

The command results in the following information display:

Line = MFA-0
State = on
Negotiated TRT = 99840
Duplicate address flag = unknown
Upstream neighbor = 08-00-2B-1C-0D-BB
Old upstream neighbor = 00-00-00-00-00-00
Upstream neighbor DA flag = unknown
Downstream neighbor = 00-00-00-00-00-00
Old downstream neighbor = 00-00-00-00-00-00
Ring purger state = off
Ring error reason = no error
Neighbor PHY type = A
Link error estimate = 15
Reject reason = none

Table 3.7, “FDDI Line Status Parameters and Their Functions” lists all FDDI line status read-only parameters and their functions.

Certain NCP command parameter values limit the number of routers and end nodes that can be configured on broadcast circuits.

NCP> SET CIRCUIT SVA-0 MAXIMUM ROUTERS 5

Use the SET EXECUTOR command with the MAXIMUM BROADCAST ROUTERS parameter to specify the maximum number of routing nodes that will be permitted on all Ethernet and FDDI circuits to which the local node is attached.

NCP> SET EXECUTOR MAXIMUM BROADCAST ROUTERS 12

The default value of this parameter is 32.

NCP> SET EXECUTOR MAXIMUM BROADCAST NONROUTERS 20

The default value is 64.

NCP> SET EXECUTOR MAXIMUM AREA 50

If you do not specify this parameter, the Routing layer recognizes up to 63 areas.

Figure 3.2, “Network Circuit Costs” illustrates sample circuit costs attributed to the network example. The following paragraphs discuss routing control parameters as they relate to Figure 3.2, “Network Circuit Costs”.

NCP> SET CIRCUIT SVA-2 COST 4

Numbers in the range of 1 to 25 are valid circuit costs. The default value is 10.

Establishing a circuit cost standard that is uniform across the entire network is recommended.

You set both the maximum cost for all circuits to the destination node (MAXIMUM COST) and the maximum hops that a packet can make when routed to the destination node (MAXIMUM HOPS) using the SET EXECUTOR command. You use these parameters to ascertain whether a destination is reachable. The value of the MAXIMUM HOPS parameter should always be equal to or greater than the longest possible path within the network. For the network example, a maximum hop parameter value of 6 is sufficient. You should choose the maximum cost and hops values carefully, with regard to the intended use of the network, the actual network configuration, and possible failures.

NCP> SET EXECUTOR MAXIMUM COST 100 MAXIMUM HOPS 6

Values in the range 1 to 1022 are valid for the MAXIMUM COST parameter; the default value is 1022. Values in the range 1 to 30 are valid for the MAXIMUM HOPS parameter; the default value is 30. The value for the MAXIMUM HOPS parameter must be less than or equal to the value for MAXIMUM VISITS.

Figure 3.2, “Network Circuit Costs” illustrates the relationship between circuit costs and path costs. To send a packet from TRNTO to DALLAS, the system can route it over one of two paths, both of which require two hops; the first path is through BOSTON, the second through DENVER. However, because the path through BOSTON has a cost of 8 and the path through DENVER has a cost of 5, the system routes the packet through DENVER.

Under normal conditions, a MAXIMUM HOPS value of 3 would be sufficient for the network in Figure 3.2, “Network Circuit Costs”. However, if the MAXIMUM HOPS value were set to 3, a failure of the TRNTO-BOSTON circuit would render TRNTO unreachable from NYC, KANSAS, or BANGOR, even though a physical path still exists (the four-hop path NYC-BOSTON-DALLAS-DENVER-TRNTO). Consideration of possible failures is also important in establishing the MAXIMUM COST parameter.

NCP> SET EXECUTOR MAXIMUM VISITS 12

If the number of nodes that the data packet visits exceeds the value of MAXIMUM VISITS, the packet is discarded. Generally, use a value that is two or three times the value for the MAXIMUM HOPS parameter. At a minimum, the value for the MAXIMUM VISITS parameter must be equal to or greater than the value for the MAXIMUM HOPS parameter. The maximum value is 63, which is also the default value.

Circuit costs are used by DECnet to determine the optimum path over which data is to be transmitted. DECnet selects the path with the lowest cost.

NCP> SET EXECUTOR MAXIMUM PATH SPLITS 2

The default value for MAXIMUM PATH SPLITS is 1. That is, all data will go over the lowest cost path, with no splitting.

Equal cost path splitting operates most efficiently for those nodes that run VMS Version 5.4 and communicate with nodes running DECnet for OpenVMS Version 4.6 or higher. Early DECnet for OpenVMS versions do not support out-of-order packet caching; any packets received out of order are discarded. Therefore, splitting traffic over all equal cost paths may result in poor network performance.

NCP> SET EXECUTOR PATH SPLIT POLICY INTERIM

As a result of this command paths are not split for routing on all equal cost paths.

When a network is divided into areas, the MAXIMUM COST and MAXIMUM HOPS parameters described previously are used to control the path between each pair of nodes within each area. A second set of routing parameters (AREA MAXIMUM COST, AREA MAXIMUM HOPS) is used to control the total cost and length of paths between level 2 routers within the whole network. In effect, these parameters control the total possible path between areas in the network.

The AREA MAXIMUM COST parameter in the SET EXECUTOR command specifies the limit on the total path cost between the local level 2 router and any level 2 router in the network. This value is the maximum cost of circuits on the longest path between level 2 routers. The AREA MAXIMUM HOPS parameter in the SET EXECUTOR command specifies the maximum number of hops that a packet can make between the local level 2 router and any other level 2 router in the network.

Use the AREA MAXIMUM COST and AREA MAXIMUM HOPS parameters to determine whether an area is reachable. Select the values for these parameters carefully, with regard for the level 2 (area) topology of the network.

NCP> SET EXECUTOR AREA MAXIMUM COST 500 AREA MAXIMUM HOPS 10

Values in the range 1 to 1022 are valid for the AREA MAXIMUM COST parameter; the default value is 1022. Values in the range 1 to 30 are valid for the AREA MAXIMUM HOPS parameter; the default value is 30.

NCP> SET EXECUTOR INCOMING TIMER 30

Expiration of this timer signals that a timeout has occurred. In effect, this timer protects the local node against a process that never responds to an inbound connection request.

NCP> SET EXECUTOR OUTGOING TIMER 30

A typical value for this timer ranges from 10 to 90 seconds, depending on line speed and network diameter. The network diameter is the maximum diameter over the set of shortest paths between all pairs of nodes in the network. In effect, this timer protects the user on the local node against a connection request that never completes.

NCP> SET EXECUTOR INACTIVITY TIMER 60

When this timer expires, DECnet for OpenVMS generates artificial traffic to test the link. The timer starts after an incoming message for the link has been processed. The timer is reset if any messages are received on the link.

A third group of parameters regulates the frequency of NSP message retransmission. These are the DELAY WEIGHT, DELAY FACTOR, and RETRANSMIT FACTOR parameters for the local node.

NSP estimates the current delay in the round-trip transmission to a node with which it is communicating. The value of the DELAY WEIGHT parameter is used to calculate a new value of the estimated round trip delay. The old round trip delay is weighted by a function of this statistical factor to calculate the new round trip delay. If the delay weight is set high, the retransmit time changes slowly. If the weight is set low, the observed round trip time can change quickly if the observed round trip delays vary widely, and thus the retransmit time can change more rapidly.

The value of the DELAY FACTOR parameter is multiplied by one-sixteenth of the estimated round trip delay time to determine the appropriate value for the time to retransmit certain NSP messages.

NCP> SET EXECUTOR DELAY WEIGHT 3 DELAY FACTOR 48

The default value is 80. For a complete discussion of these concepts, refer to the Network Services Protocol Functional Specification.

NCP> SET EXECUTOR RETRANSMIT FACTOR 10

If RETRANSMIT FACTOR is set to 10, NSP will not try to retransmit an eleventh time, and will disconnect the logical link.

In the process of logical link connect sequences, the value of the RETRANSMIT FACTOR parameter takes precedence over the OUTGOING TIMER value. As a result, the actual time necessary for the specified number of retransmits may not match the setting of the OUTGOING TIMER parameter.

The PIPELINE QUOTA parameter in the SET EXECUTOR command specifies the maximum number of bytes NSP can use from nonpaged pool to buffer logical-link transmit requests. In effect, this quota determines the number of packets NSP transmits on a single logical link before waiting for a positive acknowledgment from the remote end of the link. You determine the number of packets by dividing the PIPELINE QUOTA value by the EXECUTOR BUFFER SIZE value.

The PIPELINE QUOTA value is not deducted from the byte count quota of the user process. Thus the system manager can set the process byte count quota to sensible values without concern for the nonpaged pool requirements of DECnet for OpenVMS. DECnet's nonpaged pool usage with respect to the transmission over logical links is bounded by the product of the values of the PIPELINE QUOTA and MAXIMUM LINKS parameters.

NCP> SET EXECUTOR PIPELINE QUOTA 12000

When defining or modifying object parameters, identify the name of the object. DECnet object names are descriptive alphanumeric strings of up to sixteen characters. DECnet software also uses object numbers as unique object identifiers. Object numbers have a range of 0 to 255. Most user-defined images are numbered 0. However, a user program should have a nonzero number assigned when it provides a known service. You may define an object name in the configuration database to a type 0 object if you want to associate required privileges or default inbound access control with the object.

NCP> SET OBJECT FOO NUMBER 129

Note that the object name may not be unique to the generic services specified. Only object numbers are unique across systems. For consistency, however, using object names as they are normally referenced throughout the network is recommended.

On VMScluster systems, parameters for the SET OBJECT and DEFINE OBJECT commands specify how certain objects treat incoming and outgoing connection requests associated with the alias node.

By specifying the ALIAS OUTGOING parameter for a particular object, you can indicate whether the object uses the alias node address in any outgoing connect request.

NCP> SET OBJECT FOX ALIAS OUTGOING ENABLED

By default, only the object MAIL is so enabled. All other objects are disabled unless specified as otherwise.

Objects such as PHONE, which use a protocol that depends on multiple links, should not have the ALIAS OUTGOING parameter enabled.

Use the ALIAS INCOMING parameter to specify how certain objects are to respond to incoming connect requests that are directed to the alias node. You can either enable or disable specific objects from receiving these incoming connections.

NCP> SET OBJECT FOO ALIAS INCOMING DISABLED

By default, if you establish an alias node identifier for the node, ALIAS INCOMING is enabled for all objects except PHONE. If a user attempts to use an alias node address to connect to an object for which ALIAS INCOMING has been disabled, the status message is returned.

%SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node

The following scenario illustrates how use of an alias node identifier can facilitate communication between a node within a cluster and a remote node.

NCP> DEFINE NODE 2.13 NAME CLUSTR

NCP> DEFINE EXECUTOR ALIAS NODE CLUSTR

Because an alias node identifier has been set, the ALIAS INCOMING parameter is enabled by default. This means that all incoming connect requests addressed to the alias node identifier are routed to a node that uses the alias.

NCP> DEFINE OBJECT MAIL ALIAS OUTGOING ENABLED

After the network is started, a user with the user name JONES logs on to node THRUSH. JONES then sends a mail message to user SMITH on node BOSTON, which is outside the cluster. Because MAIL is enabled for outgoing connect requests, it appears that JONES has sent mail from node CLUSTR. An hour later, when user SMITH reads the mail from JONES, the mail is associated with the node-identifier CLUSTR::JONES.

SMITH decides to reply to the mail from JONES. SMITH sends the mail message to JONES using the destination node CLUSTR.

Meanwhile, the node THRUSH has been taken down for maintenance, so JONES has logged on to node ROBIN. Because ROBIN has also been enabled for incoming connect requests addressed to the alias node identifier, JONES receives the mail from SMITH. The mail is addressed to CLUSTR::JONES, and is delivered to a node that uses the alias.

For nonzero-numbered objects, the default name of this command file is SYS$SYSTEM: object name.COM. Nonzero objects are identified in the logical link connect message only by object number. Therefore, there must be an entry in the object volatile database that enables NETACP to locate the object name using the object number as a key. When you install DECnet for OpenVMS, nonzero object network-defined command procedures are entered by default in the SYS$SYSTEM directory, and NETACP knows about these command procedures. The supplied command files, named object name.COM, include FAL, HLD, NML, EVL, DTR, MAIL, PHONE, and MIRROR. Except for those command procedures supplied by Digital, you must create a command procedure for every object that can be started by an inbound connection request. You should name command procedures for nonzero objects object name.COM and place them in SYS$SYSTEM.

For zero-numbered objects, the default name of this command file is SYS$LOGIN: object name.COM. Zero objects are identified in the logical link connect message by object name. Therefore, there is no need for an entry in the object volatile database. You can, of course, specify an entry in the object database at any time. You are required to include a separate entry if you want special features such as default inbound access control information.

NCP> SET OBJECT FAL NUMBER 17 FILE SYS$MANAGER:TRIALFAL.COM
NCP> SET OBJECT USERS NUMBER 0 FILE SYS$SYSTEM:USERS.COM

NCP> SET OBJECT FAL NUMBER 17 FILE FAL.EXE

You should place the image in SYS$SYSTEM. This approach causes the object to be started up more quickly; it is useful in cases where no advantage is gained by invoking the image from a command procedure. The session log appears as part of the NETSERVER.LOG file.

NCP> SET NODE DENVER -
_ NONPRIVILEGED USER NETNONPRIV PASSWORD NONPRIV-
_ PRIVILEGED USER NETPRIV PASSWORD PRIV

You should specify default information for all remote nodes with which you want to have the option of using default access control.

Use the SET OBJECT command with the PRIVILEGE parameter to specify those privileges that cause the privileged user account to be used rather than the nonprivileged user account.

For example, you may want to make the FAL object accessible to any network user, whereas you want to control access to the NML object. The following command specifies privileges for the NML object in this instance:

NCP>SET OBJECT NML PRIVILEGES OPER

You need not specify privileges for FAL because it requires only NETMBX and TMPMBX privileges.

To prevent unauthorized access to objects, use the OUTGOING CONNECT PRIVILEGES parameter in the SET OBJECT and DEFINE OBJECT commands in NCP. This parameter specifies the privileges a user must possess to make outbound connections to an object.

Example 3.1, “Using the SET OBJECT OUTGOING CONNECT PRIVILEGES Command” illustrates the use of the NCP command SET OBJECT OUTGOING CONNECT PRIVILEGES. At the DCL command prompt, the user sets privileges for the process. After invoking NCP, the user specifies the privileges necessary to connect to the object TEST. Because the object TEST requires the READALL privilege to make an outbound connection, the connection fails, resulting in an error message. After the user resets the privileges to include READALL, the process is able to connect to the object.

$ SET PROCESS/PRIVILEGES=(NOALL,TMPMBX,NETMBX,OPER)
$ RUN SYS$SYSTEM:NCP
NCP> SET OBJECT TEST NUMBER 0 -
OUTGOING CONNECT PRIVILEGES READALL OPER
NCP> SET OBJECT TEST FILE SMITH$DISK:[SMITH]TEST.COM
NCP> EXIT
$ OPEN/READ LINK 0"SMITH CEADGUTY"::"0=TEST"
%DCL-E-OPENOUT, error opening 0"smith password"::"0=test" as
output -RMS-E-PRV, insufficient privilege or file protection
violation
$ SET PROCESS/PRIVILEGES=(NOALL,TMPMBX,NETMBX,OPER,READALL)
$ OPEN/READ LINK 0"SMITH CEADGUTY"::"0=TEST"
$ READ LINK RECORD

You use access control for remote NCP command execution. When you enter the SET EXECUTOR NODE and TELL commands, you can explicitly specify access control information, or you can default to information contained in the configuration database.

NCP> SET EXECUTOR NODE TRNTO"GRAY MARY"::
NCP> SET EXECUTOR NODE TRNTO USER GRAY PASSWORD MARY

The same formats exist for the TELL command. Use of the standard OpenVMS node specification format allows you to use a logical name as the node-id for these commands. It is possible to override access control in a logical name with explicit access control information in the command.

NCP> SET EXECUTOR NODE TRNTO"user-id password"

In a target-initiated downline load, the target node sends a maintenance operation protocol (MOP) request program message. This message is a request for any eligible node to perform the load. The request program message can potentially specify a number of fields, including a software identification, a software type, and a service device.

The SERVICE parameter must be set to ENABLED for a circuit in order for MOP messages received on that circuit to be processed. When DECnet receives a MOP request program message on a circuit enabled for service operations, it creates a Maintanence Operation Module (MOM) process to handle the MOP request. There is a limit of 10 concurrent MOM processes. When this limit is reached, no additional MOP downline load requests are processed by the local node until some others complete. The MOM processes are named MOM-circuit-id_process-number (for example, MOM_SVA-0_1). Each process terminates when the load request it is processing completes.

If a point-to-point circuit connects the nodes, DECnet searches the node database for a node entry with a SERVICE CIRCUIT parameter matching the circuit over which the load was requested. DECnet uses the information from this node entry to perform the load.

If the connecting circuit type is Ethernet or FDDI, MOM determines if the request was directed to the multicast address or to the local node. If the request was directed at the local node, MOM performs the load. If the request was for the multicast address, MOM volunteers to perform the load. If a software identification is provided in the request or if a node entry is found that matches the hardware address of the target node, MOM sends a message to the requesting node volunteering to perform the load. If MOM does not get a response from the remote node, it drops the received packet and exits. Otherwise, it services the remainder of the load.

If the MOP message does not specify the target node’s requested image (using a software identification field or program type field), the MOM process reads the volatile node database which associates the image file name with the target node name.

When the MOM process has enough information, it performs the load operation. If it does not have enough information, it logs an event.

There are four possible values for program type:

The secondary loader, tertiary loader, and operating system files designate image specifications, while the management file value designates a general data specification. You can use the management file to specify additional information for downline loading that certain systems may need.

After it knows the type of file being requested, NETACP can obtain a file specification in one of two locations. The first location searched is the request program message that MOM received. The second is the node database entry for the requesting node. If the file specification is not in the node entry or in the request program message, the MOM process aborts the service request and exits. MOM checks for the existence of the load file before volunteering to perform the load. If the file is not available, MOM aborts the service request and exits.

The downline load sequence varies when a request originates from a satellite node in a VMScluster. A node in a cluster may need more input parameters than are currently defined in the volatile node database. Thus, you need to be able to dynamically configure the image to be loaded, and to transfer more parameters to the target system than those accommodated by the Parameter Load and Transfer packet. To accommodate this need, MOM calls on the services of a load assist agent to help fulfill a downline load request. The load assist agent is an image that makes calls back to MOM with data that describes the image to be loaded on the target node.

For downline loads to satellite nodes in clusters, MOM delivers all load requests to load assist agents. The node parameter LOAD ASSIST AGENT identifies a specific agent by file name. Section 4.1.2.7, “Load Assist Agent Identification” describes the procedure for specifying the LOAD ASSIST AGENT file specification. Another node parameter, LOAD ASSIST PARAMETER, passes an individual value to a load assist agent file. Section 4.1.2.8, “Load Assist Parameter Identification” describes the procedure for specifying the LOAD ASSIST PARAMETER value.

An operator-initiated load uses NCP to directly request MOM to perform the load operation. The target node's primary bootstrap may or may not have to be triggered depending on the state of the target. The target node is triggered primarily to put it into a known state and to force it to supply program request information.

Use the NCP command LOAD or TRIGGER to perform an operator-initiated downline load. The TRIGGER command allows you to directly trigger the remote node's bootstrap ROM, which causes the target node to send its host a request for a load operation. The programs to be loaded may come from a local disk file on the target node, another adjacent node, or the command node.

Note that the TRIGGER command may or may not initiate a downline load. One of the functions of this command is to simulate the operation that occurs when you push the BOOT button on the target node. A bootstrap operation from the local disk may result.

When you use the LOAD command, the executor node proceeds with the load operation according to the options specified in the initial load request. You obtain any required information that has been defaulted from the volatile database. With this information, the executor is thereby able to control the load sequence.

Section 4.1.2, “Downline Load Parameters” describes the TRIGGER and LOAD commands, their parameters, and examples of their use.

Refer to the Maintenance Operation Protocol Functional Specification for a complete description of MOP error recovery.

The TRIGGER command triggers the bootstrap mechanism of a target node, which causes the node to request a downline load. Because the system being booted is not necessarily a fully functional network node, the operation must be performed over a specific circuit. To bring up the system at the target node, use either the TRIGGER NODE or TRIGGER VIA command. If you use the TRIGGER NODE command and do not specify a loading circuit, the executor node obtains the circuit identification associated with the target node from its volatile database. If you use the TRIGGER VIA command, which indicates the loading circuit but not the node identification, the executor node uses the default target node identification in its volatile database. To identify the target node in the volatile database, specify the SET NODE command with the appropriate SERVICE CIRCUIT parameter, which establishes the circuit to be used for loading.

NCP> TRIGGER NODE BANGOR VIA DMC-0

Note that this command specifies a DDCMP circuit over which the operation is to take place.

The PHYSICAL ADDRESS parameter for the target node is required in the TRIGGER VIA command and optional in the TRIGGER NODE command.

If you do not specify a physical address in the TRIGGER NODE command, DECnet for OpenVMS derives one from the target’s DECnet address and attempts to trigger the node. A target node that is running DECnet software has set its physical address to a value derived from its DECnet address and will recognize messages sent to this address. If the target node is not yet running DECnet software, its physical address will have been set to the value of the device controller’s hardware address and messages sent to a physical address derived from the target node’s DECnet address will not be recognized. If unsuccessful in triggering the node using the physical address, DECnet for OpenVMS attempts to use the hardware address of the target node from the volatile database to trigger it. You can set in the volatile database the hardware address originally assigned to the target node’s LAN adapter by specifying the HARDWARE ADDRESS parameter in the SET NODE command. (Refer to Section 2.1.2, “Hardware Addresses and Physical Addresses” for a description of LAN addressing.)

Figure 4.1, “Operator-Initiated Downline Load over Ethernet Circuit (TRIGGER Command)” illustrates the use of the TRIGGER NODE command for downline loading a target node over Ethernet circuit UNA-0.

When you use the TRIGGER command, how the system load is performed may not always be obvious. Essentially, this command provides the trigger message that controls the restart capability for an unattended target node. After the target node is triggered, it loads itself in whatever manner its primary loader is programmed to operate. The target node can request a downline load from either the executor that just triggered it or another adjacent node, or the target node can load itself from its own mass storage device.

One parameter that you can specify for the TRIGGER command is SERVICE PASSWORD. This parameter supplies a boot password, which may be required by the target node (see Section 4.1.2.11, “Service Passwords”). If you do not specify this parameter, a default value from the volatile database is used. Use the SET NODE command to establish a default value for this parameter in the volatile database. If no value is set in the volatile database, the value is 0.

NCP> LOAD NODE BANGOR

The LOAD NODE command requires the identification of the service circuit over which to perform the load operation. If you do not explicitly specify a service circuit in this command, the executor node uses the SERVICE CIRCUIT from the volatile database entry for the target node. Use the SET NODE command to include the SERVICE CIRCUIT entry in the volatile database. Alternatively, you can explicitly include the circuit, for example:

NCP> LOAD VIA SVA-0

The executor node obtains the rest of the necessary information from its volatile database. The LOAD NODE and LOAD VIA commands work only if the target node can be triggered by the executor or if the target has been triggered locally.

If the loading circuit is an Ethernet or FDDI circuit, the executor node uses the physical address of the target node to differentiate the node from other adjacent nodes on the same circuit. Specify the PHYSICAL ADDRESS parameter in the LOAD VIA command. The PHYSICAL ADDRESS parameter is optional in the LOAD NODE command.

If you do not specify the PHYSICAL ADDRESS parameter in the LOAD NODE command, DECnet for OpenVMS derives the physical address from the target node’s DECnet address and attempts to load the target node.

A target node running DECnet software has set its own physical address and recognizes this address; otherwise, the target node recognizes only the hardware address set by the manufacturer. If unsuccessful in loading the node, the executor node attempts the load using the hardware address of the target node from the volatile database.

In the volatile database, you can set the hardware address originally assigned to the target node’s LAN adapter. To do this specify the HARDWARE ADDRESS parameter in the SET NODE command. (Refer to Section 2.1.2, “Hardware Addresses and Physical Addresses” for a description of LAN addressing.)

You can set in the volatile database the Ethernet hardware address originally assigned to the target node's DEUNA or DEQNA controller, by specifying the HARDWARE ADDRESS parameter in the SET NODE command. (Refer to Section 2.1.2, “Hardware Addresses and Physical Addresses” for a description of Ethernet addressing.)

Figure 4.2, “Operator-Initiated Downline Load over Ethernet Circuit (LOAD Command)” illustrates how to use the LOAD command for downline loading over Ethernet circuit SVA-0.

When entering the LOAD NODE and LOAD VIA commands, you can specify any or all of the preceding parameters. Any parameter not specified in the command defaults to whatever information is specified in the volatile database. Use the SET NODE command to establish default information for the target node's parameters in the volatile database.

NCP> SET NODE BANGOR HOST NYC

If you do not specify the host, the executor serves as the default host. You can override any default information by using the HOST parameter for the LOAD command.

The load files are the files to be loaded downline to the target node. These files include the secondary loader, the tertiary loader and the operating system image, and the file specification for the management file. You can specify default load file names in the volatile database with the corresponding SECONDARY LOADER, TERTIARY LOADER, LOAD FILE, and MANAGEMENT FILE parameters of the SET NODE NCP command.

The management file specifies a data file containing additional management information necessary for downline loading to a target node. You can supply a management file by specifying the MANAGEMENT FILE parameter with a LOAD NODE or LOAD VIA command. You can also establish the management file value in the node database using the SET NODE command.

NCP> SET NODE BANGOR MANAGEMENT FILE MANAGE.DAT

NCP> LOAD NODE BANGOR SOFTWARE TYPE OPERATING SYSTEM

Use the SET NODE command to specify default software type information for the target node entry in the volatile database. If no software type information is specified in the volatile database, the default type is the secondary loader.

NCP> LOAD NODE REDSOX LOAD ASSIST AGENT SYS$SHARE:NISCS_LAA.EXE

This command specifies a file containing a specific load assist agent.

NCP>SET NODE REDSOX LOAD ASSIST PARAMETER SYS$SYSDEVICE:[SYS9.]

This command passes an additional parameter to the load assist agent.

In terms of the executor, the service circuit is a circuit connecting the executor node with an adjacent target node. When you use the LOAD and TRIGGER commands, specify or default to a circuit over which the load operation is to take place. Use the VIA parameter to explicitly identify the circuit when entering these commands. If specifying an Ethernet or FDDI broadcast circuit in the LOAD VIA command, include the PHYSICAL ADDRESS parameter.

If you do not specify a circuit, this information defaults to the circuit specified by the target node’s entry in the executor node’s volatile database. To set a service circuit in the volatile database, use the SET NODE command.

When defining nodes for downline loading in the local volatile database, the system manager can specify a default service password. This password may be required to trigger the primary bootstrap mechanism on the target node. If you enter a LOAD or TRIGGER command without a service password, then this default parameter is used if the target node requires one. To set a service password in the volatile database, use the SET NODE SERVICE PASSWORD command. For Ethernet or FDDI adapters that support the setting of service passwords, this password must be a hexadecimal number in the range of 0 to FFFFFFFFFFFFFFFF.

For DDCMP adapters, the range is 0 to FFFFFFFF.

NCP> SET NODE BANGOR SERVICE PASSWORD FEFEFEFE
NCP> LOAD NODE BANGOR

After the target node is loaded downline, it can request diagnostics. Use the DIAGNOSTIC FILE parameter in the SET NODE command to identify in the volatile database the diagnostics file that the target node can read.

The following is a list of HLD error messages.

Format error in HLD.DAT

The format of the HLD mapping table is incorrect. For example, this error could occur if HNODE$ was expected but not found in the table. Re-create the table, using the appropriate format.

Syntax error in HLD.DAT

The syntax of an element in the HLD mapping table is incorrect. For example, the angle brackets needed to enclose the file specification are missing. Re-create the table.

Task name not found

The task to be loaded downline is not specified in the HLD mapping table. Re-create the table so that it contains this task name.

No header in task file

The file was built with the /-HD switch. Therefore, it is an invalid RSX–11S task image. Rebuild the task.

Mapped task not on 4K boundary

The file was not built with the /MM switch. This error is for mapped RSX–11S systems only. Rebuild the task.

Unmapped partition mismatch

The TKB address does not correspond with the starting address of the partition in the RSX–11S system. This error is for unmapped RSX–11S systems only. Rebuild the task with a PAR= statement that specifies the correct starting address.

File too big for partition

The initial load size of the file is larger than the partition size in the RSX–11S system. Either make the partition larger or rebuild the file to use a smaller partition size.

Partition too big for checkpoint space

The partition size in the RSX–11S system is larger than the checkpoint space inside the file. Typically, this indicates that the partition size in your PAR= statement is smaller than the actual size of the partition in the RSX–11S system. Although the load size of a task may be much smaller than its partition, the entire partition is transferred during checkpoint operations. Rebuild the task with the exact partition size from the RSX–11S system.

MAIL provides personal mail service.

The file access listener (FAL) object, provides authorized access to the file system of a DECnet node on behalf of processes executing on any node in the network.

The FAL object can make a system vulnerable to unauthorized access by allowing network access by any remote user to any files with world read access. It also allows any remote user to create files in any directory with world write access.

VSI recommends that you do not create any default account for FAL. Other, more secure access methods are available.

PHONE allows you to communicate with other users on your system or on other DECnet for OpenVMS systems.

A default DECnet account can allow unauthorized users to use Phone to get a list of users currently logged in to the local system. A user could then attempt to log in to the system by using the list of user names.

The network management listener (NML) object provides remote management of the local system. A default nonprivileged account for this object lets remote users issue NCP commands to gather and report network information from your node’s DECnet databases.

The MIRROR object is used for loopback testing. To test DECnet for OpenVMS with the User Environment Test Package (UETP), a default account for the MIRROR object must exist.

The VPM object is used by the Monitor utility (MONITOR) in VMScluster configurations.

Refer to the VSI OpenVMS Guide to System Security for more information about these access methods and the security implications of these default accounts.