HP OpenVMS Systems Documentation

The following sections show the commands to create the mop entities you need to accomplish the tasks described in this chapter. For the variables, substitute values appropriate to your configuration. Refer to the DECnet-Plus Network Control Language Reference for more information about these attributes. Section 10.2.2 shows how to set up the mop client for a network server , while Section 10.2.3 shows how to set up the mop client for an OpenVMS Cluster satellite.

10.2.1 Configuring MOP and MOP Circuits

This section shows how to create mop and mop circuits entities. Figure 10-1 shows the mop entity and its subentities.

Figure 10-1 mop Entity

1. Create and enable the mop entity as follows:

   ncl> create mop ncl> enable mop

2. Create a mop circuit entity and use the set command to customize the entity definition for the specified circuit:

   ncl> create mop circuit csmacd-0 type csma-cd (1) ncl> set mop circuit csmacd-0 - _ncl> link name csma-cd station csmacd-0, (2) _ncl> known clients only value (3) ncl> enable mop circuit csmacd-0 - _ncl> functions (load server, dump server, console requester, - _ncl> configuration monitor, loop requester, query requester, - _ncl> test requester) (4)

   1. Specify any name you want for circuit, but for convenience you might want to specify the same name you used for the station entity (see next callout).
   2. For the data link station name, specify the name of the circuit you used when you created the csma-cd station entity. (For more information about the csma-cd station, see Section 8.3.1.1.)
   3. Specifies whether MOP should attempt to service load requests from remote systems that do not have a corresponding client entity. Some network servers are designed to request specific software by name. In such a case, there is no need for a client entity to exist.
      By default (false), MOP tries to process requests for named software from unknown clients. Set this attribute to true if you want MOP to ignore such requests.
   4. Specify one or more functions for which you want to use MOP. For instance, specify console requester if you want to use the boot mop or load mop commands or the console carrier.
      Do not enable the configuration monitor unless you plan to use it, because it consumes relatively large amounts of system resources.
   
   Note that for each mop circuit entity, DECnet-Plus dynamically creates a mop circuit operation entity for each ongoing MOP operation. Thus, you can issue the show command for mop circuit entities to display current values of their characteristics. For example:

   ncl> show mop circuit circuit-name operation * all

You can have a variety of network servers on a network. Different kinds of network servers require different levels of information for downline loading and upline dumping. For instance, a terminal server requires the hardware address and the system image. A DECnet Phase V router requires the hardware address, the system image, and the management image or script file, depending on the kind of router you have.

For information about configuring a mop client for an OpenVMS Cluster satellite, see Section 10.2.3.

The following command example shows how to set up and define the characteristics for the mop client subentity for a network server. The mop client is a set of characteristics that represents the target node. These collected characteristics are known as the client database. The example shows all possible information you might need to provide. Refer to your network server documentation for the exact information you need to provide.

ncl> create mop client client-name

ncl> set mop client client-name -
_ncl> circuit circuit-name, - (1)
_ncl> addresses {lan-address, hardware-address}, - (2)
_ncl> secondary loader {filename}, -
_ncl> tertiary loader {filename}, -
_ncl> system image {filename}, -

_ncl> diagnostic image {filename}, -
_ncl> script file {filename}, -
_ncl> management image {filename}, - (3)
_ncl> verification octet-string, - (4)
_ncl> device types {device-types}, - (5)

_ncl> phase iv client address phase-iv-address, -
_ncl> phase iv client name phase-iv-name, -
_ncl> phase iv host address phase-iv-address, -
_ncl> phase iv host name phase-iv-name, - (6)

_ncl> dump file {filename} - (7)
_ncl> dump address address (8)

1. Specifies the name of the MOP circuit over which this client can be reached.
2. Phase IV nodes can use an extended DECnet LAN address as well as their hardware address, so you must include both of these addresses in the addresses set.

   Note For clients configured with NET$CONFIGURE, the extended Phase IV DECnet address is automatically added if you supply the Phase IV client address when prompted. For clients configured with NCL, you must manually include the additional address.

   
   To calculate the extended Phase IV, proceed as follows:
   1. Convert the Phase IV node address (in the format area-number.node-number) to its decimal equivalent, using the following conversion algorithm:
      (area-number * 1024) + node-number
   2. Convert the decimal node address to its hexadecimal equivalent, reversing the order of the bytes to form the hexadecimal node address.
   3. Incorporate the hexadecimal node address in the following format:
      aa-00-04-00-hexnodeaddress
   
   For example, to determine the Ethernet physical address of a node whose node address is 63.171, calculate the following:
   (63 * 1024) + 171 = 64683 decimal = FCAB hexadecimal
   This calculation results in the following Ethernet physical address of the node:

   aa-00-04-00-ab-fc

