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

VAX restart control settings

 
SOLVED
Go to solution
Jude_7
Occasional Visitor

VAX restart control settings

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.
12 REPLIES 12
Karl Rohwedder
Honored Contributor

Re: VAX restart control settings

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
Occasional Visitor

Re: VAX restart control settings

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
Honored Contributor

Re: VAX restart control settings

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
Honored Contributor
Solution

Re: VAX restart control settings

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.
A crucible of informative mistakes
John Travell
Valued Contributor

Re: VAX restart control settings

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
Honored Contributor

Re: VAX restart control settings

John,

isn't AUTO_ACTION Alpha only?

regards Kalle
Doug_81
Frequent Advisor

Re: VAX restart control settings

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
Occasional Visitor

Re: VAX restart control settings

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
Honored Contributor

Re: VAX restart control settings

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
Jude_7
Occasional Visitor

Re: VAX restart control settings

Thanks. I have checked and the date and time are still ok upon boot-up. I originally thought that the problem was with the battery but it does look as though that isn't the case in this instance.

One of the clusters does seem to have a console password set and so the ill command or illegal instruction error appears but the cluster I was most concerned with is now auto booting which is great.
Hoff
Honored Contributor

Re: VAX restart control settings

All of what you're reporting here can be what is seen when the TOY battery is marginal, and failing. Or failed.

The usual preferred console HALT setting is RESTART-REBOOT, if and when that's available in a VAX console. This causes the execution of a HALT instruction in OpenVMS VAX to trigger a restart, and which then (due to the HALT setting) a crash and REBOOT, which means you get a crashdump on a kernel-mode HALT. And the RESTART-REBOOT otherwise acts as a BOOT during a cold start.

http://h71000.www7.hp.com/wizard/wiz_5927.html

The manuals for VAX boxes with similar model names (there are a number of very different VAX boxes with very similar model numbers around) are available at:

http://vt100.net/manx

and elsewhere.

How far along is your plan to replace the disks with newer bricks (and there are new-retrofit disks around) and the wholesale replacement of this VAX gear? Either through emulation, or through migration to OpenVMS on Integrity, or to migration to HP-UX or another platform. (VAX/VMS V5.3 - as it was then known - is twenty years old this year, after all.)

Jude_7
Occasional Visitor

Re: VAX restart control settings

Hello Hoff

Unfortunately emulators won't do it for the organisation and I have to continue to support the existing hardware for the forseeable future. Moving to a more supportable platform is not an option either. I wish it were, my main responsibilities lie within UNIX system administration.

The older 5.3 operating system is used just to transfer files to/from other systems.

A colleague implemented a RAID solution a few years back after a bind set of disks failed on a couple of occasions.

We have hardware support, every so often I get a new disk sent out when one in the RAID set fails. Its not ideal but previously the answer was to restore from tape!. It was a lengthy process hours trawling through to find a saveset let alone retrieve any data.