HP OpenVMS Systems Documentation

To delete a node from the LAN permanent node database, enter the PURGE NODE command using the following syntax:

To delete a node from the LAN volatile node database, enter the CLEAR NODE command using the following syntax:

For the PURGE NODE and CLEAR NODE commands, the /ALL qualifier deletes all LAN nodes in the LAN permanent or volatile node database.

24.8 Understanding LAN MOP

The collection of utilities and startup command files for LANCP and LANACP provide the necessary functionality for MOP downline load service. These utilities and files load cluster satellites, terminal servers, and systems requiring downline load of special images, such as console update images or system software update images (for InfoServer load).

24.8.1 Coexistence with DECnet MOP

The LAN MOP environment provides functionality that is similar to that provided by DECnet. The result is that a system manager can choose which functionality to use, DECnet MOP or LAN MOP. For OpenVMS Cluster systems, LAN MOP permits the operation of a cluster without the presence of DECnet.

LAN MOP can coexist with DECnet MOP in the following ways:

• Running on different systems
  For example, DECnet MOP service is enabled on some of the systems on the LAN, and LAN MOP is enabled on other systems.
• Running on different LAN devices on the same system
  For example, DECnet MOP service is enabled on a subset of the available LAN devices on the system, and LAN MOP is enabled on the remainder.
• Running on the same LAN device on the same system but targeting a different set of nodes for service
  For example, both DECnet MOP and LAN MOP are enabled, but LAN MOP has limited the nodes to which it will respond. This allows DECnet MOP to respond to the remainder.

To migrate to LAN MOP, follow these steps:

1. Decide which nodes are to provide MOP downline load service. These may be the same nodes that currently have service enabled for DECnet.
2. Populate the LAN permanent device database by typing the following command at the DCL prompt:

   MCR LANCP DEFINE DEVICE/UPDATE

3. Populate the LAN permanent node database by entering a node definition for each cluster satellite node and any other nodes that are similarly defined in the DECnet node database. You can enter this data manually or execute the command procedure SYS$EXAMPLES:LAN$POPULATE.COM, following the directions and help provided.
4. Disable service on each of the DECnet circuits where it is currently enabled in the volatile database.
5. Enable service on each LAN device in the LAN permanent device database that you would like to use by typing the following command at the DCL prompt for each device:

   MCR LANCP DEFINE DEVICE device-name/MOPDLL=ENABLE

6. If high performance is required, select a data size of 1482 bytes and only reduce this if some load requests now fail. Alternatively, set up one system to load those clients that require a small data size and set up a different system to load the other clients.

To permanently migrate back to DECnet MOP, follow these steps:

1. Disable the MOP service in the volatile database by typing the following:

   MCR LANCP SET DEVICE device-name/MOPDLL=DISABLE

2. Disable the MOP service in LANCP's permanent database by typing the following:

   MCR LANCP DEFINE DEVICE device-name/MOPDLL=DISABLE

3. Reenable service on each DECnet circuit in the permanent and volatile databases.

A cluster management command procedure has been provided to facilitate the use of LANCP for LAN MOP booting of satellites. Called CLUSTER_CONFIG_LAN.COM, it resides in SYS$MANAGER and is a direct parallel to CLUSTER_CONFIG.COM, which is used by cluster managers to configure and reconfigure an OpenVMS Cluster system. The two procedures perform the same functions, but CLUSTER_CONFIG.COM uses DECnet MOP for downline load, whereas CLUSTER_CONFIG_LAN.COM uses LAN MOP and does not use DECnet for anything. Therefore, when you add a new node, CLUSTER_CONFIG_LAN.COM does not ask for the node's DECnet node name and address. Instead, it queries for an SCS node name and an SCS node ID number.

For your convenience, you can still run CLUSTER_CONFIG.COM. When you execute CLUSTER_CONFIG.COM, it checks whether LANACP for MOP booting is also running. It also checks to see if DECnet is running. If LANACP is running and DECnet is not, then CLUSTER_CONFIG.COM dispatches to CLUSTER_CONFIG_LAN.COM. If CLUSTER_CONFIG.COM discovers that both LANACP and DECnet are running, it asks the user whether LAN MOP booting is being used, and whether it should call CLUSTER_CONFIG_LAN.COM for the user.

24.8.4 Sample Satellite Load

The following example shows how to issue commands to the LANCP utility to enable MOP downline load service and to define node ZAPNOT:

set acp/opcom
set device eza0/mopdll=enable
set node ZAPNOT/addr=08-00-2B-33-FB-F2/file=APB.EXE-
             /root=$64$DIA24:<SYS11.>/boot=Alpha

The following example shows the OPCOM messages displayed when you start up the LANACP LAN server process:

%%%%%%%%%%%  OPCOM  10-JAN-2001 06:47:35.18  %%%%%%%%%%%
Message from user SYSTEM on GALAXY
LANACP MOP Downline Load Service
Found LAN device EZA0, hardware address 08-00-2B-30-8D-1C

