topic Re: Network booting V4.7 from a V5.5 server in Operating System - OpenVMS

Network booting V4.7 from a V5.5 server

Stanley F Quayle — Tue, 08 Feb 2005 13:50:26 GMT

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

Re: Network booting V4.7 from a V5.5 server

Uwe Zessin — Tue, 08 Feb 2005 14:00:51 GMT

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

Re: Network booting V4.7 from a V5.5 server

Stanley F Quayle — Tue, 08 Feb 2005 15:42:34 GMT

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.

Re: Network booting V4.7 from a V5.5 server

Ian Miller. — Tue, 08 Feb 2005 15:49:07 GMT

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.

Re: Network booting V4.7 from a V5.5 server

Bojan Nemec — Tue, 08 Feb 2005 15:56:12 GMT

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

Re: Network booting V4.7 from a V5.5 server

Stanley F Quayle — Tue, 08 Feb 2005 16:31:56 GMT

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

Re: Network booting V4.7 from a V5.5 server

Stanley F Quayle — Tue, 08 Feb 2005 16:36:51 GMT

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

Re: Network booting V4.7 from a V5.5 server

Robert_Boyd — Tue, 08 Feb 2005 16:39:43 GMT

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.

Re: Network booting V4.7 from a V5.5 server

Stanley F Quayle — Tue, 08 Feb 2005 17:27:09 GMT

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*

Re: Network booting V4.7 from a V5.5 server

Stanley F Quayle — Tue, 08 Feb 2005 17:33:38 GMT

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

Re: Network booting V4.7 from a V5.5 server

Jan van den Ende — Wed, 09 Feb 2005 05:51:18 GMT

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

Re: Network booting V4.7 from a V5.5 server

Uwe Zessin — Wed, 09 Feb 2005 05:58:00 GMT

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.

Re: Network booting V4.7 from a V5.5 server

Bojan Nemec — Wed, 09 Feb 2005 06:01:57 GMT

Jan,

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

Bojan

Re: Network booting V4.7 from a V5.5 server

Uwe Zessin — Wed, 09 Feb 2005 07:03:04 GMT

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

Re: Network booting V4.7 from a V5.5 server

Volker Halle — Wed, 09 Feb 2005 13:22:21 GMT

Stanley,

regarding the RMTNOTCLS error message, this article may help:

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

Volker.

Re: Network booting V4.7 from a V5.5 server

Stanley F Quayle — Thu, 17 Feb 2005 06:58:30 GMT

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?

Re: Network booting V4.7 from a V5.5 server

Volker Halle — Thu, 17 Feb 2005 07:22:47 GMT

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.

Re: Network booting V4.7 from a V5.5 server

Stanley F Quayle — Thu, 17 Feb 2005 09:07:27 GMT

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

Re: Network booting V4.7 from a V5.5 server

Volker Halle — Thu, 17 Feb 2005 09:51:13 GMT

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.

Re: Network booting V4.7 from a V5.5 server

Stanley F Quayle — Thu, 17 Feb 2005 10:05:39 GMT

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.