Network booting V4.7 from a V5.5 server

[Stanley F Quayle]

I have a VAX running VMS V5.5. I have a second system disk that I'd like to "serve" to another VAX so it can network boot that version (V4.7). But I don't want it to cluster with the boot server.

I can do this with LANCP in VMS 6.x with DECnet-Plus (pardon the wrap):

$ MCR LANCP
set node X /addr=08-00-02-xx-xx-xx /file=niscs_load.exe
/root=DISK2:[SYS0.]

However, I can't seem to find the corresponding incantation for VMS 5.5 with DECnet (IV, non-Plus).

[Uwe Zessin]

I am not surprised...

LANCP appeared in VMS V6.2. It provides an alternate MOP load mechanism when the customer does not want to run DECnet at all.

DECnet-Plus, by the way, has its own built-in MOP load mechanism that does not depend on LANCP (at least that was the case when I last played with it).

[Stanley F Quayle]

Going to a new version of VMS isn't an option on this situation.

It's easy to set up a node to boot with @CLUSTER_CONFIG, and I used this as a starting point. I've had a limited success in getting it working -- it will start to boot the alternative operating system, but fail when it doesn't join the cluster.

[Ian Miller.]

If it does not join the cluster then it can't synchronize access to the v4.7 disk with the boot server - you have two unclustered nodes accessing the same disk which sounds like bad news to me. Parhaps thats why it fails when it can't join the cluster - to protect against this.

[Bojan Nemec]

Stanley,

Have you tried with DECnet replacing LANCP:
NCP> SET NODE X HARD ADDR 08-00-02-xx-xx-xx
NCP> SET NODE X LOAD ASSIST AGENT sys$share:niscs_load.exe
NCP> SET NODE X LOAD ASSIST PARAMETER DISK2:[SYS0.]


Bojan

[Stanley F Quayle]

> If it does not join the cluster then it can't synchronize access to the v4.7 disk with the boot server - you have two unclustered nodes accessing the same disk which sounds like bad news to me.

But I can do this with DECnet-Plus and LANCP.

[Stanley F Quayle]

Here's the configuration:

Node Volatile Characteristics as of 8-FEB-2005 16:27:47

Remote node = 1.499 (OFFICE)

Hardware address = 08-00-2B-2A-22-F8
Load Assist Agent = SYS$SHARE:NISCS_LOAD.EXE
Load Assist Parameter = DISK$VMS062:[SYS0.]

---------------------------------------------
Actually, I'm booting a VMS V6.2 image instead of V4.7, but the sequence should be the same.

---------------------------------------------
Here's what shows up on the console:

%%%%%%%%%%% OPCOM 8-FEB-2005 16:28:28.13 %%%%%%%%%%%
Message from user DECNET on SIMH55
DECnet event 0.7, aborted service request
From node 1.400 (SIMH55), 8-FEB-2005 16:28:28.11
Circuit QNA-0, Line open error, File open error, Load file
%SYSTEM-F-ROPRAND, reserved operand fault at PC=0001B0DC, PSL=03C00000
Node = 1.499 (OFFICE), Ethernet address = 08-00-2B-2A-22-F8


The Load Assist Agent is actually run by the boot host. And it can't run the V6.2 image in this case.

So, I tried the following:

NCP>set node office load assist agent sys$library:niscs_load.exe

But it still fails:

%%%%%%%%%%% OPCOM 8-FEB-2005 16:35:55.69 %%%%%%%%%%%
Message from user DECNET on SIMH55
DECnet event 0.7, aborted service request
From node 1.400 (SIMH55), 8-FEB-2005 16:35:55.65
Circuit QNA-0, Line open error, File open error, Load file
%SYSTEM-F-ROPRAND, reserved operand fault at PC=0001B0DC, PSL=03C00000
Node = 1.499 (OFFICE), Ethernet address = 08-00-2B-2A-22-F8

[Robert_Boyd]

There is an inherent problem with your idea -- booting over the network from remotely served disk in the OpenVMS environment requires MSCP access after the initial load of the bootstrap loader image. This means the system booting must join the cluster to maintain the connection to the drive -- unless it is loading a diskless system like ELAN which loads itself in memory and doesn't need the disk drive after the initial load.

You'll want to find yourself a copy of the DECnet Phase IV documentation and read up on how to set up a MOP loader and see if you find any further answers there.

[Stanley F Quayle]

Over in comp.os.vms, Keith A. Lewis suggested something like the following:

Remote node = 1.499 (OFFICE)
Hardware address = 08-00-2B-2A-22-F8
Load file = VMB.EXE
Load Assist Agent = SYS$SHARE:NISCS_LAA.EXE
Load Assist Parameter = DISK$VMS062:

Unfortunately, that fails with:

%%%%%%%%%%% OPCOM 8-FEB-2005 17:22:45.11 %%%%%%%%%%%
Message from user DECNET on SIMH55
DECnet event 0.7, aborted service request
From node 1.400 (SIMH55), 8-FEB-2005 17:22:45.09
Circuit QNA-0, Line open error, File open error, Load file
%LAA-F-RMTNOTCLS, remote node is not a VAXcluster member
Node = 1.499 (OFFICE), Ethernet address = 08-00-2B-2A-22-F8

*sigh*

[Stanley F Quayle]