%%%%%%%%%%%  OPCOM  10-JAN-2001 06:47:35.25  %%%%%%%%%%%
Message from user SYSTEM on GALAXY
LANACP MOP Downline Load Service
Found LAN device EZB0, hardware address 08-00-2B-30-8D-1D

%%%%%%%%%%%  OPCOM  10-JAN-2001 06:47:54.80  %%%%%%%%%%%
Message from user SYSTEM on GALAXY
LANACP MOP V3 Downline Load Service
Volunteered to load request on EZA0 from ZAPNOT
Requested file:  $64$DIA24:<SYS11.>[SYSCOMMON.SYSEXE]APB.EXE

%%%%%%%%%%%  OPCOM  10-JAN-2001 06:48:02.38  %%%%%%%%%%%
Message from user SYSTEM on GALAXY
LANACP MOP V3 Downline Load Service
Load succeeded for ZAPNOT on EZA0
System image, $64$DIA24:<SYS11.>[SYSCOMMON.SYSEXE]APB.EXE (Alpha image)

The following display shows the contents of the LAN$ACP.LOG file:

10-JAN-2001 06:47:35.02  Found LAN device EZA0, hardware address
08-00-2B-30-8D-1C
10-JAN-2001 06:47:35.18  Found LAN device EZB0, hardware address
08-00-2B-30-8D-1D
10-JAN-2001 06:47:35.25  LANACP initialization complete
10-JAN-2001 06:47:45.39  Enabled LAN device EZA0 for MOP downline load service in
exclusive mode
10-JAN-2001 06:47:54.70  Volunteered to load request on EZA0 from ZAPNOT
    Requested file:  $64$DIA24:<SYS11.>[SYSCOMMON.SYSEXE]APB.EXE
10-JAN-2001 06:48:02.23  Load succeeded for ZAPNOT on EZA0
    MOP V3 format, System image, $64$DIA24:<SYS11.>[SYSCOMMON.SYSEXE]APB.EXE
    Packets:  2063 sent, 2063 received
    Bytes:    519416 sent, 4126 received, 507038 loaded
    Elapsed time:  00:00:07.42, 68276 bytes/second

The LAN enhancements permit cross-architecture booting in a OPENVMS Cluster system. VAX boot nodes can provide boot service to Alpha satellites, and Alpha boot nodes can provide boot service to VAX satellites. Note that each architecture must include a system disk that is used for installations and upgrades.

24.9 Managing the LAN MOP Downline Load Service

The LANACP LAN server process maintains the LAN volatile node and device databases. The LANCP utility provides commands that:

• Display MOP downline load status and counters information
• Clear counters information
• Enable or disable OPCOM messages and packet tracing

Counters and status information is maintained for each node and device. Counters information includes transmitted and received byte and packet counts, transmit errors, logical errors such as protocol violations and timeouts, and number of load requests. Status includes the time of the last load and the status of the last load.

24.9.1 Enabling MOP Downline Load Service

To enable MOP downline load service, enter the SET DEVICE command using the following syntax:

In this command, use the device-name parameter to supply the LAN controller device name.

See Section 24.6.2 for a complete description of this command.

24.9.2 Disabling MOP Downline Load Service

To disable MOP downline load service, enter the SET DEVICE command using the following syntax:

In this command, use the device-name parameter to supply the LAN controller device name.

See Section 24.6.2 for a complete description of this command.

24.9.3 Displaying the Status and Counters Data

To display MOP downline load status, enter the SHOW DLL command using the following syntax:

The following display shows counters information for a particular node:

LAN MOP DLL Status:
   EXA enabled in exclusive mode for known nodes only, data size 1482 bytes
   FXA disabled

       #Loads   Packets        Bytes     Last load time       Last loaded
       ------   -------        -----  --------------------  -----------------
   EXA      5      1675      4400620  10-JAN-2001 10:27.51  GALAXY
   FXA      0         0            0

On this node are two LAN devices, EXA (DEMNA) and FXA (DEMFA). MOP downline load service is enabled on EXA in exclusive mode.

Requests are answered only for nodes that are defined in the LANACP node database. The image data size in the load messages is 1482 bytes. There have been five downline loads, the last one occurring on node GALAXY at 10:27. Finally, no downline loads are recorded for FXA, which is currently disabled for downline load service.

To display recent downline load activity that has been logged in the LAN$ACP.LOG file, enter the SHOW LOG command using the following syntax:

24.9.4 Displaying the Status and Counters Data for Individual Nodes

To display MOP downline load information for nodes in the LAN permanent node database, enter the LIST NODE command using the following syntax:

To display MOP downline load status and counters information for nodes in the LAN volatile node database, enter the SHOW NODE command using the following syntax:

Table 24-12 provides a brief description of the LIST NODE and SHOW NODE command qualifiers.

Example

The following example shows output from a command issued on a local node on which there are three nodes defined (GALAXY, ZAPNOT, and CALPAL). CALPAL has issued two load requests:

