Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Cluster_config

Dock
Occasional Contributor

Cluster_config

I have a VMS (7.32) cluster consisting of two Alpha 4100 using FC to HSG80 Controller/storage.
I tried to add a third Alpha 4100 into the cluster. (It was running standalone VMS previously).
I connected the third node all right into HSG80. Then ran cluster_config (as per the manual) on one of the existing nodes.
I specified the new root (SYS2) and answered all the relevant questions.

The third node boots all right, joins the cluster and then goes itno NETCONFIG and AUTOGEN.
This is where the problems start:
These two procedures are trying to execute images not from the shared systems disk and the new root (i.e. $1$DGA10:[sys2....) but from the VERY TOP of the shared system disk ($1$DGA10:[sysexe]) which ofcourse does not exist and the node just hangs.

It looks that AUTOGEN and NETCONFIG did not get the information about the new root (i.e. SYS2) !?

I tried running cluster_config MANY times but always with the same result.

Any help/idea ?

TIA !
10 REPLIES
Karl Rohwedder
Honored Contributor

Re: Cluster_config

Have you checked the bootflags on the new system, did it boot the correct systemroot?

regards Kalle
Dock
Occasional Contributor

Re: Cluster_config

Yes, the boot flags are all right:

boot_osflags 2,0

Additionally, on the existing two nodes in the cluster I get the confirmation message about the third node successfully joined the cluster.
Kris Clippeleyr
Honored Contributor

Re: Cluster_config

Dock,
Anything in the SY*.COM files about redefining some system logicals (like SYS$SYSTEM) ?
Regards,
Kris (aka Qkcl)
I'm gonna hit the highway like a battering ram on a silver-black phantom bike...
Karl Rohwedder
Honored Contributor

Re: Cluster_config

The procedure VMS$INITIAL-050_VMS.COM checks for the logical SYS$TOPSYS to create the correct rooted logicals names. If this logical is not defined, then the logicals e.g. SYS$SPECIFIC point towards the disk alone.

But why is this logical undefined?

Perhaps you can use SYSGEN to set OPA0 as startup file (SYSGEN> SET /STATUP=OPA0) and check (Remember to SET NOON and SPAWN, because any error logs you out).

regards kalle
Karl Rohwedder
Honored Contributor

Re: Cluster_config

The procedure VMS$INITIAL-050_VMS.COM checks for the logical SYS$TOPSYS to create the correct rooted logicals names. If this logical is not defined, then the logicals e.g. SYS$SPECIFIC point towards the disk alone.

But why is this logical undefined?

Perhaps you can use SYSGEN to set OPA0 as startup file (SYSGEN> SET /STARTUP=OPA0) and check (Remember to SET NOON and SPAWN, because any error logs you out).

regards kalle
Ian Miller.
Honored Contributor

Re: Cluster_config

Try a conversational boot, set STARTUP_P1 to "DV". This will create
[SYS2.SYSEXE]STARTUP.LOG
which you could look at on on of the other nodes.
____________________
Purely Personal Opinion
John Gillings
Honored Contributor

Re: Cluster_config

> Try a conversational boot, set STARTUP_P1 to "DV".

Not often one catches Ian out! That should be STARTUP_P2:

SYSBOOT> SET STARTUP_P2 "DV"
A crucible of informative mistakes
Ian Miller.
Honored Contributor

Re: Cluster_config

Doh, that would be STARTUP_P2.
(slaps self on head :-)
____________________
Purely Personal Opinion
Dock
Occasional Contributor

Re: Cluster_config

I did try setting STARTUP_P2 to "DV" but it did not create any startup.log file in [sys2.sysexe] or anywhere in [sys2...]

Dock
Volker Halle
Honored Contributor

Re: Cluster_config

Dock,

during inital boot from the new root, SYS$SYSTEM:STARTUP1.COM is running, not your standard SYS$SYSTEM:STARTUP.COM
(view with SYSBOOT> SHOW/STARTUP). This procedure may not honor the STARTUP_P2 settings. This 'temporary' procedure is created by CLUSTER_CONFIG.COM - please have a look into that file and maybe add a SHOW LOG SYS$* and a SET VERIFY at the beginning.

Volker.