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).
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.
Migrating from DECnet MOP to LAN MOP To migrate to LAN MOP, follow these steps:
Decide which
nodes are to provide MOP downline load service. These may be the
same nodes that currently have service enabled for DECnet.
Populate the LAN permanent device database by typing
the following command at the DCL prompt: LANCP>DEFINE DEVICE/UPDATE
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.
Disable service on each of the DECnet circuits where
it is currently enabled in the volatile database.
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:
LANCP>DEFINE DEVICE device-name/MOPDLL=ENABLE
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:
Disable the MOP
service in the volatile database by typing the following:
LANCP> SET DEVICE device-name/MOPDLL=DISABLE
Disable the MOP service in LANCP's permanent database
by typing the following:
LANCP> DEFINE DEVICE device-name/MOPDLL=DISABLE
Reenable service on each DECnet circuit in the permanent
and volatile databases.
Any nodes that you added while booting with LAN MOP
will not have been entered in the DECnet node database as targets
for downline load, and they will need to be updated when you return
to DECnet MOP.
Using CLUSTER_CONFIG_LAN.COM and LAN MOP 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.
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
Cross-Architecture Booting 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.
HP OpenVMS System Manager's Manual, Volume 2:... 
Managing the Local Area Network (LAN) Software
