VAX restart control settings

[Jude_7]

I am tasked with support two VAX clusters, one running VMS version 5.3 and the other 6.2.
Owing to the age of the kit, Microvax 3100, 3000 and 4200 series I am having problems finding a solution to a problem;

A recent power outage caused all of the VAX nodes to wait at the console prompt. I had to boot the servers, I understand there is a way to change a variable to ensure that the servers attempt to boot in this eventuality rather than to wait for intervention.

Any advise on how to do this for the VAX hardware/VMS version specified gratefully received.

[Karl Rohwedder]

The variable is called HALT, if memory serves me right you must enter:

>>> SET HALT 2

to enable autoreboot, newer VAXen also allowed for keywords, e.g. "restart".

regards Kalle

[Jude_7]

Thanks for your reply. I attempted 'set halt 2' previously but for some reason its not accepted as a valid command. I haven't tried set halt restart but expect the same system response. The response is Illegal command or something equivalent to.

I'm trying this on a microvax 3300 running 5.3.

[Karl Rohwedder]

Jude,

the VMS version is not relevant here, its the console software. Try
>>> HELP

Maybe someone has set a console password? Then
every command is 'illegal' except BOOT and LOGIN.

regards Kalle

[John Gillings · Accepted solution]

Jude,

At that age I'd also be checking the batteries. If they're completely dead, it doesn't matter much what you set - after a power failure it will all be lost. The console may prompt for stuff regardless (for example, the console language).

If the prompt was from OpenVMS waiting for the date and time, then the SYSGEN paramter TIMEPROMPTWAIT might be what you're thinking of. It controls how long the system will wait for someone to feed it the date and time while booting (that's assuming it can't figure it out for itself -and if it can't that's a good indication that your battery is dead).

TIMEPROMPTWAIT is measured in a "uFortnight"s (micro fortnights - about 20 minutes - this unit is a very very old, VMS joke that made it into production). The default is 65535 which is about 2.5 years.

For nodes that are joining a cluster, the date and time don't really matter as the existing cluster nodes will override any setting. However, it is important that the foundation node get the date and time right, otherwise your cluster could find itself in a serious time warp.

[John Travell]

Hopefully you understood from a previous reply that you need to shutdown VMS and get to the console prompt, >>>.
Once you are there, the variable you need to set is AUTO_ACTION.
so, enter :
>>> set AUTO restart
or, if the console will not accept that,
>>> set AUTO 2

The console variable AUTO_ACTION controls what the console does in the event of an unplanned entry to console mode. Values:
HALT - do nothing, stay in console mode.
REBOOT - do just that.
RESTART - go look for a restart parameter block (RPB), if one is found attempt to restart VMS, if not then fail-over to just REBOOT.

The main value of RESTART comes when you have just suffered one of the few pathological halts present in VMS, e.g. "Kernel stack not valid". If AUTO is set to REBOOT you destroy the evidence and get going.
If it is set to RESTART, and an RPB is present, you first get an appropriate restart bugcheck, then the system will REBOOT (provided VMS sysgen parameter BUGREBOOT is set to 1).
Finally, you have some evidence for people like Volker and me to look at and hopefully find out why it went down in the first place.

Following a power fail there will clearly there will be no RPB in memory, so the RPB check will fail very quickly indeed and the system will just REBOOT.

In case anyone is unclear about this, a ^P is a planned entry to console mode, so AUTO_ACTION is not invoked.

Hopefully all of this will both fix your power-on problem and help you understand WHY you are doing what you do.

John Travell.
If you want to contact me, just look at my profile.

[Karl Rohwedder]

John,

isn't AUTO_ACTION Alpha only?

regards Kalle

[Doug_81]

Hi Jude:
Different hardware has slightly different console commands.

For the 3100 you want to enter
>>>SET HALT 2

For the 3000 & the 4200 you want to enter
>>>set auto_action boot

Doug

[Jude_7]

Hello

Apologies for the severly overdue reply to this post. I forgot to reply at the time of posting the request. I came back to the forum to check for something else today and realised my error.

Thanks to Karl, John, John and Doug.

The set halt 2 command at the halt prompt worked in conjunction with the mcr sysgen parameter timepromptwait changed to 0 and now I have systems that should auto boot on the next powercut.

[Robert Gezelter]

Jude,

Please take heed of the comments about batteries.

Even if the system accepted the commands, if the batteries are flat, if will be of no use when the power goes out.

A good reason for a scheduling a 5-10 minute shutdown. Shut each of the systems down (all the way to power off), then apply the power and restart.

If the batteries are ok, then everything will be fine. If all of the settings have disappeared, then the NVRAM battery(ies) need replacement.

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