|
NIA #37 - VMS System Managers Manual #6
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
???????????????????? ????????????????????????????????? ????????????????????
? 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]
|
|