3. secondary loader, tertiary loader, system image, diagnostic image, script file, and management image all specify files that can be used during a downline load.
   The load sequence for a client-initiated request is as follows: The first program to run at the target node is the primary loader. Typically, this program is either executed directly from the client's bootstrap ROM, or it is in the microcode of the load device. Usually, the primary loader requests a secondary loader program, which then might request a tertiary loader, which, in turn, might request an operating system. The final module to be loaded is the management file or the CMIP script file. In this sequence, each program or file requests the next one until the management file or CMIP script file is loaded.
   Refer to your network server documentation to find out which of these files you need. In some cases, the client might specify a file name when it requests to be loaded; in this instance, you do not have to specify the file when setting up the client.
   Fields in these file specifications are defaulted. If the file specification comes from the client database, the default device and directory are provided by the logical name MOP$LOAD. If the client specifies a file name in the load request message, the default device and directory are provided by the logical name MOP$NAMED_LOAD. These logical names are created by NET$STARTUP, but you can modify them. The default file type is .SYS for the secondary loader, tertiary loader, system image, and diagnostic image files. It is .DAT for management images and CMIP script files.
4. 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.
5. Specifies one or more device types associated with this client. Use device types and omit addresses if you want to set up a generic client entity. The entity will be used for any incoming load or dump requests that specify a matching communications device type. To discover the communications device type for a particular network server, refer to your network server documentation, or use the configuration monitor function of MOP.
6. Use phase iv client address, phase iv client name, phase iv host address, and phase iv host name to specify client and host names and addresses for Phase IV systems. Enter these in the area-number.node-number format.
7. dump file specifies the file to which MOP writes when it dumps the network server. Refer to your network server documentation for information about dump support for your server.
   The default device and directory are provided by the logical name MOP$DUMP. This logical name is created by NET$STARTUP but you can modify it. The default file type is .dmp.
8. dump address specifies the first location of client memory to be dumped. Specifying any value other than zero might affect your ability to use a dump analysis tool on the dump file. Change the dump address only if your client documentation suggests such action.

To guard against unauthorized access, some network servers require that a 16-digit hexadecimal service password be present in MOP load, boot, or remote console requests. The way the password is set up for a particular server depends on the design of that server. For example, a server might use a console command to change a password held in nonvolatile RAM.

When you attempt to boot the server using the NCL boot or load commands, or to connect to the server's remote console using the ccr command, you must specify the correct password, or the server ignores the request. You can specify the password in the verification client attribute or command parameter.

When using NCP in a Phase IV network, the service password is interpreted as an unsigned integer of up to 16 hexadecimal digits. You can omit leading zeros. In keeping with the definition as an integer, the rightmost digits occupy lower addresses in memory than did the leftmost digits.

When using NCL in a DECnet Phase V network, the service password or verification value is interpreted as an octet string of up to 16 hexadecimal digits. You can omit trailing (rightmost) zeros on input. Leftmost digits occupy lower addresses in memory than do rightmost digits.

If a particular network server provides a command to set up the password value, the password syntax might be like NCP, treating the value as an integer, or it might be like NCL, treating the value as an octet-string. If the server's syntax is like NCP, you need to specify the password in different ways on the server and on the host system.

To convert an NCP-style value to an NCL-style value, do the following:

1. Add leading zeros to make the value exactly 16 digits.
2. Working from right to left on the NCP-style value, copy each pair of digits to the NCL-style value.
3. Prefix the NCL-style value with "%X".

For example, if you have an NCP service password value of:

123456789ABCD

The NCL verification value is:

%XCDAB896745230100

%XCDAB896745230100

Verif=CD-AB-89-67-45-23-01-00

The following command example shows how to set up and define the characteristics for the mop client subentity for an OpenVMS Cluster satellite. The mop client represents the target node. You can either use the commands listed below to set up your OpenVMS Cluster satellite or you can use the command procedure CLUSTER_CONFIG.COM. For more information about CLUSTER_CONFIG.COM, refer to the OpenVMS Cluster Systems for OpenVMS guide.

ncl> create mop client client-name
ncl> set mop client client-name -
_ncl> circuit circuit-name, -
_ncl> addresses {lan-address}, -
_ncl> system image {"@net$niscs_laa(dev:[root.])"}, - (1)
_ncl> verification octet-string (2)

1. Specifies the load assist agent. The load assist agent is an image that supplies MOP with the initial OpenVMS load image for the OpenVMS Cluster satellite. DEV:[ROOT.] indicates that you should specify the system root for the OpenVMS Cluster satellite you are loading. For more information about OpenVMS Cluster satellites, refer to OpenVMS Cluster Systems for OpenVMS.
2. 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.

Section F.6 provides an example of configuring MOP for either an OpenVMS Cluster satellite or a network server.

10.2.4 After Configuring MOP

After you have created the entities, defined their characteristics, and enabled the mop client entities and the mop circuit entities, use the load, boot, loop, query, and test commands to perform MOP operations. (For information about using the load and boot commands, see Section 10.5.1 and Section 10.5.2.) For information about using the loop, test, and query commands, refer to the DECnet-Plus Problem Solving guide. Use the show command to display information about all aspects of the mop entity and MOP operations.

10.2.5 MOP's Use of Default Directories

MOP uses logical names to identify directories where it expects to find images or to write dump files. MOP defines the logical names shown in Table 10-2 in NET$STARTUP.COM.

Phase IV DECnet used a set of MOM$XXX logical names. Network server software already installed on your system and network server installation kits that have not yet been updated for DECnet Phase V expect these MOM$XXX logical names. For backward compatibility, NET$STARTUP.COM defines these MOM$XXX logical names to their default Phase IV values.

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.

10.3 Starting MOP

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