Day: December 26, 2006

Boot Ok
The ID of the card was all right after all: it was set to 5 before. But it did not solve the problem of the error.
The full output:

>>>b dkb100 -flags 1,0
(boot dkb100.1.0.11.0 -flags 1,0)
block 0 of dkb100.1.0.11.0 is a valid boot block
reading 1168 blocks from dkb100.1.0.11.0
bootstrap code read in
base = 1f2000, image_start = 0, image_bytes = 92000
initializing HWRPB at 2000
initializing page table at 1e4000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code
%APB-I-FILENOTLOC, Unable to locate SYSBOOT.EXE
%APB-I-LOADFAIL, Failed to load secondary bootstrap, status = 00000910

halt code = 5
HALT instruction executed
PC = 20003d94
warning -- HWRPB is invalid.
>>>
I searched for error code 910:
$ write sys$output f$message(%x910)
%SYSTEM-W-NOSUCHFILE, no such file
$
This is weird!
So I decided to take a look in AXP082:[SYS1], the root used, and compared that to AXP082:[SYS0], the one from which Diana boots. apart form it’s obvious place ([VMS$COMMON]), SYSBOOT.EXE can be founf in [SYS0.SYSCOMMON] and in [SYS1.syscommon]. I always thought case didn’t matter, but it seems it does!
Next, I simply renamed the directory to it’s uppercase equivalent and behold:

b dkb100 -flags 1,0
waiting for pkb0.6.0.11.0 to poll...
waiting for pkb0.6.0.11.0 to poll...
waiting for pkb0.6.0.11.0 to poll...
(boot dkb100.1.0.11.0 -flags 1,0)
block 0 of dkb100.1.0.11.0 is a valid boot block
reading 1168 blocks from dkb100.1.0.11.0
bootstrap code read in
base = 1f2000, image_start = 0, image_bytes = 92000
initializing HWRPB at 2000
initializing page table at 1e4000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code
%SYSBOOT-W-NOERLDUMP, Unable to locate SYS$ERRLOG.DMP
%SYSBOOT-W-NODUMP, unable to locate system dump file

%DECnet-W-NOOPEN, could not open SYS$SYSROOT:[SYSEXE]NET$CONFIG.DAT

but then trouble begins.

%SYSINIT-I- waiting to form or join an OpenVMS Cluster
%VMScluster-I-LOADSECDB, loading the cluster security database
%SYSTEM-I-MOUNTVER, $116$DKA100: (DIDO PKB) is offline. Mount verification in progress.

%MSCPLOAD-I-CONFIGSCAN, enabled automatic disk serving
%CNXMAN, Sending VMScluster membership request to system DIANA
...
%CNXMAN, Have connection to system DIANA
%CNXMAN, Sending VMScluster membership request to system DIANA
...and this continues, and continues.Still, Diana does show a new member is coming in:

+———————————————————————-————————+
| SYSTEMS | MEMBERS |
|————————-——————————————+———-—-————|
| NODE | SOFTWARE | STATUS |
|————————+——————————————+—————————|
| DIANA | VMS V8.2 | MEMBER |
| DIDO | VMS V8.2 | NEW |
+————————-——————————————-—————————+
So the blunt way: I removed DIDO als a cluster member, that removes the whole SYS$SYSROOT tree for that node as well.. After, I re-added it the node, which creates a [SYS1] directory, including the case error, and will then wait for the new member to boot.
After having corrected the case error, booted the new server, with the same result: It will get a connect to Diana but no data seems te be received. So it won’t never get into the cluster….
Booted it one more, but locally, it will start to be a cluster of it’s own, and have not even an attempt to connect to Diana – but the system – and all disks, even the one on the shared scsi bus, are fully accesable.
It will just fail to form a cluster with Diana!
Is DECNet the part to blame??
SRM updated
The SRM has been updated to the latest version (7.0) but that did not solve the problems.
VMS 8.3
had been downloaded some time ago, but today I finished creating CD’s so I can install it on whatever system. The new AlphaServer400, perhaps?