> unless it is loading a diskless system like ELAN which loads itself in memory and doesn't need the disk drive after the initial load.

Hmmm. The V4.7 system MOP-downloads embedded MicroVAX II's in test equipment. It's quite possible that they're running VAXELN.

At this moment, I don't have access to the system to determine if the MV II's are running VMS or not.

[Jan van den Ende]

Stanley,

_even_ if you wanted those systems to be clustered, NI-clustering was only introduced in V5, so V4.7 will not go.

I strongly agree with Ian: un-coordinated access by two (more) systems to the same disk is _THE_ optimum scenario for disaster!.

Of course the loading WILL start: at first it is only the boot-server that accesses the drive, just to read some files and transfer them over the net.

Now, _IF_ that was a VaxELN (or any other) memory-resident image, that does not require (write) access to the disk, THEN that is OK.
I see no way in which you can MSCP serve a disk to nodes that are not members of the local cluster.


I will follow this thread with a most curious interest!!

Proost.

Have one on me.

Jan

[Uwe Zessin]

That's not _quite_ correct, Jan.

A very simple NI-style clustering with a single boot node was introduced with VMS V4.5c or around that release.

[Bojan Nemec]

Jan,

There was a special V4.7A version which introduced the NI-clustering.


Bojan

[Uwe Zessin]

The "A" in V4.6A and V4.7A was processor support for some MicroVAX machines.

[Volker Halle]

Stanley,

regarding the RMTNOTCLS error message, this article may help:

http://h18000.www1.hp.com/support/asktima/operating_systems/CHAMP_SRC930603000522.html

Volker.

[Stanley F Quayle]

To summarize the discussion here and on comp.os.vms, it seems that this doesn't work unless the system becomes a member of the cluster. And I've confirmed that at the customer's site -- the network-booting system joins the cluster.

So, does VMS 4.7 cluster with VMS 5.5-2?

[Volker Halle · Accepted solution]

Stanley,

the cluster software version (CLU$GB_CLUVER) for V5.1 (or higher) is 6, but for V4.7 it's supposed to be 2. And you can only cluster 2 nodes, if the cluster software version is not more than 1 version number apart.

I don't have a V4.7 system at hand, but you can find out the version with SDA:

$ ANAL/SYS ! example from an E8.2 system
SDA> exa clu$gb_cluver
CLU$GB_CLUVER: 00000000.00000006 "........"

Volker.

[Stanley F Quayle]

> And you can only cluster 2 nodes, if the cluster software version is not more than 1 version number apart.

Interesting. I checked the value on both V5.5-2H4 and V7.3, and it's 6. But I know that I can't cluster (successfully) these versions. The V5.5-2H4 system joins the cluster and then hangs...

I'll have the client check the version on his V4.7 system...

[Volker Halle]

Stanley,

the new node should crash itself with a CLUSWVER bugcheck, if the cluster software versions are incompatible with existing nodes in a cluster.

If it 'hangs', something else may be wrong/incompatible. Just force a crash on the hanging node and try to look around with SDA.

Volker.

[Stanley F Quayle]

Well, that's not important to this problem. I'm still trying to find out how to boot this V4.7 system.

I suppose I *could* have the device have its own system disk, and access everything else via DECnet.

[Volker Halle]

Stanley,

re: V5.5-2H4 and V7.3 in same cluster:

I got a chance to try to boot our V5.5-2H4 CHARON-VAX into our mixed version and mixed architecture cluster (VAX V6.2 up to I64 E8.2) and it does not work...

The V5.5-2H4 node is being rejected by the first of the E8.2 systems and crashes with

CLUSWVER - Software version incompatible with existing VMScluster
(R0 = %SYSTEM-F-REJECT, R1=00008106 = CLMDRS$C_VERSION = version mismatch).

Beyond the cluster software version (CLU$GB_CLUVER), which is 6 for all those systems, there are also checks for the cluster protocol version (stored in CSB$B_ECOLVL+1, visible with SDA> SHOW CLUSTER in the CSB of each node:
...
Eco/Version 0/23 ! for V5.5-2H4
...

V7.3 (and higher) includes checks to allow everything up from V6.0 (Protocol version 24.), but won't allow the V5.5-2H4 system, which has 23.

Volker.

[Ian Miller.]

Volker,
its intersting to know V6.2, V7.3 and V8.2 will work in the same cluster as I may be doing that next month.

[Volker Halle]

Here is the V7.2 Release Notes text, which explains the cluster restrictions regarding V5.5-2 (and earlier):

4.14.2.1 Mixed-Version Incompatibilities
V7.2

A change to the OpenVMS Cluster Version 7.2 software prevents systems running OpenVMS Version 7.2 from participating in a cluster in which one or more nodes are running any of the following software versions:

OpenVMS VAX Version 5.5-2 or earlier versions
OpenVMS Alpha Version 1.5 or OpenVMS Alpha Version 1.0

If you attempt to boot a Version 7.2 node into a cluster containing a node with any of these older versions, the Version 7.2 node cannot join the cluster, and it crashes with a CLUSWVER bugcheck.

Similarly, if you attempt to boot a node running one of these older versions into a cluster in which one or more nodes are running Version 7.2, the older version node cannot join the cluster, and it crashes with the same CLUSWVER bugcheck.

Volker.