• The first request is the multicast request from CALPAL that the local node volunteered to accept.
• The second request is the load request sent directly to the local node by CALPAL for the actual load data. The elapsed time from the second load request to completion of the load was 6.65 seconds.

Node Listing:

GALAXY (08-00-2B-2C-51-28):
  MOP DLL:  Load file:   APB.EXE
            Load root:   $64$DIA24:<SYS11.>
            Boot type:   Alpha satellite

ZAPNOT (08-00-2B-18-7E-33):
  MOP DLL:  Load file:   NISCS_LOAD.EXE
            Load root:   LAVC$SYSDEVICE:<SYS10.>
            Boot type:   VAX satellite

CALPAL (08-00-2B-08-9F-4C):
  MOP DLL:  Load file:   READ_ADDR.SYS
            Last file:   LAN$DLL:APB_X5WN.SYS
            Boot type:   Other
            2 loads requested, 1 volunteered
            1 succeeded, 0 failed
            Last request was for a system image, in MOP V4 format
            Last load initiated 10-jan-2001 09:11:17 on EXA0 for 00:00:06.65
            527665 bytes, 4161 packets, 0 transmit failures

Unnamed (00-00-00-00-00-00):

Totals:
  Requests received    2
  Requests volunteered 1
  Successful loads     1
  Failed loads         0
  Packets sent         2080
  Packets received     2081
  Bytes sent           523481
  Bytes received       4184
  Last load            CALPAL at 10-jan-2001 09:11:17.29

To clear MOP downline load counters for all nodes and devices, enter the CLEAR DLL command using the following syntax:

24.9.6 OPCOM Messages

By default, OPCOM messages are enabled. Messages are generated by the LANACP LAN server process when device status changes, load requests are received, and loads complete. These messages are displayed on the operator's console and included in the log file written by LANACP, SYS$MANAGER:LAN$ACP.LOG.

To enable OPCOM messages, enter the SET ACP/OPCOM command using the following syntax:

24.9.7 Load Trace Facility

If the error data produced by the LANACP LAN server process for a load request is not sufficient to help you determine why the load is failing, you can direct the server process to record trace data. The data consists of transmit and receive packet information for every transmit and receive done by the server, and written to a log file for each load attempt. The name of the log file is SYS$MANAGER:LAN$nodename.LOG. You can record either all packet data or only the first 32 bytes of each packet.

The following list describes the typical load sequence:

1. Receive a Program Request message on the Load Assistance Multicast Address from the requesting node, code 8.
2. Transmit an Assistance Volunteer message to the requesting node, code 3.
3. Receive a Program Request message on your node address from the requesting node, code 8.
4. Transmit a Memory Load message to the requesting node with sequence number zero, code 2.
5. Receive a Request Memory Load message requesting the next sequence number (modulo 256), code 10 (decimal).
6. Repeat steps 4 and 5 until there is no more data to send.
7. Transmit a Memory or Parameter Load with Transfer Address message, code 0 or 20 (decimal).
8. Receive a final Request Memory Load message requesting the next sequence number (modulo 256) indicating that the last message has been received, code 10 (decimal).

For cluster satellite loads, the last Memory Load message contains cluster parameters. This message and the final Load with Transfer Address messages are displayed in full even if only partial trace echo has been enabled.

To enable partial tracing of packet data, enter the SET ACP/ECHO command using the following syntax:

To enable full tracing of packet data, add the /FULL qualifier:

24.9.8 MOP Console Carrier

Console carrier provides a mechanism to connect to a LAN device, such as a terminal server, that implements a management interface using the MOP console carrier protocol. The LANCP utility provides this function in the form of a CONNECT NODE command.

The command syntax is:

Table 24-13 provides a brief description of the CONNECT NODE command qualifiers.

Examples

1. CONNECT NODE GALAXY/DEVICE=EWA0

   
   This command attempts a console carrier connection to node GALAXY using the Ethernet device EWA0.

2. CONNECT NODE 08-00-2B-11-22-33/DEVICE=EWA0/PASSWORD=0123456789ABCDEF

   
   This command attempts a console carrier connection to the given node address using the Ethernet device EWA0, with a password.

Some systems recognize and respond to MOP remote boot requests. These systems typically require a password or other mechanism to prevent unwanted boot requests from triggering a reboot of the system. The LANCP utility provides this function in the form of the TRIGGER NODE command.

To request a reboot of a LAN system, enter the TRIGGER NODE command using the following syntax:

Table 24-14 provides a brief description of the TRIGGER NODE command qualifiers.

Rather than specify the format to send MOP Version 3 or 4, the LANCP utility sends one message in each format to the target node.

The following examples show how to use the TRIGGER NODE command:

Examples

1. TRIGGER NODE GALAXY/DEVICE=EWA0

   
   This command sends MOP trigger boot messages to node GALAXY using Ethernet device EWA0.

2. TRIGGER NODE 08-00-2B-11-22-33/DEVICE=EWA0/PASSWORD=0123456789ABCDEF

   
   This command sends MOP trigger boot messages to the given node address using the Ethernet device EWA0, with indicated password.