VMS 5.5 Boot (cluster)

[PAUL ROGERS`]

A recent failure of a disk drive forced me to min boot. After resetting the STARTUP_P1 to "" I get "..-GPTFULL, global page table is full" message. I also noticed that when I do a shutdown I no longer have the "CLUSTER_SHUTDOWN" option (this is configured as a vaxcluster). Did I reset something incorrectly when I did the reset of the startup parameter? I noticed in the SYS$SYSTEM:STARTUP.COM file the p1 through p5. Should I have set it to something other than ""?

[Volker Halle]

Paul,

welcome to the OpenVMS ITRC forum.

It looks like you have lost - at least some of - your system parameters.

The GPTFULL message implies, that the sysgen parameter GBLPAGES now is too small.

Missing the CLUSTER_SHUTDOWN option indicates, that this node is NOT running as a cluster node anymore, i.e. the VAXCLUSTER parameter is probably 0. If this node shares an IO path with other nodes and is suposed to run in a cluster, this is extremely dangerous, as it will cause un-coordinated disk access and destroy your disk structure quite fast. If this is the case, HALT the node immediately and make sure you have your latest disk backups handy !

Did you - by any chance - use the command SYSBOOT> SHOW DEFAULT ? This would load a default set of parameters, which could explain the symptoms you're seeing.

The system parameters saved BEFORE your last AUTOGEN are still available in SYS$SYSTEM:VAXVMSSYS.OLD - the parameters set by the last AUTOGEN are saved as SYS$SYSTEM:AUTOGEN.PAR

You might want to check these old parameters with:

$ MC SYSGEN
SYSGEN> USE AUTOGEN.PAR

SYSGEN> USE VAXVMSSYS.OLD

If you like one of those sets of parameters, then use SYSGEN> WRITE CURRENT to write them into your default parameters SYS$SYSTEM:VAXVMSSYS.PAR for the next boot.

Volker.

[Robert Gezelter]

Paul,

To understand what is happening, we need to better understand your environment.

Your message implies that you restored a disk. Are you sure that you booted from the correct system root (the same one that you booted from BEFORE the disk failure)?

Also, if doig a MIN startup, then it is unsurprising the you are not able run your full environment.

If you can give us more details, we can be more on target.

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Paul,

I am with Volker about the cause:
you have (somehow) activated a non-cluster set of SYSGEN params. ((activated FEDAULT, or booyed from some non-clustered system root. Maybe your changed disk was NOT a restored BACKUP of the original?)
I also second his caution if you ARE accessing shared disks (but that will be too late anyway :-( )
If you still it, restore your original system disk, or else, re-issue @CLUSTER_CONFIG

hth

Proost.

Have one on me.

jpe

[Jan van den Ende]

Brrr, how is that for checking your entry before submitting?
"FEDAULT" should have been "DEFAULT", and "booyed" is "booted", of course! :-(

Proost.

Have one on me.

jpe

[comarow]

We can theorize, and I would check all your
roots on that disk.

Are there other systems sharing that disk?
Or were there?

To make sure you are on the right root, check sysgen and see if SCSNODE is correct.
Also, check the modparams.dat file.

IF your modparams.dat is correct, it would be easiest to run autogen to correct it. IF there is a feedback file on system that comes close to reflected your load, it would be better than not using feedback.

If you have a reasonable feedback file,
AND the modparams.dat is correct, you are home free. If the modparams.dat is another node, and you find the right root, boot from that.