![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
Some network servers, however, create a separate directory for their files. Network server instructions for a Phase IV DECnet environment tell you to redefine a MOM$XXX logical name to include that separate directory. For example, the DECserver 700 product places its files in SYS$SYSROOT:[DECSERVER], and expects MOM$LOAD to be redefined to SYS$SYSTEM,SYS$SYSROOT:[DECSERVER].
For DECnet-Plus to load such network servers, you must redefine MOP logical names to include the directories in which their files reside. Network servers that do not have a MOP client database definition always supply a software ed field in the request program message they transmit when requesting a downline load. For these network servers, redefine the logical name MOP$NAMED_LOAD to include the directory. For example:
$ define mop$named_load sys$sysroot:[mom$system],sys$sysroot:[decserver]
For network servers that have a MOP client database definition, either you can modify the MOP$LOAD logical name, or you can modify the MOP client file specifications to include the directory specification. For example, if the client files reside in SYS$SYSROOT:[FOODIR], change:
ncl> set mop client fred system image {foobar.sys}
to
ncl> set mop client fred system image {sys$sysroot:[foodir]foobar.sys}
You must redefine these logical names after the network is started. If you start your network during system boot, edit SYS$MANAGER:NET$LOGICALS.COM to include these definitions. Digital recommends that you do not edit NET$STARTUP.COM, since that file will be replaced by a new version in future releases of DECnet-Plus.
On an OpenVMS system, during the system boot operation NET$STARTUP.COM executes. By default, NET$STARTUP.COM does not start MOP. If you want MOP to start automatically, you can define the logical name NET$STARTUP_MOP by adding it to SYS$MANAGER:NET$LOGICALS.COM. For example:
$ define net$startup_mop true
If you do not start MOP automatically, you can start MOP manually any time after starting the network by entering the following command:
$ @sys$system:startup network mop
This command creates the process portion of MOP, NET$MOP, in a detached process. The command also executes the NET$MOP_CLIENT_STARTUP.NCL and NET$MOP_CIRCUIT_STARTUP.NCL scripts.
By default, MOP writes status messages to the file SYS$MANAGER:NET$MOP_OUTPUT.LOG. You can override the default log file by defining a logical name for it before starting MOP. The following command defines NET$MOP_OUTPUT to the file name SYS$MANAGER:MOP_APR95_STATUS.LOG:
$ define net$mop_output sys$manager:mop_apr95_status.log
DECnet-Plus implements a MOP receive buffer limit to prevent memory depletion. The receive default is 100. You can modify this by defining MOP$RECEIVE_LIMIT prior to MOP startup. A value of zero means no limit.
If NET$MOP fails because MOP memory has been exhausted by receive buffers, the next thread creation failure results in a log file containing a %MOP-F-CRETHDF error, and an OPCOM message indicates that the MOP process is no longer running. You will have to restart MOP.
You can stop the MOP process as follows:
ncl> disable mop
On an OpenVMS system, determine the process id for NET$MOP, by issuing the following command:
$ show system
Then stop the process:
$ stop/id=process-id
As alternative methods for stopping MOP, you can use the following NCL command for OpenVMS:
ncl> delete mop
Make sure you have deleted all subentities before using the delete command.
Stopping the process terminates all MOP operations. It disables and deletes all MOP circuits, and then disables and deletes the mop entity. You can restart MOP any time.
Downline load operations occur in the following ways:
If you use the NCL load command, you must issue it at a load host. The NCL load command ensures that the load host at which you issue the command is the node that performs the downline load. You can specify parameters on the load mop client command lines to override current values in the load host's database. To use the load command, you must enable the console requester and load server functions for the circuit. For example:
ncl> load mop client client-name
Alternatively, you can use the load mop circuit command, which allows you to load a client system that is not specified in the client database. For example:
ncl> load mop circuit circuit-name - (1) _ncl> address lan-address, - (2) _ncl> secondary loader filename, - _ncl> tertiary loader filename, - _ncl> system image filename, - _ncl> script file filename, - _ncl> management image filename, - _ncl> verification octet-string (3)
After you issue the load command on the load host, the downline load proceeds as follows:
Note
Not all network servers support the NCL load command. If you issue a load command to a server that does not support it, the server treats the command as if it were a boot command. Refer to your network server documentation for information about load command support for your server.
If you use the NCL boot command, you can issue it from any supported network management host. This command simulates the operation that occurs when you push the boot button on the client node. The boot command allows you to directly start the remote node's bootstrap ROM, which causes the client to load itself in whatever manner its primary loader is programmed to operate. Usually the client boots from the network, but it can also boot from a local disk. To use the boot command, you must enable the console requester function for the circuit. For example:
ncl> boot mop client client-name
Alternatively, you can use the boot mop circuit command, which allows you to load a client system that is not specified in the client database. For example:
ncl> boot mop circuit circuit-name - (1) _ncl> address lan-address, - (2) _ncl> verification octet-string, - (3) _ncl> device device-name, - (4) _ncl> software id software-id, - (5) _ncl> script id script-id (6)
After you issue the NCL boot command on one of the network's management hosts, the downline load proceeds as follows. (This system can also be one of your load hosts, but it is not required.)
Automatic load service is the means by which client systems can request to be loaded with some software, without involving an operator or network manager on the load host.
The requirements for automatic load service are twofold:
You can use the client parameters in the following ways:
More than one load host can be set up to load the same client system; the first to respond loads the client.
Certain client systems are designed to ask for software by name. The load request message contains the file name part of the file specification. For such requests, MOP attempts to satisfy the load even if no client entity is defined (that is, even if no client matches the incoming message's circuit and LAN address).
MOP looks for the requested file using logical name MOP$NAMED_LOAD: as the search path, and .sys as the file type.
You can prevent MOP from loading unknown clients by setting the circuit parameter known clients only to true.
You can record MOP events showing a client-initiated downline load with the event dispatcher. To find out about the events you receive, refer to DECnet-Plus Network Control Language Reference. For information about using the event dispatcher to record events, see Chapter 12.
DECnet-Plus supports the following image formats for downline loading:
The correct choice of image attributes such as base address and transfer address depends on the hardware involved and on the primary ROM bootstrap loaders.
Management image and CMIP script files must be in RMS variable-length record format.
Automatic dump service is the means by which client systems can request to be dumped, without involving an operator or network manager on the dumping host. When a network server detects a system failure, it sends dump request to the host, or, on the LAN, to a dump assistance multicast address if a LAN host is not available. After a host responds, the network server dumps its memory. It is a valuable tool for crash analysis because you can analyze the dump file and determine why the network server failed.
There are two requirements for automatic dump service:
The client parameters are used as follows:
More than one dump host may be set up to dump the same client system; the first to respond dumps the client.
Refer to your network server documentation for information about upline dump support for your server.
OpenVMS Cluster satellites do not use upline dumping; instead, they write their memory image to the disk.
The console carrier provides access to the remote console subsystem (ASCII console) of a network server on a LAN. The console carrier interface does not use NCL. Instead, you enter commands at the operating system to use the console carrier.
For information about the console carrier on OpenVMS systems, see Appendix G.
The LAN configuration monitor listens for system id messages on the LAN and records the results. Digital-supplied LAN stations transmit a system id message every 10 minutes on average. Therefore, by listening to these messages for a long enough period of time, the configuration monitor builds a database containing details about most systems that are operational.
To enable the configuration monitor, specify the function configuration monitor when you enable the mop circuit. (See Section 10.2.)
The configuration monitor stores data it collects as a set of station subentities, one for each address from which a system id is received. The name of a station entity is constructed from the LAN address. Use the show command to view the contents of this database. To show the contents of the database used by the configuration monitor, use the following command:
ncl> show mop circuit csmacd-0 station * all
You can use the NCL show command or logical names to monitor the network.
Use the NCL show command to monitor the following network activity:
The show command allows you to monitor the operation of the running network. For example, if a circuit fails, the configuration of the running network in terms of reachable and unreachable nodes might change. NCL allows you to display information about both local and remote network entities and thereby detect existing or potential problems.
The show command lets you decide what type of information you want NCL to display about the entity you specify. You can display the following attributes about an entity:
For OpenVMS systems, you need NET$EXAMINE rights to issue the show command.
The counters used for the various entities in DECnet-Plus allow you to monitor network traffic. For example, you can examine the use of data links and perhaps anticipate network bottlenecks or failing links. This information can also help you plan future network configurations. To use counters effectively, you need to determine the rate of change in a counter. To do this, use the NCL snapshot command.
The following sequence of examples show how to use snapshot.
ncl> show routing circuit * all counters
Node 0 Routing Circuit CSMACD-0 at 1995-02-26-08:54:51.436-05:00I0.364 Counters Data PDUs Received = 0 Data PDUs Fragmented = 0 Data PDUs Transmitted = 2772 Circuit Changes = 1 Initialization Failures = 0 Control PDUs Sent = 11694 Control PDUs Received = 0 Corrupted Hello PDUs Received = 0 Creation Time = 1995-02-25-06:29:17.389-05:00Iinf
ncl> snapshot routing circuit * all counters
Node 0 Routing Circuit CSMACD-0 at 1995-02-26-08:59:06.216-05:00I0.389 Counters Data PDUs Received = 0 Data PDUs Fragmented = 0 Data PDUs Transmitted = 2793 Circuit Changes = 1 Initialization Failures = 0 Control PDUs Sent = 11733 Control PDUs Received = 0 Corrupted Hello PDUs Received = 0 Creation Time = 1995-02-25-06:29:17.389-05:00Iinf
Note
In order to display snapshot values, you must run NCL, then issue the snapshot command, and the subsequent show commands from the ncl> prompt. After you exit NCL, the snapshot values are lost.
ncl> show routing circuit * all counters
Node 0 Routing Circuit CSMACD-0
at 1995-02-26-09:01:09.046-05:00I0.402
Counters
Creation Time = 1995-02-25-06:29:17.389-05:00Iinf
Snapshot created at 1995-02-26-08:59:06.216-05:00I0.389
Actual Value Snapshot Value Difference
------------ -------------- ----------
Data PDUs Received 0 0 0
Data PDUs Fragmented 0 0 0
Data PDUs Transmitted 2806 2805 1
Circuit Changes 1 1 0
Initialization Failures 0 0 0
Control PDUs Sent 11786 11785 1
Control PDUs Received 0 0 0
Corrupted Hello PDUs Received 0 0 0
Use this information as a baseline for comparisons with later snapshots. It shows you how much time has elapsed and lets you see how much activity the counters have recorded between show commands. The information you obtain from counters might be useful either alone or in conjunction with logging information to measure the performance of a particular entity.
For a complete summary description of all network counters, including the probable causes of particular types of occurrences, refer to the DECnet-Plus Network Control Language Reference guide.
An address is a tower set that describes the protocols needed to establish a connection with a node. Tower sets are stored in the namespace. Output is similar to the following OpenVMS display. Each line of a tower corresponds to a network protocol layer.
ncl> show node 0 address
Node 0
AT 1996-03-14-10:59:41.194-05:00I8.917
Identifiers
Address =
{
(
[ DNA_CMIP-MICE ] , (1)
[ DNA_SessionControlV3 , number=19 ] , (2)
[ DNA_OSItransportV1 , 'DEC0'H ] , (3)
[ DNA_OSInetwork , 49::00-0C:AA-00-04-00-50-30:21 ](4)
) ,
(
[ DNA_CMIP-MICE ] ,
[ DNA_SessionControlV3 , number=19 ] ,
[ DNA_NSP ] , (5)
[ DNA_OSInetwork , 49::00-0C:AA-00-04-00-50-30:20 ]
) ,
(
[ DNA_CMIP-MICE ] ,
[ DNA_SessionControlV3 , number=19 ] ,
[ DNA_OSItransportV1 , 'DEC0'H ] ,
[ Internet_IP , 16.20.120.120 ] (6)
)
}
The following examples illustrate how the show command displays information about an end node routing circuit on a LAN. You can display information about other entities in the same way.
ncl> show routing circuit csmacd-0
Node 0 Routing Circuit CSMACD-0 at 1995-02-26-09:56:26.148-05:00I0.368 Identifiers Name = CSMACD-0
ncl> show routing circuit csmacd-0 state
Node 0 Routing Circuit CSMACD-0 at 1995-02-26-09:28:15.032-05:00I0.264 Status State = On
ncl> show routing circuit csmacd-0 manual data link sdu size
Node 0 Routing Circuit CSMACD-0 at 1995-02-26-09:30:24.882-05:00I0.277 Characteristics Manual Data Link SDU Size = 1492
ncl> show routing circuit csmacd-0 circuit changes
Node 0 Routing Circuit CSMACD-0 at 1995-02-26-09:31:29.597-05:00I0.328 Counters Circuit Changes = 1
ncl> show routing circuit csmacd-0 all counters
Node 0 Routing Circuit CSMACD-0 at 1995-02-26-09:43:23.042-05:00I0.235 Counters Data PDUs Received = 0 Data PDUs Fragmented = 0 Data PDUs Transmitted = 5075 Circuit Changes = 1 Initialization Failures = 0 Control PDUs Sent = 12134 Control PDUs Received = 0 Corrupted Hello PDUs Received = 0 Creation Time = 1995-02-25-06:29:17.389-05:00Iinf
ncl> show routing circuit csmacd-0 all
Node 0 Routing Circuit CSMACD-0
at 1995-02-26-09:46:16.622-05:00I0.253
Identifiers
Name = CSMACD-0
Status
UID = 756F4BB0-58F3-CA11-8008-AA000400784D
State = On
Data Link SDU Size = 1492
Data Link Port = CSMA-CD Port ETA
Characteristics
Type = CSMA-CD
Template = ""
Data Link Entity = CSMA-CD Station CSMACD-0
Enable PhaseIV Address = True
Manual Data Link SDU Size = 1492
Manual Routers = {}
Inactive Area Address = {}
Counters
Data PDUs Received = 0
Data PDUs Fragmented = 0
Data PDUs Transmitted = 5077
Circuit Changes = 1
Initialization Failures = 0
Control PDUs Sent = 12161
Control PDUs Received = 0
Corrupted Hello PDUs Received = 0
Creation Time = 1995-02-25-06:29:17.389-05:00Iinf
Use the following logical names to obtain status about network startup and configuration:
$ show logical net$startup_status
"NET$STARTUP_STATUS" = "RUNNING-ALL" (LNM$SYSTEM_TABLE)
The DECnet-Plus software reports significant events that occur during network operation. An event is an occurrence of a normal or abnormal condition detected by an entity. You can control the types of events that DECnet-Plus records for specific or general categories of events by using NCL. These event records help you track the status of network components.
PROFILE_VMS_017.HTML OSSG Documentation 2-DEC-1996 12:35:14.07
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.