HP OpenVMS Systems Documentation

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.

10.4 Stopping 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.

10.5 Downline Loading a Client System

Downline load operations occur in the following ways:

• The client (network server or OpenVMS Cluster satellite) can initiate the downline load by starting its bootstrap ROM and sending a program load request to an eligible host. See Section 10.5.3.
• You can downline load a remote client from your host by issuing the NCL load or boot commands. See Section 10.5.1 and Section 10.5.2.

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)

1. Specifies the name of the MOP circuit over which this client can be reached.
2. You must specify circuit, address, and system image on the command line because there is no client database to supply this information. Note that the other parameters listed are optional, but that some client systems might require them.
3. Specifies the verification string. The value is an octet string of up to 16 hexadecimal digits. Enter the value as "%X" followed by an even number of digits. For more information about specifying a verification string, see Section 10.2.2.1. The default is %X0000000000000000.

After you issue the load command on the load host, the downline load proceeds as follows:

1. The load host sends a mop boot message specifying that the load should occur from the host.
2. When the client receives this message, it sends a mop request program message directly to that load host.
3. The load host and the client use additional MOP messages to transfer the client's software image or images into the client's memory.

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)

1. Specifies the name of the MOP circuit over which this client can be reached.
2. Specifies the address to which the boot message is sent. This value is required for LANs, but can be defaulted from the client entity.
3. Specifies the verification string. The value is an octet string of up to 16 hexadecimal digits. Enter the value as "%X" followed by an even number of digits. For more information about specifying a verification string, see Section 10.2.2.1. The default is %X0000000000000000.
4. Specifies the device from which the remote node is to boot itself. The interpretation and use of this parameter depends solely on the remote system.
5. Specifies the name of the software with which the remote node loads itself. The interpretation and use of this parameter depends solely on the remote system.
6. Specifies the name of the CMIP script used during the load. The interpretation and use of this parameter depends solely on the remote system.

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.)

1. The management host sends a mop boot message with the default boot option specified.
2. When the client receives this message, it transmits a mop request program message to all nodes on the LAN.
   If communication is taking place over a synchronous link, the client sends the mop request program message to the adjacent node on the link. The adjacent node issued the boot command.
3. The first system that responds to the client becomes the client's load host. The load host and the client use additional MOP messages to transfer the management host's software image into the client's memory. The client ignores other responders once the load is in progress.
   On a synchronous link, the load host transfers the software image to the client.

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:

• The load server function must be enabled for the circuit.
• A mop client entity must usually have been created to hold the parameters that are needed during the load.

You can use the client parameters in the following ways:

• Parameters to map load request to client entity
  The circuit and addresses parameters must be set correctly because these parameters from the incoming request message are used to locate the client entity.
  Alternatively, you can create a generic client entity by omitting addresses and using the device types parameter. Such a client entity will match any load request that specifies a communications device type that occurs in the device types set.
• Files used during the load
  The client system asks for software in generic terms, for example, a load request might ask for "the operating system." The various file attributes, in this case system image, are used to locate the file to be loaded. More than one file specification may be given; the first file that can be opened is used.
  The design of the client system determines which of the various files (secondary loader, system image, and so forth) are needed. The configuration information for the client should give you this information.
• Parameters to be given to the loaded client
  These parameters are set by the phase iv client and phase iv host attributes. They are necessary if the client is to operate with Phase IV DECnet protocols, and they might also be needed for DECnet Phase V systems. Refer to your network server configuration documentation for more information.

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.

10.5.4 Supported Image Formats for Downline Loading

DECnet-Plus supports the following image formats for downline loading:

• Native OpenVMS system image with header. MOP only loads the first image section. Use the linker qualifiers /SYSTEM/HEADER to create the file in an appropriate format.
• RSX task image without task header. Use the /-HD when building the task.
• VAX ULTRIX image files, in omagic, nmagic, or zmagic format. These formats correspond to the ld options -N, -n, and -z, respectively.
• RISC ULTRIX image files, in omagic format only. Use the ld option -N to create a suitable image.

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.

10.6 Automated Upline Dumping

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 dump server function must be enabled for the circuit.
• A mop client entity must usually have been created to hold the parameters that are needed during the dump.

The client parameters are used as follows:

• Parameters to map dump request to client entity
  The circuit and addresses parameters must be set correctly because these parameters from the incoming request message locate the client entity.
  Alternatively, you can create a generic client entity by omitting addresses and using the device types parameter. Such a client entity will match any load request that specifies a communications device type that occurs in the device types set.
• Parameters used during the dump
  The dump file parameter names the file to be created to hold the memory dump data; more than one file can be specified, in which case the first that can be opened is used.
  The dump address parameter specifies the first location to be dumped; this should be left at zero, the default value.

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.

10.7 Console Carrier

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.

10.8 Using the LAN Configuration Monitor

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.

11.1 Using the NCL Show Command to Monitor the Network

Use the NCL show command to monitor the following network activity:

• Determine the status and characteristics of components in the network.
• Obtain error and performance statistics about current network operations.

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:

• Characteristics --- describe the operating parameters of an entity as they are defined in the database.
• Counters --- tabulate the number of times the entity performed a particular operation, or the number of times a certain condition or event has occurred since the entity was created.
• Identifiers --- specify the simple name assigned to an entity when it was created.
• Status attributes --- record current conditions of the entity, such as its state.

For OpenVMS systems, you need NET$EXAMINE rights to issue the show command.

11.1.1 Using Counters to Evaluate Network Operations

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.

• The following command shows the output for all routing circuit counters using the show command before using 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

• The following command shows the output for all routing circuit counters using the snapshot command. Note that the command displays the current counters.

  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

• The following command shows the output for all routing circuit counters using the show command after issuing the snapshot command. The difference column in the table shows the difference between the actual value of the counter and the value of the counter when you used the snapshot command. Until you exit from NCL, the snapshot display appears whenever you issue the show routing circuit * all counters command.

  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.