The Hacker's Encyclopedia 1998

home *** CD-ROM | disk | FTP | other *** search

/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / n_z / nia037.hac < prev next >

Wrap

Text File | 2003-06-11 | 102.1 KB | 2,163 lines

┌──────────────────┐ ╔═══════════════════════════════╗ ┌──────────────────┐ │ Founded By: │ ║ Network Information Access ║ │ Mother Earth BBS │ │ Guardian Of Time │─║ 20JUN90 ║─│ NUP:> DECnet │ │ Judge Dredd │ ║ Guardian Of Time ║ │Text File Archives│ └────────┬─────────┘ ║ File 37 ║ └─────────┬────────┘ │ ╚═══════════════════════════════╝ │ │ ╔═════════════════════════════╗ │ └───────────║ VMS SYSTEM MANAGER'S MANUAL ║─────────────┘ ║ CHAPTER 6 ║ ╚═════════════════════════════╝ SETTING UP A NETWORK As the manager of a VMS system, you may want to connect your system to a network. This chapter describes the following network topics: : What a DECnet network is : How a VMS system can be part of a DECnet network : The responsibilities of the system manager in a network environment : The procedures needed to bring up a VMS system as a node on an existing network : Techniques to keep the network running NOTE: Refer to Chapter 7 if you intend to set up and manage a Local Area VAXcluster configuration. That chapter outlines the tasks required to configure a Local Area VAXcluster and describes CLUSTER_CONFIG.COM, the command procedure that you use to perform these tasks. 6.1 General Description of a DECnet NETWORK A DECnet network permits the linking of computers into flexible configurations to exchange information, share resources, and perform distributed processing. A VMS operating system can participate in a DECnet network through its networking interface, DECnet-VAX. As a part of a network, a VMS system can communicate with other VMS systems running on a full range of VAX processors, as well as with a wide range of non-VMS systems that use DECnet software. DECnet distributed processing capabilities allow information to be gathered from anywhere in the network. VMS systems can be placed at locations where they are required while still having access to the facilities of other widely dispersed systems. Access to the network is available wherever it is needed: executive offices, factory floors, laboratories, field locations. Information can be exchanged between all parts of an organization or institution in a stable, integrated networking environment. 6.1.1 What is a DECnet Network? A DECnet network consists of two or more computer systems, called nodes, that are connected (for example, by means of cables, telephone lines, microwave or satellite links). Adjacent nodes in a network are connected by lines over which circuits operate. The line is the physical data path, and the circuit is the communications data path. All input and output (I/O) between nodes takes place over circuits. A node can be designed to have active circuits operating over a number of lines that connect that node to other nodes in the network. DECnet permits computer processes running on the same or different computers to communicate with each other over logical links. A logical link connects two processes and carries a stream of two-way communications traffic between the processes over one or more circuits. Many logical links can be supported concurrently over a single circuit established between two nodes. The process to which a logical link is connected is called an object. Some objects are DECnet-VAX system programs (for exampl, the MAIL object); other subjects are user-written programs. For two programs to communicate over the network, the program on the local node establishes a logical link with the object on the remote node. In a network of more than two nodes, the process of directing a data message from a source node to a destination node is called routing. DECnet supports adaptive routing, which permits messages to be routed through the network over the most cost-effetive path; messages are rerouted automatically if a circuit becomes disabled or a lower-cost path becomes available. Nodes can be either routing nodes (called routers) or nonrouting nodes (known as end nodes). Both routers and end nodes can send messages to and receive messages from other nodes in the network. However, a router has the ability to forward or route messages from itself to another node. A router can serve as an intermediate node on a path between two nodes exchanging messages, if the two nodes have no direct physical link to each other. Any node that has two or more active circuits connecting it to the network must be a router. An end node can only have one active circuit connecting it to the network. A DECnet network can vary in size from a small to a very large network. A typical small network might consist of two to four nodes. A maximum of 1023 nodes is possible in an undivided network, but the optimum number is approximately 200 to 300 nodes, depending on the topology ( the way the nodes and lines are arranged in the network ). Very large DECnet networks can be divided into multiple areas: Up to 63 areas, each contaning a maximum of 1023 nodes. In a multiple area network, the network manager groups nodes into separate areas, with each area functioning as a subnetwork. Nodes in any area can communicate with nodes in other areas. DECnet supports routing within each area and a second, higher level of routing that links the areas, resulting in less routing traffic throughout the network. Nodes that perform routing within a single area are reffered to as level 1 routers; nodes that perform routing between areas as well as within their own area are called level 2 routers ( or area routers ). The DECnet architecture follows industry standards and is designed to permit easy expansion and incorporation of new developments in data communications. DECnet offers the option of communicating over different kinds of network connections, which are for the most part transparent to the general user of the network. 6.1.2 How DECnet-VAX Serves As The VMS Interface To The Network DECnet is the collective name for the software and hardware products that are a means for various DIGITAL operating systems to participate in a network. DECnet-VAX is the implementation of DECnet that allows a VMS operating system to function as a network node. As the VMS network interface, DECnet-VAX supports both the protocols necessary for communicating over the network and the functions necessary for configuring, controlling, and monitoring the network. DECnet-VAX networking software can be configured on any VMS operating system running on any VAX processor. in a DECnet network, a DECnet-VAX node can communicate with other DECnet-VAX nodes or with any other operating system that supports DECnet. In addition, DECnet-VAX node can use a packet switching network to communicate with nodes on other networks and can use gateways and other special software and hardware products to communicate with foreign vendor systems. DECnet-VAX is tightly coupled to the VMS operating system. It is completely integrated into the operating system and provides a natural extension of local I/O operations to remote systems. VMS users can use the network almost transparently. Because DECnet-VAX is a part of the VMS operating system, you can use the DECnet-VAX interface as a standard part of a standalone operating system ( for example, to prepare network application programs ). Before you can bring up your system as a node in a multinode environment, you must have a DECnet-VAX license and register a DECnet-VAX key on your system. 6.1.3 What Does a DECnet Network Look Like? to be linked in flexible configurations. The basic kinds of environments into which a DECnet network can be configured are the local rea network and the wide area network. The local area network permits communication within a limited geographic area, while a wide area network permits long-distance communications. Local area networks and wide area networks can be integrated into a single large network. A local area network provides a high-speed communications channel designed to connect information processing equipment in a specific geographic area, such as an office, a building, or a cluster of buildings (for example, a campus). The DIGITAL local area network uses the Ethernet: a single shared network channel. All nodes have equal access to the channel. Because the Ethernet is a multi-access device, new nodes can be added without affecting existing nodes on the Ethernet. An Ethernet is a coaxial cable, to which each system or device is connected by a single line. In an office or other area where personal computers and workstations are located, ThinWire Wthernet cabling is usually used. The Ethernet supports a very high rate of data transmission (up to 10 million bits per second) in a limited area. DECnet-VAX also offers comprehensive wide-area network support and long-haul connectivity over point-to-point connections. Point-to-point connections, which use the DIGITAL Data Communications Message Protocol (DDCMP), are synchronous or asynchronous. Synchronous devices provide high-speed connections over dedicated lines or telephone lines ( using modems ). Asynchronous devices provide low-speed, low-cost connections over terminal lines that are switched on for network use either permanently ( a static connection ) or temporarily ( a dynamic connection ). For example, a user on a MicroVAX can configure a dialup line to another comptuer as a dynamic asynchronous DECnet line for the duration of a telephone call. 6.1.4 System And Network Manager REsponsiblities As system manager of a DECnet-VAX node, you are repsonsible for establishing your system as a node in the network, and controlling and monitoring your node. To configure your system as a network node, you must supply information at the local node about network components, including the local node, remote nodes, circuits, lines, and objects. This information constitutes what is called the configuration database for the local node. Each node in the network has such a database. As manager of your system, you supply information about the configuration database using the Network Control Program (NCP) utility. If you are configuring a DECnet-VAX node for the first time or rebuilding the configuration database for your local node, you can use the interactive NETCONFIG.COM procedure to configure your node automatically. Once you start up your DECnet-VAX node and verify its connection to the network, you can use the NCP utility to control and monitor local network operations, and test network software operation. Planning for configuration of your node in an existing network usually involves coordinating with the system managers of other nodes in the network or with the manager of the network (if a manager has been designated) to ensure uniform network parameter settings. To create a new network, the managers of individual systems should connect their systems by means of communications lines; the system managers should then configure their own systems as network nodes and start DECnet on their nodes. A system manager of a network may also be called upon to provide DECnet-VAX host services for other DECnet nodes. Host services include loading system images and programs downline to unattended remote nodes, and receiving for interpretation upload dumps of system images from nodes that have crashed. For example, DECnet-VAX permits you to load an operating system image or a terminal server image downline to a target node. Another DECnet-VAX host service involves connecting to an unattended remote node (for example, a diskless communications server) to act as its console. For a larger network, one person, who may be the manager of a network node, is usually designated as the manager of the network. The network manager is responsible for planning, building and fine-tuning a whole network to run with maximum efficiency. The network manager makes networkwide configuration decisions, such as the kinds of paths to be established, which nodes should be routers or end nodes, and whether the network should be divided into areas. The network manager also sets values for network parameters that should be the same across the network. Managing a network usually involves regular monitoring to detect patterns of usuage and error conditions on the network, and performing remote configuration of the network to control traffic patterns and accommodate network growth. System and network managers also perform maintenance procedures (to avoid serious problems from developing) and troubleshooting procedures (to resolve problems quickly). Using network software, the manager can obtain statistics on network usuage and routing parameters. Network loggin files provide error statistics useful in diagnosing potential problems. NCP commands display the status of nodes, lines and circuits in the network. 6.2 Getting Started On The Network There are two ways to establish your VMS system as part of a DECnet-VAX network: : Bring up your VMS system as a network node: If you are the manager of a VMS system, you can physically connect your system to an existing DECnet network by means of a communications line, and bring your system up as a network node by performing the DECnet-VAX installation procedure. The DECnet-VAX installation procedure you perform on your system involves registering the DECnet-VAX key using the VMS License Management Utility, configuring your node as part of the network, starting the network, and verifying that you are connected to the network. : Create a new network: If there is no existing network to which you can connect, you can cooperate with the managers of other systems to create a new network. A network is formed when two or more systems are connected by communications lines and each system is brought up as a network node. For larger networks, the system manager of one node may also manage the network. 6.2.1 Preparing To Bring Up Your System As A Node On An Existing Network If you are the system manager of a VMS system, you can install the DECnet-VAX license and configure your system as a node on an existing network. You can be connected permanently to the network, in which case you will be able to communicate with any other node on the network. You can also optionally choose to establish a temporary connection to another system over a telephone line. This temporary DECnet connection between two systems may result in a network that exists only for the duration of the telephone call. Before you begin the procedure for starting DECnet-VAX on your system, you should check your hardware and connect any required communications lines. You should also prepare your VMS operating system for the network environment and decide how you want to configure your node. 6.2.1.1 Connecting the Communications Hardware On Your System A network is a flexible configuration of computers and terminals interconnected by communicciations lines. You should identify the equipment you need to connect your VAX computer to an existing network. For each connection, this equipment normally includes: : A communications controller device (line device) that contains one/more interface points called ports. (The line device is installed on your processor.) : A communications line to connect the port to the network. Consult your DIGITAL sales support representative if you are not familiar with the equipment that you require or if you need to install such equipment. Following the instructions in the hardware user manuals included with the equipment, you should be able to connect each network communications line to the appropriate port. A VAX computer on which a VMS operating system is running can be connected to the network by means of high-speed lines ( such as an Ethernet cable or a synchronous point-to-point line). A VMS system can also be connected to a network by means of a low speed, low cost asynchronous line. An asynchronous point-to-point connection can be established over any VMS terminal line between a VMS system and other system (which can be a non-VMS system) that supports the DECnet asynchronous DIGITAL Data Communications Message Protocol (DDCMP). An asynchronous connection can optionally be made over a dialup line (for example, a telephone line) if a modem is used at each end of the connection. A modem is a device that connects the terminal line to the telephone line. MOdems may be purchased from DIGITAL, along with the appropriate installation documentation. A VAX processor can have a number of communications ports, depending on the model. The possible connections are limited only by the number of devices that your processor can support, as specified in the DECnet-VAX Software Product Description load unit tables, and the devices that you can configure for your node. 6.2.1.1 Connecting the Communications Hardware on Your System A network is a flexible configuration of computers and terminals interconnected by communications lines. You should identify the equipment you need to connect your VAX computer to an existing network. For each connection, this equipment normally includes : A communications controller device(line device) that contains one or more interface points called ports. ( The line device is installed on your processor.) : A communications line to connect the port to the network. Consult your DIGITAL sales support representative if you are not familiar with the equipment that you require, or if you need to install such equipment. Following the instructions in the hardware user manuals included with the equipment, you should be able to connect each network communications line to the appropriate port. A VAX computer on which a VMS operating system is running can be connected to the network by means of high speed lines ( such as an Ethernet cable or a synchronous point-to-point line). A VMS system can also be connected to a network by means of a low-speed, low-cost asynchronous line. An asynchronous point-to-point connection can be established over any VMS terminal line between a VMS system and another system (which can be a non-VMS system) that supports the DECnet asynchronous DIGITAL Data Communications Message Protocol (DDCMP). An asynchronous connection can optionally be made over a dialup line ( for example, a telephone line), if a modem is used at each end of the connection. A modem is a device that connects the terminal line to the telephone line. MOdems may be purchased separately from DIGITAL, along with the appropriate installation documentation. A VAX processor can have a number of communications ports, depending on the model. The possible connections are limited only by the number of devices that your processor can support, as specified in the DECnet-VAX Software Product Description load unit tables, and the devices that your configure for your node. 6.2.1.2 Preparing Your VMS System for the Network Environment Before you bring up DECnet-VAX on your system, you should take the following steps to prepare your system to function as part of the network: Check to see if you have the privileges you need to perform network operations. The minimum privileges that a system manager normally requires to configure and control the network and run network programs are SYSPRV, OPER, TMPMBX, NETMBX, & BYPASS. A list of privileges required for network operations appears in TABLE 6-1. Enter the DCL command SHOW PROCESS/PRIVILEGES to determine which of your authorized privileges are currently enabled, and use the SET PROCESS/PRIVLEGES command to enable any additional privileges you are authorized to have that are required for network operations. Decide whether you want to establish a default nonprivileged DECnet account and directory. The nonprivileged account is a default DECnet account that is used in either of the following conditions: When a user on a remote network node does not explicitly supply access control information (the user name/password) when requesting a connection to the local node, or There is no proxy account to use on your system An account is required to use certain VMS utilities, such as MAIL or PHONE, over the network. If you want the default account you can request that the DECnet-VAX configuration procedure, NETCONFIG.COME, establish a default nonprivileged account and directory for your node automatically. As an alternative, you can establish a nonprivileged account and directory manually. Set up any proxy accounts that you want to establish for your node. A proxy login account allows a user on a remote node on the network to access data by way of a local account on your system. You should never grant proxy access to privileged accounts. If necessary, tune your VMS system to accommodate DECnet-VAX software. The network manager who establishes network configuration guidelines should provide you with any required information if you need to update VMS system parameters and quotas. ╔════════════════════════════════════════════════════════════════════════════╗ ║TABLE 6-1: VMS Privileges Required For DECnet-VAX Operations ║ ║────────────────────────────────────────────────────────────────────────────║ ║Privilege Network Operations ║ ║ACNT Required to start the network; permits you to ║ ║ suppress accounting messages ║ ║BYPASS Permits you to view passwords in the DECnet-VAX ║ ║ databases ║ ║CMKRNL Required to start the network; permits a process to ║ ║ access the VMS kernel ║ ║DETACH Required to start the network;allos you to create ║ ║ detached processes ║ ║NETMBX Required for all network userrs; needed for any ║ ║ network operation; needed to create a logical link ║ ║OPER Allows you to perform operator functions such as ║ ║ modifying the DECnet-VAX volatile database ║ ║TMPMBX Required for all network users and default DECnet ║ ║ accounts; needed to run NCP and to create a temporary║ ║ mailbox ║ ║SYSNAM Permits you to declare a name or object number in a ║ ║ user task ║ ║SYSPRV Required to access the DECnet-VAX permanent database ║ ╚════════════════════════════════════════════════════════════════════════════╝ 6.2.1.3 Planning the Configuration of Your DECnet-VAX Node Before you specify how your node is to be configured as part of an existing network, you should make the following decisions: Select a unique node name and node address for your system. If a network manager has been designated for your network, request a node name and address from the network manager. If your node is a member of a VAXcluster, obtain your node name/address from the VAXcluster manager. ( The VAXcluster node name must be set in the VMS system parameter SCSNODE and the node address in SCSSYSTEMID ). Each node in the netowrk is identified by a specific name and a numeric address by which the node is known to other nodes in the network. The node name can be no more than six alphanumeric characters ( including at least one alphabetic character ). The node address consists of an area number ( in the range from 1 to 63, w/ a default value of 1 ), and a node number ( in the range from 1 to 1023 ) separated by a period ( for example 2.2 ). If you node is a member of a VAXcluster that uses an alias node identifier ( an alias name/address), you can obtainthe alias identifier from the VAXcluster manager. An alias node identifier, common to some or all nodes in a cluster, permits remote nodes to treat the cluster as though it were a single node. Individual nodes in a VAXcluster can optionally assume the alias, while retaining their individual node names. You can use the alias adopted by the cluster, as well as your own node name, to communicate w/ other nodes in the network. Determine the node names and addresses of all other nodes in your netowrk to which you want to connect. To obtain the correct node name/address of each node, you can contact the network manager or, if necessary, the individual system managers of the other nodes. You must enter this remote node information in your network node database. Alternatively, you can determine whether the names/address of the nodes that you want to define are already defined in the network database of another node. If you have the appropriate access, you can copy the node database information from a remote node into your node database. Decide whether your system is to be a router or an end node. If you have a DECnet full function license and the accompanying DECnet-VAX key, you have the option of configuring your system as either a router or an end node. If your DECnet license and key are for the end node capability, you can only configure your system as an end node. Determine the types of connections that will be made to the network: Ethernet, synchronous DDCMP, or asynchronous DDCMP connections. You can use the network configuration procedure NETCONFIG.COM to configure all circuits and lines automatically except for asynchronous circuits and lines. 6.2.2 Installing DECnet-VAX on Your System This section describes the procedure for installing DECnet-VAX on your VMS operating system. Use this installation procedure to bring up your system as a node on an existing DECnet network. To perform the installation procedure, you should log in to the SYSTEM account on your node. The DECnet-VAX installation procedure consists of the following steps: 1. Purchase the DECnet-VAX license and the DECnet-VAX key and register the key on your system, using the VMS License Management Utility. 2. Configure your DECnet-VAX node and define the remote node names. You can configure your node and turn on the network at your node either automatically or manually. 3. If you plan to use an asynchronous DECnet connection, perform any steps needed to establish the connection. 4. Verify that your node is connected to the network. 6.2.2.1 Getting a DECnet-VAX License and Key To permit your node to communicate w/ other nodes in the networ, you must have a DECnet-VAX license and register a DECnet-VAX key on your system using the VMS License Management Utility. You can purchase either an end node or a full function license and the corresponding key. The end node key permits you to configure your node only as an end node. The full function key permits you to configure your node as either a routing node or an end node. You can also use the full function key to upgrade from end node to full function capability. 6.2.2.2 Configuring Your DECnet-VAX Node You are now ready to configure your DECnet-VAX system. You can configure the node automatically or manually. You can use the automatic configuration procedure when you first bring up the node or when you reconfigure it completely. You can use manual configuration techniques to bring up a new node, reconfigure a node, or modify an existing configuration. The system manager at each node in the network is responsible for the DECnet-VAX configuration database for the node. The database includes the files that describe the local (executor) node and the other nodes in the network w/ which the local node can communicate, as well as the circuits and lines that connect the local node to the network. The network database also includes information on the logging collection points ( such as the logging montiro ), to which network events are reported. In addition, DECnet-VAX provides a default object database desribing objects ( such as MAIL ) known to the network. Each node in the network has such a database. The configuration database comprises the volatile database ( the working copy of the database that reflects current netowrk conditions) and the permanent database ( which provides the initial values for the volatile database when you start the network ). Modifications to the volatile database exist only while the network is running. Changes made to the permanent database remain after the network is shut down, but do not affect the current system. As system manager, you provide network component information, from the point of view of the local node, int he configuration database at the local node. Use the Network Control Program ( NCP ) to supply this information in the form of parameter vaules, which determine how the various components of the network function together. Use NCP DEFINE commands to establish the contents of the permanent database and SET commands to specify the contents of the volatile database. Use PURGE commands to delete permament database entries and CLEAR commands to delete or reset volatile database entries. Configuring Your NOde Manually You can always configure your node manually; however, you have the option of doing it automatically ( as described in the next section ) if you are configuring a new node or compeletly reconfiguring a node. If you decide to configure your node manually, you must enter NCP commands to establish the permanent configuaration database and then turn on the network manually, causing the contents of the permnent database to be entered in the volatile database. A brief explanatioon of how to use NCP to establish your configuration database manually appears later in this section. If you decide to configure your node manually, you can optionally create a default nonprivileged DECnet account and directory for your node manually. Configuring Your Node Automatically You can use the interactive command procedure NETCONFIG.COM to configure your system automatically. NETCONFIG.COM configures all required permanent database entries except for remote nodes, asynchronous circuits, and lines. You can also use the command prcedure to set up the optional default nonpriviledged DECnet account on your system. Use NETCONFIG.COM only if you are bringing up your node for the first time, or want to reconfigure your node completely. The procedure purges any existing permanent database entries on your system (except for remote node entires). You must have the privilege SYSPRV to use NETCONFIG.COM to configure your node. If you decide to use the NETCONFIG.COM command procedure to configure your node automatically, perform the following steps. Default values appear in brackets [] after certain questions in the interative dialog. To accept a default, press RETURN. 1. Log in to the SYSTEM account on your node. 2. Invoke NETCONFIG.COM. Enter the following command at the dollar sign ($) prompt: $ @SYS$MANAGER:NETCONFIG The following message is displayed: DECne-VAX network configuration procedure This procedure will help you define the parameters needed to get DECnet-VAX running on this machine. You will be shown the changes before they are executed, in case you want to perform them manually. 3. Provide the node name. You will be promted as follows: What do you want your DECnet node name to be? Enter the node name you have selected ( or have been assigned by the network manager ), your node name must be six alphanumeric characters or less, and must be unique among all node names in the network (If you are on a VAXcluster node, you must press RETURN to accept the default node name that appears in brackets at the end of the prompt. This default node name is based on the SYSGEN parameter SCSNODE. If no default node name is displayed, exit the procedure and use SYSGEN to set up a value for SCSNODE, then restart the procedure. The DECnet node name of a VAXcluster node must match the value of SCSNODE ). 4. Provide the node address. You will be promted as follows: What do you want your DECnet address to be? Enter the node address you have selected/assigned. The node address is a numeric value of the following format? area-number.node-number Area-Number ( 1 to 63 ) designates the area in which the node is grouped and node number ( 1 to 1023 ), designates the node's unique address w/in the area. If you do not specify an area number, the system will supply a default area number ( the default value is 1 ). (If you are on a VAXcluster node, you must press RETURN to accept the default node address that appears in brackets at the end of the prompt. This default node address is based on the SYSGEN parameter SCSSYSTEMID. If no default node address is displayed, exit the procedure and use SYSGEN to set up a value for SCSSYSTEMID, then restart the procedure. The DECnet node address of a VAXcluster node must match the value of SCSSYTEMID.). 5. Specify router or nonrouter status. You will be promted as follows: Do you want to operate as a rounter? [NO (nonrouting)] Press return to operate as a nonrouter ( that is, as an end node ). Type YES and press RETURN if you want your ssytem to be a router and if you have registered the DECnet-VAX full function key or will register it before you start up the network. 6. Set up the nonprivileged DECnet account. You will be promted as follows: Do you want a default DECnet account? [YES] Press RETURN to set up the default nonprivileged DECnet account and directory. Type NO and Press RETURN if you do not want to set up the account. 7. Apply the configuration. The network configuration procedure displays the list of commands ncedssary to start up your network. ( An example showing the commands appears later in this section ). You will be promted as follows: Do you want these commands to be executed? [YES] Press return to configure the network; type NO and press RETURN to cancel the configuration operation. If you choose to configure the network, the procedure displays a series of information messages and the following statement: The changes have been made. 8. Turn on the network. You will then receive the following messages, ending in a prompt: If you have not already registered the DECnet-VAX key, then do so now. After the key has been registered, you should invoke the procedure SYS$MANAGER:STARTNET.COM to start up DECnet-VAX w/ these changes. ( if the key is already registered ) Do you want DECnet started? [YES] You can respond to this prompt in either of the following ways: Type No and press RETURN in response to the last prompt if you need to register the key on your system at this point. Register the key using the VMS License Management Utility. Once the DECnet-VAX key is registered, you can then start up DECnet-VAX manually w/ these configuration changes by entering the following command: $ @SYS$MANAGER:STARTNET (You can also type NO and press RETURN in response to the last prompt if the key is already registered but you do not want to start the network until a later time ). Press RETURN in response to the last prompt if you want to start the network at this time and the key is already registered. The procedure turns on the network and displays the identification numbes of the created processes. When the dollar sign ($) prompt appears, you have successfully configured and turned on the DECnet-VAX network. If you want the network to be started automaticallly each time the VMS operating system is booked, enable the following command in the SYS$MANAGER:SYSTEARUP_V5.COM ccommand procedure ( by deleteing the exclamation point at the beginning of this command line in the command procedure): $ @SYS$MANAGER:STARTNET Note that you can optionally press RETURN to start the network w/out the key being registered, if you want to use DECnet-VAX only at your local node. The key IS required if you want to establish connections to other nodes in the network. Example 6-1 shows the interatctive dialog that is dsiplayed when you invokde NETCONFIG.COM to configure node PURPLE w/ address 2.3 ass an end node w/ a default DECnet account. In this example, node PURPLE is connected to Ethernet Circuit UNA-0. ┌────────────────────────────────────────────┬───────────────────────────────┐ │EXAMPLE 6-1: SAMPLING NETCONFIG.COM DIALOUGE│ │ ├────────────────────────────────────────────┴───────────────────────────────┤ │DECnet-VAX network configuration procedure │ │This procedure will help you define the parameters needed to get DECnet │ │running on this machine. You will be shown the changes before they are │ │actually executed, in case you want to perform them manually. │ │ │ │What do you want your DECnet node name to be? : PURPLE │ │What do you want your DECnet address to be? : 2.3 │ │Do you want to operate as a router [NO(nonrouting)] : RET │ │Do you want a default DECnet Account? [YES] : RET │ │ Here are the commands necessary to set up your system. │ │ │ │--------------------------- │ │ │ │ $ RUN SYS$SYSTEM:NCP │ │ PURGE EXECUTOR ALL │ │ PURGE KNOWN LINES ALL │ │ PURGE KNOWN CIRCUITS ALL │ │ PURGE KNOWN LOGGING ALL │ │ PURGE KNOWN OBJECTS ALL │ │ PURGE MODULE CONFIGURATOR KNOWN CIRCUITS ALL │ │ $ DEFINE/USER SYS$OUTPUT NL: │ │ $ DEFINE/USER SYS$ERROR NL: │ │ PURGE NODE 2.3 ALL │ │ PURGE NODE PURPLE ALL │ │ $ RUN SYS$SYSTEM:NCP │ │ DEFINE EXECUTOR ADDRESS 2.3 STATE ON │ │ DEFINE EXECUTOR MAXIMUM ADDRESS 1023 │ │ DEFINE EXECUTOR ROUTING TYPE NONROUTING IV │ │ DEFINE EXECUTOR NONPRIVILEGED USER DECNET │ │ $ DEFINE/USER SYSUAF SYS$SYSTEM:SYSUAF.DAT │ │ $ RUN SYS$SYSTEM:AUTHORIZE │ │ ADD DECNET /OWNER="DECNET DEFAULT" - │ │ /PASSWORD="" - │ │ /UIC=[376,376] /ACCOUNT=DECNET - │ │ /DEVICE=SYS$SYSDEVICE: /DIRECTORY=[DECNET] - │ │ /PRIVILEGE=(TMPMBX,NETMBX) - │ │ /FLAGS=(CAPTIVE) /LGICMD=NL: - │ │ /NOBATCH /NOINTERACTIVE │ │ $ CREATE/DIRECTORY SYS$SYSDEVICE:[DECNET] /OWNER = [377,376] │ │ $ RUN SYS$SYSTEM:NCP │ │ DEFINE LINE UNA-0 STATE ON │ │ DEFINE CIRCUITE UNA-0 STATE ON COST 1 │ │ DEFINE LOGGING MONITOR STATE ON │ │ DEFINE LOGGING MONTIOR EVENTS 0.0-9 │ │ DEFINE LOGGING MONITOR EVENTS 2.0-1 │ │ DEFINE LOGGING MONITOR EVENTS 4.2-13,15-16,18-19 │ │ DEFINE LOGGING MONITOR EVETNS 5.0-18 │ │ DEFINE LOGGING MONITOR EVENTS 128.0-4 │ │ Do you want these commands to be executed? [YES]:RET │ │ The changes have been made. │ │ If you have not already registered the DECnet-VAX key, then do so now. │ │ After the key has been registered, you should invoke the procedure │ │ SYS$MANAGER:STARTNET.COM to start up DECnet-VAX w/ these changes. │ │ (if the key is already registered) Do you want DECnet Started [YES]: RET │ └────────────────────────────────────────────────────────────────────────────┘ 9. Define the other node names. At the Dollar sign ($) prompt, invoke the Network Control Program (NCP) by entering the following command: $ RUN SYS$SYSTEM:NCP For each remote node in the network that you want to identify by node name, enter the following command to define the node address and name in your permanent node database: NCP>DEFINE NODE address NAME name Address is the existing node address in the form area-number.node-number, and name is the node name. If you omit the area number from the node address, the area number of your local node is used. The netowkr manager or the system manager of the remote node you want to define can provide you with the correct name and address. If a node that you can access on your network has a node database that contains all the node names and addresses you want to define and you have the appropriate privileges to access that database, you can enter the following command at the NCP prompt ( provided the network is turned on ): NCP>COPY KNOWN NODES FROM node-id TO PERMANENT In this command, node-id is the node name or address of the remote node from which you are copying the information. If you specify the node name, that name must be in your volatile databse. All the node names/addresses are copied to your permanent node database from the volatile node database of the remote node. If your node is a memeber of a VAXcluster that uses an alias node identifier ( an alias node name/address ), your node can adopt the alias. Specify the following commands to define the alias node address and name in the permanent node database, and associate the alias identifier with your node: NCP>DEFINE NODE address NAME name NCP>DEFINE EXECUTOR ALIAS NODE node-id for the node-id, you can specify either the alias node address or name that you have defined. Your node can then be identified by the alias node name/address as well as by its unique node name/address when DECnet is running. Then enter the following commands to create the volatile node database for your node: NCP>SET KNOWN NODES ALL NCP>EXIT The other nodes on the network should define your node name/address in their node databases in order to be able to communicate with your node by node name. If a network manager assigned the unique node name/address to your node, the manager can define your node name in an overall network node database. 10. Determine how to proceed. You have completed the network startup procedure, if you plan to use asynchronous DECnet, continue to the next section, which describes how to establish asynchronous connections. 6.2.2.3 Establishing Asynchronous DECnet Connections to Other Systems The automatic network configuration procedure described in the previous section does not configure asynchronous lines and circuits. As a VMS system manager, you have the option of connecting your VMS system to another system by means of a low-cost, low-speed asynchronous DECnet line. The two types of asynchronous DECnet connections you can establish are as follows: : A static asynchronous DECnet connection, which creates a permanent DECnet link to a single remote node. : A dynamic asynchronous DECnet connection, which provides a temporary DECnet link. You can establish dynamic connections to different remote nodes at different times. Note that non-VMS systems that support DECnet asynchronous DDCMP lines can make asynchronous DECnet connections to VMS systems. The asynchronous connection can be between two routers, a router and an end node, or two end nodes. If you are on an end node and want to make an asynchronous connections, it will be your only cennection to the network, because an end node can only have one circuit active at a time. Establishing a Static Asynchronous Connection A static asynchronous DECnet connection is a permanent connection between two nodes. This type of connection can be made in one of two ways: : The nodes can be connected by a physical line ( a null modem cable ) attached to a terminal port at each system. No modems are required. You can communicate with the other system at any time. : The connection can be made over a dialup line using modems at both ends of the line. For example, your VMS system can establish a static asynchronous connection to a remote node over a telephone line. You can configure your static asynchronous line as soon as you have executed NETCONFIG.COM, and then turn on the network manually. If you system is brought up as a routing node, you can establish a static asynchronous connection at any time, no matter how many network connections you already have. Follow the tsteps outlined in this section to establish a static asynchronous connection. For the connection to be successful, the node with which you are creating a DECnet link must also establish an asynchronous DECnet connection with your node. ( note that the line speeds at each end of the connection must be the same ). 1. Log in to the SYSTEM account on your VMS node. 2. Load the asynchronous DDCMP driver, NODRIVER (NOA0). Enter the commands shown below at your terminal ( or include them in the SYS$MANAGER:SYSTARTUP_V5.COM command procedure before you boot the system ). $ RUN SYSTEM:SYSGEN SYSGEN> CONNECT NOA0/NOADAPTER SYSGEN> EXIT The asynchronous driver must be loaded before any asynchronous connection can be made. 3. To set up the terminal line to become a static asynchronous DECnet line, enter the DCL command SET TERMINAL at your terminal. If there is more than one terminal attached to your VMS system, you must specify a SET TERMINAL command for each terminal line that will be used for a static asynchronous DECnet connection. : Nondialup line: for a nondialup configuration, enter the following SET TERMINAL command to convert a terminal line to a static asynchronous line: $ SET TERMINAL/PERMANENT/PROTOCOL=DDCMP device-name: In this command, device-name is the name of the terminal port that is connected to the line that you want to make a static asynchronous DECnet line( all references to a device in this section refer to the terminal port ). : Dialup line: For a dialup configuration, enter the following SET TERMINAL command to convert the terminal line to a static asynchronous DECnet line with modem control. $ SET TERMINAL/PERMANENT/MODEM/NOAUTOBAUD - _$ /NOTYPE_AHEAD/PROTOCOL=DDCMP device-name: You can ensure that these SET TERMINAL commands will be executed automatically each time the network is started. Modify your SYS$MANAGER:SYSTARTUP_V5.COM command procedure to include all required SET TERMINAL commands before the command @SYS$MANAGER:STARTNET. 4. After configuring your node, configure the asynchronous lines and circuits in the network database. Use NCP commands to define each asynchronous line and accompanying circuit as being inthe ON state ( The line and circuit are turned on when SYS$MANAGER:STARTNET.COM is executed.) Enter the following commands: $ RUN SYS$SYSTEM:NCP NCP>DEFINE LINE dev-c-u STATE ON RECEIVE BUFFERS 4 - _LINE SPEED BAUD-RATE NCP>DEFINE CIRCUIT dev-c-u STATE ON NCP>EXIT Baud-rate is the speed at which the line sends and receives data. For an asynchronous line or circuit, dev-c-u is defined as follows: dev: the first two letters of the asynchronous device name ( passible values are TT and TX). c : A decimal number ( 0 or a integer ) designating a device's hardware controller. If the third letter on the device name is A, c egauls 0. If the third letter of the device name is B, c equals 1, and so on. u :The unit number of the device name; u is always equal to 0 or a positive integer. (An example is the device identifier TT-0-0, which represents the asynchronous device name TTA0. ). A minimum of four buffers should be allocated for data reception over the line. If the line speed at the other end of the connection is changed after the initial static asynchronous connection is made, you can use the DEFINE LINE command specified in step 4 to change the line speed for your end of the connection to match the line speed at the other end. The line speed will be changed the next time the line is turned on. 5. For security over a dialup connection, you can run NCP and establish optional transmit and receive passwords for the local end of the static asynchronous dialup link. The transmit password is the password sent to the other node during connection startup; the receive password is the password expected from the other node during connection startup. You must also use NCP to specify that your asynchronous circuit is to verify the password supplied by the other node. If the correct passwords are not supplied, the asynchronous connection cannot be made. Although transmit and receive passwords are not mandatory for static asynchronous dialups links, they add to their security of your DECnet connection. Passwords can contain from one to eight alphanumeric characters and must be delimited with quotation marks if they contain spaces. Specify the following commands: $ RUN SYS$SYSTEM:NCP NCP> DEFINE CIRCUIT dev-c-u VERIFICATION ENABLED NCP> DEFINE NODE node-id TRANSMIT PASSWORD transmit-password - _RECEIVE PASSWORD receive-password NCP>EXIT Node-id is the name of the remote node to which your node will be connected. Note that if you have defined passwords for the local end of the link, you must notify the remote node system manager to establish transmit and receive passwords for the remote end of the static asynchronous DECnet dialup link. 6. If the network is not already on, turn on the network at your node by entering the following command: $ @SYS$MANAGER:STARTNET This command starts the network and causes the permanent database entries defined int he previous steps to be entered in the volatile database on the running network. If the network was already running before you began the static asynchronous connection procedure, enter the following commands to cause the permanent database entries to be entered in the volatile database. $ RUN SYS$SYSTEM:NCP NCP>SET LINE dev-c-u ALL NCP>SET CIRCUIT dev-c-u ALL NCP>SET NODE node-id ALL NCP>EXIT If the line and circuit could not be set on in the volatile database, causing DECnet to fail to gain control of the line, the following error message is displayed: % NCP-I-NMLRSP, LISTENER RESPONSE - Operation Failure If the static asynchronous connection cannot be made, refer to the section on asynchronous connection problems. 7. If you want to turn off the asyncrononous lines temporarily, run NCP and enter the following: $ RUN SYS$SYSTEM:NCP NCP>SET LINE dev-c-u STATE OFF NCP>SET CIRCUIT dev-c-u STATE OFF NCP>CLEAR LINE dev-c-u ALL NCP>CLEAR CIRCUIT dev-c-u ALL NCP>EXIT To turn the static asynchronous DECnet line back on, enter the following NCP commands: $ RUN SYS$SYSTEM:NCP NCP>SET LINE dev-c-u ALL NCP>SET CIRCUIT dev-c-u ALL NCP>EXIT 8. If you want tos eitch an asyncrhonous DECnet line back to a terminal line with DECnet running, you must clear the line and circuit entries from the network volatile database. To clear the entries, enter these commands: $ RUN SYS$SYSTEM:NCP NCP>SET LINE DEV-C-U STATE OFF NCP>SET CIRCUIT DEV-C-U STATE OFF NCP>CLEAR LINE DEV-C-U ALL NCP>CLEAR CIRCUIT DEV-C-U ALL NCP>EXIT To switch the line for which modem control was not enabled back to a terminal line, enter the following command: $ SET TERMINAL/PERMANENT/PROTOCOL=NONE DEVICE-NAME: To switch the line for which modem control was enabled back to a terminal line, enter the following command: $ SET TERMINAL/PERMANENT/MODEM/AUTOBAUD - _$ /TYPE_AHEAD/PROTOCOL=NONE DEVICE-NAME: Establishing a Dynamic Asynchronous Connection A dynamic asynchronous DECnet connection is a temporary connection between two nodes, normally over a telephone line through the use of modems. The line at each end of the connection can be switched from a terminal line to a dynamic asynchronous DECnet during establishment of a dynamic connection. A dynamic asynchronous connection is normally maintained only for the duration of a telephone call. NOTE: A dynamic asynchronous connection to a VMS node can be initiated from any VMS or non-VMS node that supports the DECnet asynchronous DDCMP protocol. On a VMS node, you have the option of performing the initial steps of the dynamic asynchronous connection process ( steps 1/2 as follows ) before you turn on the network at your node ( step 3 ). The later steps of the process ( starting w/ step 4 ) must occur when the line is being switched to DECnet. Follow the steps listed in this section to establish a dynamic asynchronous DECnet connection. This procedure assumes the local VMS node is originating the connection and switching on the terminal line for DECnet use. The connection must be to a VMS node on which you have an account w/ NETMBX privilege. The steps that the system manager at the remote VMS node must perform in order for the dynamic asynchronous DECnet llink to be established successfully are also included in this section. 1. Log in to the SYSTEM account and enter the following commands interactively ( or include them in the SYS$MANAGER:SYSTARTUP_V5.COM command procedure before you boot the system ). These commands load the asynchronous driver NODRIVER ( NOA0) and install DYNSWITCH software on your system. $ RUN SYS$SYSTEM:SYSGEN SYSGEN> CONNECT NOA0/NOADAPTER SYSGEN> EXIT $ INSTALL:=$SYS$SYSTEM:INSTALL $ INSTALL/COMMAND INSTALL> CREATE SYS$LIBRARY:DYNSWITCH/SHARE - _ /PROTECT/HEAER/OPEN INSTALL> EXIT The system manager of the remote VMS node must also enter these commands. Additionally, the system manager at the remote VMS node must enter the commands that follow. These commands enable to use of virtual terminals for the terminal line that is to be switched, and set the DISCONNECT characteristic for the terminal line. ( The virtual terminal capability permits the process to continue running if the physical terminal you are using becomes disconnected. ) $ RUN SYS$SYSTEM:SYSGEN SYSGEN> CONNECT VTAO/NOADAPTER/DRIVER=TTDRIVER SYSGEN> EXIT $ SET TERMINAL/EIGHT_BIT/PERMANENT/MODEM/DIALUP - _$ /DISCONNECT DEVICE-NAME: Device-name is the name of the terminal port to which the dynamic asynchronous connection is made. 2. You must establish the required transmit password at the originating end of the dynamic asynchronous dialup link. The transmit password is the password sent to the remote node during connection startup. Use NCP to enter a command to define the transmit password for the remote node. The password can contain one to eight alphanumeric characters and should not contain any spaces. Specify the following commands: $ RUN SYS$SYTEM:NCP NCP>DEFINE NODE node-id TRANMIT PASWORD pasword NCP>EXIT Node-id is the name of the remote node with which your node is forming a connection. For each remote node with which you will create a dynamic asynchronous DECnet dialup link, you must define a transmit password in a separate command. The system manager for the node at the other end of the connection must define that same password as a receive password for your node ( the password expected to be received from your node). The remote system manager should also specify the parameter INBOUND ROUTER or INBOUND ENDNODE, to indicate the type of node ( router or end node ) that is expected to initiate the dynamic connection. The remote manager should enter the following command: $ RUN SYS$SYSTEM:NCP NCP>DEFINE NODE node-id RECEIVE PASWORD password INBOUND node-type NCP>EXIT 3. DECnet must be running on both nodes for the remaining steps. If you havenot already done so, turn on the network by entering the following command ( and request that the remote system manager do so also): $ @SYS$MANAGER:STARTNET If the network was already running before you began the dynamic asynchronous connection procedure, enter these commands to cause the permanent database entry to be entered in the volatile database: $ RUN SYS$SYSTEM:NCP NCP>SET NODE node-id ALL NCP>EXIT 4. The remaining steps can be performed by any VMS user with NETMBX privilege. Log in to your local VMS system and enter the following DCL command on your terminal to cause your process to function as a terminal emulator ( which makes the remote terminal appear to be a local terminal connection ): $ SET HOST/DTE device-name: Device-name is the name of your local terminal port that is connected to he modem. If both systems use modems with autodial capabilities ( for example, DF03, DF112 or DF224 modems that support an autodial protocol ), you can optionally include the /DIAL qualifier on the SET HOST/DTE command to cause automatic dialing of the modem on the remote node, as follows: $ SET HOST/DTE/DIAL=number device-name: 5. If you are not using automatic dialing, dial in to the remote node manually. 6. Once the dialup connection is made and you receive the remote VMS system welcome message, log in to your account on the remote node. 7. While logged in to your account on the remote node, enter the following command to cause the line to be switched to a DECnet line automatically: $ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET The following message indicates that the DECnet link is being established: %REM-S-END - control returned to local-nodename:: $ To check whether the communications link has come up, specify the following command on the local system: $ RUN SYS$SYSTEM:NCP NCP>SHOW KNOWN CIRCUITS NCP>EXIT The resulting display should list a circuit identified by the mnemonic TT or TX, depending on the asynchronous device installed on the line, and indicate that is is in the ON state. When the DCL prompt ($, by default) appears on your terminal screen, you can begin to communicate with the remote node over the asynchronous DECnet connection. If the dynamic connection is not made successfully, refer to the section on asynchronous connection problems. 8. As an alternative to switching the terminal line to a DECnet line automatically ( as described in the previous step ), you can switch the line manually. If you originate a dynamic connection to a VMS node from anon_VMS system, manual switching is required; from a VMS system, it is optional. If you are originating the connection from a non-VMS node, follow system-specific procedures to log in to the remote VMS node by means of terminal emulation. Once you are logged in to the remotenode, two steps are required to perform manual switching: Using your account on the remote VMS node, specify the SET TERMINAL command described in step 7, but add the /MANUAL qualifier: $ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET/MANUAL You will receive the following message from the remote node indicating the remote system is siwtching its line to DECnet use: %SET-I-SWINPRG The line you are currently logged over is becoming a DECnet line You should exit from the terminal emulator and switch your line manually to a DECnet line. The procedure depends on the specific operating system on which you are logged in. The following example shows how a VMS user originating a dynamic connection would perform this procedure. : Exit the terminal emulator by pressing the backslash (\) key and the CTRL key simultaneously on your VMS system. : Enter the following command to switch your tierminal line to a DECnet line manually: $ SET TERMINAL/PROTOCOL=DDCMP TTA0: : Enter NCP commands to turn on the line and circuit connected to your terminal port TTAO manually, as in the following example: $ RUN SYS$SYSTEM:NCP NCP>SET LINE TT-O-O RECEIVE BUFFERS 4 LINE SPEED 2400 STATE ON NCP>SET LINE TT-O-O RECEIVE BUFFERS 4 STATE ON NCP>EXIT Asynchronous DECnet is then started on the local VMS node. 9. You can terminate the dynamic asynchronous link in one of two ways: a: Break the telephone connection. b: Run NCP and turn off either the asynchronous line or circuit. The two commands you can use are as follows: $ RUN SYS$SYSTEM:NCP NCP>SET LINE dev-c-u STATE OFF NCP>SET CIRCUIT dev-c-u STATE OFF NCP>EXIT If either of the above NCP commands is entered at the remote node, the line returns to terminal mode immediately. If the command is entered at the local (originating) VMS node, the remote line and circuit remain on for approximately four minutes and then the line returns to terminal mode. 6.2.2.4 Shutting Down and Restarting The Network The network shuts down automatically as part of the normal VMS system shutdown procedure. If your VMS system is running, you can shut down the network at your local node without destroying any active logical links by entering the following commands: $ RUN SYSTEM:NCP NCP>SET EXECUTOR STATE SHUT NCP>EXIT When this command sequence is issued, no new links are allowed; when all existing links are disconnected, the network is turned off. While your VMS system is running, you can stop the network at your node by entering the following commands: $ RUN SYS$SYSTEM:NCP NCP>SET EXECUTOR STATE OFF NCP>EXIT All logical links are terminated immediately and the network is stopped. To turn the network on manually, specify the following: $ @SYS$MANAGER:STARTNET To start the network if it is not currently active, you must be logged in to the SYSTEM account or have the privileges listed at the beginning of the STARTNET.COM command procedure. To cause the network to be started each time the VMS operating system is booted, enable the following command in the SYS$MANAGER:SYSTARTUP_V5.COM command procedure: $ @SYS$MANAGER:STARTNET The command is supplied in the command procedure; to enable it, use a text editor to delete the exclamation point at the start of the command line. The network will be turned on automatically as part of the VMS system startup. You will not have to turn on the network again unless you should explicitly shut down the network or remove the network startup invocation from the site-specific startup command procedure. 6.2.2.5 Using NCP to Create and Tailor the Configuration Database The system manager is responsible for configuring the node for network operation by supplying information in the DECnet-VAX configuration database about the following network components: The local (executor) node Remote nodes with which the local node can communicate Local circuits Local lines Network objects network event logging The configuration database is actually two databases: a permanent database that establishes the deault parameter values for node startup, and a volatile database that contains the current parameter values in a functioning network. You can use the Network Control Program ( NCP ) Utility to build the network configuration database manually or to modify its contents. If you are configuring the node for the first time, you can use the automatic configuration command procedure, NETCONFIG.COM, to establish parameters needed to get DECnet running. The procedure for using NETCONFIG.COM is described in an earlier section. When you run NCP and enter a command, NCP will prompt you for selected parameters if you do not supply them. NCP also provides a HELP facility with information about each command, which you can access as follows: $ RUN SYS$SYSTEM:NCP NCP>HELP [topic...] Use NCP SET commands to establish the contents of the volatile database. Use NCP DEFINE commands to establish the conents of the permanent database. You must hav OPER privilege to change the volatile database and SYSPRV to change the permanent database. The permanent database information is supplied to the volatile database when the network is started ( that is, the STARTNET.COM commnd procedure is executed ). You can also use the ALL parameter with the SET command to cause all permanent database entries for a network component to be loaded into the volatile database. The basic NCP commands requried to define the network components in the permanent configuration database are as follows: $ RUN SYS$SYSTEM:NCP NCP>DEFINE EXECUTOR NCP>DEFINE NODE node-id NCP>DEFINE LINE line-id NCP>DEFINE CIRCUIT circuit-id NCP>DEFINE OBJECT object-name NCP>DEFINE LOGGING MONITOR STATE ON NCP>DEFINE LOGGING MONITOR EVENTS event-list NCP>EXIT NCP commands also recognize the plural forms of the network component names: KNOWN NODES, KNOWN CIRCUITS, KNOWN LINES, NKOWN OBJECTS. To modify the current configuration of your node, you can enter SET commands for any network component. For example, to add circuit and line entries for the Ethernet UNA defice ( the DEUNA ), enter the following commands: $ RUN SYS$SYSTEM:NCP NCP>SET LINE UNA-0 STATE ON NCP>SET CIRCUIT UNA-0 STATE ON NCP>EXIT To determine the contents of your network configuration database, use the NCP commands LIST and SHOW. The LIST commands displays information in the permanent database; the SHOW command displays volatile database entries. To delete entries from the configuratin database, use the PURGE and CLEAR commands. The PURGE command deletes permanent database entries; the CLEAR command deletes or resets volatile database entries. For example, to list the permanent name/address of a node, enter the following commands: $ RUN SYS$SYSTEM:NCP NCP>LIST NODE nod-id NCP>EXIT To delete a node form the permanent database, enter the following commands: $ RUN SYS$SYSTEM:NCP NCP>PURGE NODE node-id ALL NCP>EXIT Node-id can be either the node name or the node address. You can also delete an individual parameter for a node. Because the PURGE command does not affect the volatile ( memory-resident ) copy of the DECnet database, you can access a node deleted with the PURGE command until DECnet is started again. If you use the CLEAR command to delete a node entry, the node entry will reappear in the volatile database after DECnet is started again. 6.2.2.6 Providing Security for Your DECnet-VAX Node Some of the security measures that you can use to protect your files and system in a network environment are summarized in this section. As manager of a VMS node, you can protect your system against unauthorized access by users on other nodes in the network by setting passwords for any accounts that you may create. Otherwise, users on other nodes could gain full access to your system by using the SET HOST command to log in to one of the accounts on your node. Proteting Files and Using Proxy Accounts As a user on a VMS node, you can protect the files in your directory against access over the network. To set limits on who can access the files in your account, specify the DCL command SET PROTECTION. If your file is protected, a VMS user on a remote node who wants to access your file must be able to specify the user name and password of a local account that has the appropriate privileges to access the file. A remote user to whom you have given this informatin must then include the authorization information in the form of an access control string, "username password", in the VMS file specification used to access your file: node"username password"::devicd:[directory]filename.type;version Establishing proxy accounts. As system manager of your node, you can maintain the security of passwords by preventing their transmission over the network. You can permit selected outside users to access particular non-privileged accounts on your node without having to send any explicit access control information over the network. To do this, you must create a proxy account that allows a remote user to have access privileges on your node without having a private account on your node. If the remote user is assigned a proxy accoount on your local node that maps into a local user account, the remote user assumes the same access privileges as the owner of the local account. the system manager controls the use of proxy accounts at the local node. Use the Authroize Utility to create and modify the permanent proxy database, NETPROXY.DAT, at your node. Each NETPROXY.DAT entry can map a single remote user to multiple proxy acounts on the local node ( one default proxy account and up to 15 additional proxy accounts ). The proxy database entry identifies the user by nodename::username or nodename::(group,member). When DECnet is started up, the information in NETPROXY.DAT is used to construct a volatile proxy database. If changes are made to the permanent proxy database by means of the Authorize Utility, the volatile proxy database is updated automatically. Similarly, the system manager at a remote node can create and maintain a proxy database of network user having proxy access to specific accounts on that node. Controlling proxy login access. For proxy login to be successful, one node must be able to initiate proxy login access and the other node must allow proxy login access. To control proxy login for your local ( executor ) node, use Netowrk Control Program commands to modify the proxy parameters in the executor and object databases. The NCP parameters that specify whether a node can initiate proxy login are the outgoing proxy parameters; the parameters that specify whether a node allows proxy login access are the incoming proxy parameters. By default, both the local node and the remote node can initiate proxy login and allow proxy access. Defaults for DIGITAL supplied objects are set in the object database. For example the object MAIL has outgoing proxy access set by default. To specify or modify the proxy parameter for a network object, use the NCP command SET OBJECT. Use this command to permit outgoing proxy access for a network object: $ RUN SYS$SYSTEM:NCP NPC>SET OBJECT object-name PROXY OUTGOING NCP>EXIT Controlling Access to Your Node In general, the system manager can control access to the local node at three levels: Circuit-level access control: for point-to-point connections, especially over dialup lines, you can use passwords to verify that the initiating node is authorized to form a connectin with your node. Passwords ar usually optional for point-to-point connections but are required for dynamic asynchronous connections. Each end of a point-to-point circuit can establish a password to transmit to the oterh node, and specify a password expected from the other node. Before the link is established, each node verifies that it received the expected password from the other node. Added security is provided for a dynamic asynchronous connection ( which is normally maintained only for the duration of a telephone call ): the node requesting the dynamic connection is required to supply a password, but the node receiving the login request is prevented from revealing a password to the requesting node. Node-Level access control: To conttrol the establishment of logical links with remote nodes, you can specify in your network database access control parameters that indicate which of the following logical link connections are permitted: INCOMING, OUTGOING, BOTH, or NONE. Use the NCP commands to that follow to specify access parameters for a specific node, and the executor parameter DEFAULT ACCESS that applies to any node for which a specific access parameter is not specified: $ RUN SYS$SYSTEM:NCP NCP>DEFINE NODE node-id ACCESS option NCP>DEFINE EXECUTOR DEFAULT ACCESS option NCP>EXIT System-level access control: When a remote user requests access to the system, the following means of authorizatin are checked: Is an explicit access control string available? Does the user have a proxy account on the local node? Is there a default nonprivileged DECnet account at the local node? If no explicit access control information or proxy account is available, DECnet-VAX will attempt to use a default nonprivileged DECnet account to access the system. The default DECnet account allows users to perform certain network operations, such as the exchange of electronic mail between users on different nodes, without having to supply a name and password. The default DECnet account is also used for file operations when an access control string is not supplied. For example, it permits remote users to access local files on which the file protection has been set to allow WORLD ACCESS. If you do not want remote users accessing your node, do notcreate a default DECnet account. you can request the DEcnet-VAX configuration command procedure, NETCONFIG.COM, to establish the default nonprivileged DECnet account and directory for you automatically or you can establish the account and directory manually, as follows: $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF>ADD NETNONPRIV/PASSWORD=NONPRIV/DEVICE=device-name:- _/DIRECTORY=[NETUSER]/UIC=[200,200]/PRIVILEGE=(TMPMBX,NETMBX)- _/FLAGS=(CAPTIVE)/NOBATCH/NOINTERACTIVE/LGICMD=NL: UAF>EXIT $CREATE/DIRECTORY device-name:[NETUSER]/OWNER_UIC=[200,200] Device-name is the name of the device on which you have your directory. If a remote node requests access to an object on the local node but does not supply access control information, any access control information specified for the object in the local network database will be used. 6.3 keeping the Network Running Once you have brought up your system as a network node, you can use a variety of software techniques to monitor and test the network. You can also use troubleshooting techniques to resolve problems related to keeping the network running. The tools you can use to monitor the network and the types of tests you can perform on the network are summarized in the following sections. Common problems encountered during network operation are indicated, along with advice on troubleshooting. 6.3.1 Monitoring the Network You can monitor network activity using software tools. Analyzing the information you collect can help you to determine whether the network is running properly or whether any changes are required to resolve problems or improve performance. Major network monitoring tools include the following: NCP display commands you can use to determine the status and characteristics of components in the network. NCP counters you can read to obtain error and performance statistics on current network operations. Network events logged by DECnet that can be reported to you as they happen. Other software tools, such as the Ethernet configurator and the DECnet Test Sender/DECnet Test Receiver ( DTS/DTR ) Utility, that permit you to learn more about network operation. 6.3.1.1 Using NCP to Display Information About network Components You can use the NCP commands SHOW and LIST to monitor network activity by displaying the following: Information about the current condigtion of network components ( using SHOW commands ) and the startup values assigned to the components ( using LIST commands ). Counter information about circuits, lines, remote nodes, and the local node ( using SHOW COUNTER commands ) Information about the range of network events being logged by the DECnet event logging facitlity ( using SHOW LOGGING commands ) You do not need any privileges to issue SHOW commands, but you need the privilege SYSPRV to issue LIST commands. Use the SHOW command to monitor the operation of the running network. You can display the characteristics and current status of network circuits, lines and nodes, including the local ( excutor ) node. This information is useful in detecting any changes in the network configuratin or operation. For example, if a circuit failure causes some nodes to become unreachable, you can use SHOW commands to check the status of the circuit and the nodes. In general, the SHOW and LIST commands permit you to indicate what type of information you want NCP to display about the particular component you specify. The display types include the following: CHARACTERISTICS: Static information that does not normally change during network operations ( for example, the identification of the local node and the circuits connected to the local node, and relevant routing parameters such as circuit cost ). STATUS: Dynamic information that usually indicates network operation for the running network ( for example, the operation state of the local node, circuits, lines and remote nodes ). SUMMARY: Only the most useful information from both static and dynamic sources; usually a condensed list of informatin provided for the CHARACTERISTICS and STATUS display types. SUMMARY is the default if you do not specify a display type. COUNTERS: Counter informatioon about circuits, lines, remote nodes, and the local node. EVENTS: Information about which network events are currently being logged to which logging collection point. When you display information about network components, you can specify either the singular or plural form of the component in the NCP command. Plural forms of component names are KNOWN ( all components available to the local node ), ACTIVE ( all circuits, lines and logging not in the OFF state ), and ADJACENT ( all nodes directly connected to the local node ). typical examples of NCP display commands follow: $ RUN SYS$SYSTEM:NCP NCP>SHOW EXECUTOR CHARACTERISTICS NCP>SHOW KNOWN LINES STATUS NCP>SHOW ACTIVE CIRCUITS NCP>SHOW ADJACENT NODES STATUS NCP>LIST KNOWN NODES NCP>EXIT All NCP display commands optionally allow you to direct the information displayed to an output file you specify. You can display information about network components on remote nodes using the TELL prefix in the NCP command. The format of the command is TELL node-id SHOW component. For example, to look at remote node counters, enter the following command sequence: $ RUN SYS$SYSTEM:NCP NCP>TELL node-id SHOW EXECUTOR COUNTERS NCP>EXIT 6.3.1.2 Using NCP counters You can use NCP commands to display error and performance statistics about network components at any time while the network is running. DECnet software uses counters to collect statistics for the executor node, remote nodes, circuits and lines automatically. To display the conents of counters, use NCP SHOW COUNTER commands, as in the following typical examples of the commands: $ RUN SYS$SYSTEM:NCP NCP>SHOW EXECUTOR COUNTERS NCP>SHOW NODE node-id COUNTERS NCP>SHOW KNOWN CIRCUITS COUNTERS NCP>SHOW KNOWN LINES COUNTERS NCP>SHOW LINE line-id COUNTERS NCP>EXIT For the local node and remote nodes, counter statistics cover such subjext as connection requests, user data traffic, timouts, and errors. Circuit counters cover such topics as the transmission of data packets over the circuit, timeouts, and errors. Line counters cover such information as the transmission of bytes and data blocks over the line and relevant errors. Use NCP commands to control counter usage. You may want to reset counters to zero if you are extablishing a controlled environment for test purposes. To reset counters to zero, use the NCP command ZERO COUNTERS ( the ZERO command requries the OPER privilege ). You can zero counters for the executor node and individual nodes, circuits and lines, or all nodes, circuits and lines. In the examples of typical commands that follow, not that the word COUNTERS is optional: $ RUN SYS$SYSTEM:NCP NCP>ZERO EXECUTOR COUNTERS NCP>ZERO NODE node-id NCP>ZERO KNOWN CIRCUITS NCP>ZERO LINE line-id COUNTERS NCP>EXIT You can regulate the requency with which specific counters are logged by entering the following command sequence: $ RUN SYS$SYSTEM:NCP NCP>SET component COUNTER TIMER nn NCP>EXIT The variable nn is in seconds. Expiration of the counter timer causes the contents of the counter to be logged and the counter reset to zero. 6.3.1.3 Using DECnet Event Logging Use the DECnet event logging facility to monitor significant network events, such as circuit failures or lost packets, on a continuous basis. Whenever a network error or other meaningful event occurs, the DECnet event logger will log an event message to a terminal or file that you specify. Examples of network events that are logged as they happen include the following: Changes in circuit and line states ( for example, a circuit failure ) A node becoming reachable or unreachable Circuit and node counter values, logged before the counter is automatically reset to zero Errors in data transmission Use of invalid data link passwords Collection and analysis of network events can provide insight into why a particular error condition exists or why network performance may vary. As events are detected, the event logger sends them to a collection point for analysis. Collection points are called logging sinkgs; they can be located on the local node or at a remote node. Event data can go to one or more sinks. Each of the following types of event sinks handles event data in a slightly different way: Logging monitor. A program that receives and processes events. Events sent to the logging monitor are displayed on the screen of any terminal declaring itself a "network operator" by means of the Operator Communication (OPCOM) facility. Directing events to the OPCOM terminal is very useful for applications where the operator needs to know what is happening on the network as it happens. For example, it may be useful to know that a circuit is going down as it happens. The automatic configuration command procedure enables the logging monitor. The OPCOM process is started when the command procedure SYS$MANAGER:STARTUP_V5.COM is executed. You can enable a terminal as a network operator terminal by specifying the DCL command REPLY/ENABLE=NETWORK. Usually the operator console ( OPA0 ) is one of the OPCOM terminals. Logging console. A terminal or file that receives events in a readable format. The default logging console is the operator console. Logging file. A user-specified file that receives events in binary format, possibly for later analysis. In order for logging to occur at your node, logging must be enabled and the envents must be identified. If you use the automatic configuration command procedure, NETCONFIG.COM, logging will be established automatically. Otherwise you can use the NCP command SET or DEFINE LOGGING to set the logging sink state to be ON. To identify a remote location for a logging sink, specify the SINK node-id parameter in the command. Use one or more commands to define the events to be logged. For example, enter the following commands to cause all network events to be logged to OPCOM nd displayed at your network operator terminal: $ RUN SYS$SYSTEM:NCP NCP>SET LOGGING MONITOR STATE ON NCP>SET LOGGING MONITOR KNOWN EVENTS NCP>EXIT Alternatively, for each event class, you can specify the specific events to be logged, as follows: $ RUN SYS$SYSTEM:NCP NCP>SET KNOWN LOGGING EVENTS event-list NCP>EXIT Events in the event list are identified by class and type ( in the form class.type ). An event class refers to the DECnet software functional layer in which the event occurred. Event classes logged by DECnet include those listed in Table 6-2. The event type is a decimal number representing a unique event within the class. You can use the asterisk (*) wildcard character for event types, and you can specify a single event type or a range of types. ┌─────────────────────────────────────────────────┐ │TABLE 6-2: DECnet Event Classes │ ├─────────────────────────────────────────────────┤ │Event Clas DECnet Functional Layer │ │ │ │0 Network Management │ │1 Application │ │2 Session Control │ │3 End Communication │ │4 Routing │ │5 Data Link │ │6 Phsyical Link │ │7 X.25 packet-level events│ │128-159 VMS system-specific │ └─────────────────────────────────────────────────┘ An example of the command to speify event types 5 through 7 in event class 4 is as follows: $ RUN SYS$SYSTEM:NCP NCP>DEFINE LOGGING MONITOR EVENTS 4.5-7 NCP>EXIT The event message displayed by OPCOM is in the following form: EVENT TYPE class.typ, event-text From node-address ( node name ) Occurred ( date/time ) component type and identifier descriptive text You can use the SHOW LOGGING command to learn what logging is being performed. For example, to display complete information on all logging being conducted at all nodes, use these commands: $ RUN SYS$SYSTEM:NCP NCP>SHOW ACTIVE LOGGING KNOWN SINKS NCP>EXIT To stop monitory at the network operator terminal temporarily, enter the following commands: $ RUN SYS$SYSTEM:NCP NCP>SET LOGGING MONITOR STATE OFF NCP>CLEAR LOGGING MONITOR ALL Then enter these commands to turn monitoring back on: $ RUN SYS$SYSTEM:NCP NCP>SET LOGGING MONITOR STATE ON NCP.EXIT To disable logging at the network operator terminal permanently, enter the following commands: $ RUN SYS$SYSTEM:NCP NCP>PURGE LOGGING MONITOR ALL NCP>EXIT 6.3.2 Common Problems Encountered on the Network Once you have brought up your system as a network node, you may receive messages related to netowrking errors. Other problems that can occur at any time during network operation may not result in messages being displayed. This section explains the causes of error messages that may be displayed. 6.3.2.1 Common Eorror Messages and Meanings When you are using DECnet-VAX, you may receive network-related messages indicating software or hardware problems, transient conditions, or errors in your input. The following list displays some common netowrk-related messages, explains what condition may be causing each message, and suggests actions you can take. NCP-I-INVPVA, invalid parameter value This message is displayed if you specify a parameter value in an NCP command tht is not a valid value for the specified parameter. The name of the parameter for which the value was invalid is displayed at the end of the error message. Re-enter the command with the correct value for the parameter. SYSTEM-I-LINKEXIT, network partner exited This message is displayed if the process on the remote node exited before confirming the logical link to your node. The remote process might have exited prematurely, a timeout may have occurred at the remote node, or there may be a problem in the log file on the remote node. You could either retry the operation or try to read the NETSERVER.LOG file in the drectory of the account you are attempting to access at the remote node. ( DECnet-VAX automatically creates a NETSERVER.LOG file and places it in the directory for the appropriate account when it receives a connect request. ) SYSTEM-F-UNREACHABLE, remote node is not currently reachable This message is displayed when you attempt to connect to a node that is unreachable. You can try to access the remote node again at a later time. The message is also displayed even if the remote node does not exist, as long as you have indicated a node address or a node name that you previously defined in your node data base. You also receive notice that the node is unreachable if the value of the executor parameter MAXIMUM ADDRESS in your network database is lower than the address of the remote node you are attempting to access. Increase the value of the NCP executor parameter MAXIMUM ADDRESS in your database to be at least as high as the highest addrss of any node that you want to contact. SYSTEM-F-INVLOGIN, login information invalid at remote node This message is displayed if you attempt to access a remote node using an access control string that contains an invalid user name or password, or if you do not specify any access control information and no default DECnet account or proxy account is available at the remote node. Retry the file operation with the correct login information. SYSTEM-F-NOSUCHNODE, remote node is unknown, This message is displayed if you attempt to enter a command to access a remote node and the remote node represented by node-id is not identified in the local volitile database. Verify that the node identifier is correct, enter the node name in your node database, and retry the operation. SYSTEM-F-PATHLOST, path to network partner lost This message is displayed if you logged in to another node over the network ( for example, using the DCL command SET HOST ) and the path to the remote node is lost. The path may be lost because of too much network activity or communications problems, or because DECnet was turned off at the remote node. Wait, then check to see if the node is still reachable. If so, try again to log in. SYSTEM-F-SHUT, remote node no longer accepting connects This message is displayed if you attempt to access the remote node using a DCL command ( such as the SET HOST command ) under either of these conditions: The executor parameter DEFAULT ACCESS on the remote node has been set to NONE. The default access at theremote node must be set to permit incoming and outgoing access before you can connect to the node. SYSTEM-F-NOLINKS, maximum network logical links exceeded This message is displayed if the maximum number of links that the remote node allows has been exceeded. Wait and try again later. SYSTEM-F-NOSUCHOBJ, network object unkown at remote node This message is displayed if you attempt to access a network object at a remote node and the object is not specified in the remote node database. For example, if you attempt to use the Phone Utility to reach a node that does not have an entry for the network object PHONE in its configuration database, you receive the above message. 6.3.2.2 Problems Related to Network Operation Problems in maintaining the proper functioning of the running network can be difficult to resolve. This section describes the technique for isolating a problem to a particular DECnet software functional layer or layers, and provides troubleshooting suggestions to determine the specific network problem. As system manager of the local node, you may want to consult with the network manager ( if one is available for your network ) as necessary to resolve these problems. Troubleshooting Techniques Based on DNA layers Techniques for troubleshooting DECnet-VAX problems are based on the layered network design of DECnet-VAX as specified in the DIGITAL Network ARchitecture ( DNA ). The DNA layers are illustrated in Figure 6-1. Each layer performs particular services as part of the overall network capability provided at the node. During troubleshooting, it is useful to distinguish among the network layers in localizing the cause of a particular problem. For example, some problems are characteristic of the Data Link layer, while others are related to the Routing layer or to the End Communicatins layer ( which provides logical link services ). Figure 6-1: DECnet-VAX Software Design as Based on DNA Layers ────────────────────────────────────────────────────────────────────────────── ┌─────────────────────────────────────┐ │ USER LAYER │ ├─────────────────────────────────────┤ │ │ NETWORK APPLICATION LAYER │ │ NETWORK │ SESSION CONTROL LAYER │ │ MANAGE- │ END COMMUNICATIONS LAYER │ │ MENT │ ROUTING LAYER │ │ LAYER │ DATALINK LAYER │ ├─────────┴───────────────────────────┤ │ PHSYICAL LINK LAYER │ └─────────────────────────────────────┘ ZK-6364-HC Network Problems and Suggested Actions The following discussion of network difficulties identifies typical problems originating at the various layers, and it describes actins you can take to locate the source of the problem. The problems are grouped into those related data links, routing, and logical links. Data link problems. Inability to reach and active node is a common problem on the network. The problem could be either a data link problem or a routing problem. To determine whether the problem is a data link problem, examine both the remote node and the circuit. The data link layer causes data to be moved over physical devices, so it affects only adjacent nodes ( an adjacent node is connected to the local node by a single physical line ). You can learn whether the unreachable node is an adjacent node and whether the node is available by checking with the network manager or the system manager of the unreachable node. Also check the state of the circuits ( the data link protocol causes a circuit to be in the ON-SYNCHRONIZING state ). The problem may be with the data link if the circuit does not start up correctly or is up but the adjacent node is not reachable. ( Note that circuit startup may also be affected by incorrect setting of the transmit and receive passwords, as described in the following section on routing problems ). To locate a data link problem, examine the appropriate counters, line and circuit parameters, and network events. Use NCP SHOW commands to display the contents of the circuit and line counters to see if they are reporting errors. Use NCP SHOW commands to check the values of line and circuit parameters in the network configuration database. The look at the network events DECnet logged for event class 4 ( for the routing layer ) and event call 5 ( for the Data Link layer ) to determine whether any events affecting the data link have occurred. Routing problems. Routing layer problems can involve nodes that are not reachable or circuits that are not stable. The circuit may be up and the adjacent node may be reachable, but one or more intermediate nodes ( along the communications path ) that should be reachable are not. To isolate such Routing layer problems, examine the appropriate counters and passwords, and try to check the nodes along the routing path. Check the contents of the node and circuit counters at your node and, if possible, arrange for the node and circuit counters at the remote node to be examined. Examine network events logged for event class 4 ( for the Routing layer ). Check the setting sof the transmit and receive passwords for the local node and the adjacent node to see if they match ( these passwords affect circuit startup ). Finally, you can use NCP commands with the TELL prefix to try to trace the routing path from one node to another, to determine if an intermediate node is down and to examine the parameter values for all nodes on the communications path. If erratic routing behavior occurs ( for example, constant changes in the reachability of nodes, or connection to a node other than the one you expect to reach ), check whether two or more nodes with the same node address are connected to the network. If routing seems to be functioning properly, you can look at executor parameters related to routing ( such as cost and hops ). Logical link problems. The End Communications layer, which provides logical link servies, can also be the source of common problems. Typical symptoms of logical link problems include Link timeout Network partner exited Invalid account Problems with performance and response time In general, for logical link problems, you can examinethe following: The default DECnet nonprivileged account and directory on the remote node, to determine if they have been created properly. Incoming and outgoing timers at both ends of the logical link, to ensure the links are not timing out prematurely because the timers are set too low. The accounting log ( using the VMS Accounting Utility), to determine whether the correct process was created or whether a correct process exited prematurely. The load on the local and remotenodes, to determine whether the load is preventing the link from being created. The path over the network to the remote node. If the circuit is an Ethernet circuit, check the line buffer size parameter to ensure the proper setting. The Netserver timeouts, by getting somone to examine the NETSERVER.LOG file at the remote end. The proxy settings for your node and for the objects being accessed. ( To determine the default proxy access setting for your executor node, specify the NCP command SHOW EXECUTOR CHARACTERISTICS. To examine the proxy access setting for network objects, use the NCP command SHOW KNOWN OBJECTS CHARACTERISTCS ). The disk quota, to ensure it is sufficient to create the NETSERVER.LOG file. The SYS$LOGIN file, to determine whether the file protection is set to WORLD:READ. If a logical link connection is unsuccessful, the link may gave timed out for one of the following reasons: A heavily loaded node can cause creation of a logical link to take a long time. Incoming and outgoing timers may be set to low. A logical link problem may cause the message "network partner exited" to be displayed. This message indicates that the remote node exited before the logical link was established. Check the following: The networking load on the nodes at each end of the logical connection The accounting log on the remote end. Netserver timeouts on the remote node. If you receive a message indicating an invalid account, check that you have the proper authorization to make the logical link connection. However, an invalid account condition may also be reported by the message "network partner exited." Consequently you should try to have somone check the NETSERVER.LOG file on the remote node. If performance and resonse time over the logical link become degraded, the cause may be too much traffic on a path to the target node. If you encounter this problem, consult with the network manager. Configuration problems. The main reason for netowrk errors may be improper configuration of the system. Check your DECnet-VAX configuration, and check the communciations calbes and connection. 6.3.2.3 Asynchronous Connection Problems Attemps to establish asynchronous DECnet connections with other nodes can fail ofr a variety of reasons. This section describes some reasons why you may fail to make a static or dynamic connection. A static asynchronous connection has failed if the static asynchronous DECnet line is started but remains in the ON-STARTING state. To isolate the cause of the problem, check whether the following conditions exist. : Are the line speeds at both ends of the connection set to the same value? : If you are using a dialup line, is the modem characteristic set on the terminal? ( This must be done before the line is set to asynchronous DDCMP use.) : Are the two nodes being connected located in the same area in the network (that is, do their node addresses have the same area number) or are both nodes area routers? : Is the parity on the asynchronous DECnet line set to NONE? If your system is not a VMS system, is the terminal line set to the correct parity? : Is the terminal line set up to use 8-bit characters? : If the node already has an active circuit, is the node a routing node? : If verification is enabled for the circuit, do the passwords set at the two nodes match? If you are unsuccessful in setting up your terminal line as a static asynchronous DDCMP line, check the following: : is the /NOTYPE_AHEAD qualifier specified for your terminal before you attempt to set up the static asynchronous line? If a type-ahead buffer is associated with your terminal, you may not be able to bring up your terminal line as an asynchronous DECnet line until you terminate any process started at the remote node that may own your terminal line. If dynamic switching is being performed and the asynchronous DECnet connection is not made, first check the following: : Is DECnet started on both nodes? : Is the asynchronous DDCMP cla driver (NODRIVER) loaded by mean of SY$YTEM:YGEN at each node? : Is the dynamic switch image (DYNSWITCH) installed by means of SYS$SYSTEM:INSTALL at each node? : Are virtual terminals enabled on the remote node and, in particular, for the terminal over which you are logged in to the remote node? If the dynamic asynchronous lines are started by are left in the "ON-STARTING" state, make the following checks: : Are the two nodes that are being connected located in the same area ( that is, do their addresses have the same area number) or are they both area routers? : Are the routing initialization passwords (transmit and receive passwords) set appropriately at each node? : Is the INBOUND parameter for the initiating node set correctly in the node database at thenode receiving the connection request? : Is the parity on the asynchronous DECnet line set to NONE? If your system is not a VMS system, is the terminal line set to the correct parity? : Is the terminal line at the remote node set up to use 8-bit characters? : If the node already has an active circuit, is the node fefined as a routing node? $_END OF NIA037 [OTHER WORLD BBS]