[Info-vax] running VMS on PWS (SRM console)

[Phillip Helbig undress to reply]

In article <qn26o8$49n$1 at gioia.aioe.org>,
helbig at asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes: 

> I have some notes on this, and there is some information here and in the 
> group, but is there a definitive guide?
> 
> I understand that a good battery is essential to retain the settings
> during a power cycle with longer downtime, and that at least a weak
> battery is needed to retain the settings after a brief power cycle after
> changing the settings.  However, even if the battery is completely dead,
> should it always be possible to make the change (even if one can't save
> it)?  In other words, I'd like to verify that the machine is physically
> capable of booting from the SRM console before checking the battery
> (which implies disassembly). 
> 
> With no graphic monitor, the console output is on COM1, which is the 
> lower of the two ports, right?  Is it always visible if there is no 
> graphics monitor attached, despite any console settings?

> I'm pretty sure that I had the SRM console on all three of these at one 
> time.  Maybe I've forgotten how I got there, maybe something happened 
> while they were shut down.

I have 8 of these machines altogether, two in my cluster and 6 as
spares.  I did get to to the SRM prompt on the three I mentioned
previously today, but can't do so now.  Three other spares were acquired
more recently and I hadn't checked them out yet.  Checking out one of
the newer ones, I found that, indeed, I can get to the menu to change
the SRM console, but only via a graphics monitor.  F2 works there.  If I
issue a SET CONSOLE SERIAL, then this (and other settings) survive a
power cycle, so I guess that the battery is OK.  (The graphics monitor
didn't work on two of the three in the first group which have a graphics
card.) 

Reason: Today, my electricity meter was supposed to be swapped out and, 
having no UPS, I powered down the cluster.  As it turned out, the guy 
who was to install it was sick and the company didn't call to cancel the 
appointment, so it was all unnecessary.  After powering up, one PWS 
seems to have died (nothing at the console prompt).  It could be that 
the battery is bad and it reverted to the SRM console and graphics 
output.  I'll swap in the spare and, if the removed machine otherwise 
looks OK, replace the battery and it will become the new spare.

Another glitch: another node came up with the wrong name.  Either the 
BOOT_OSFLAGS didn't survive the power cycle, or I had never set them.  I 
know that the battery is bad on this machine since it always asks for 
the time.  (It is an XP1000, so doesn't have the console issue.)  As,
like today, it is always possible that a machine doesn't survive a power 
cycle, I haven't replaced the battery, but will do so when I swap it out 
after it fails (perhaps I can get it going again and set it up as a 
spare).  Perhaps one can replace the battery while it is running, but 
that is physically impossible or at least very difficult on the shelf 
where it is located.

Someone (Hoff?) once said that the longer the time between reboots, the 
less often one checks one's startup procedures.  Fortunately, mine all 
worked, then again, I haven't changed much if anything since the 
previous reboot.  Back when patches were availalbe to hobbyists, I used 
to reboot regularly (but not power down).  I suppose there is no harm in 
a rolling reboot, especially if things are configured so that no shadow 
copies will be initiated, and even the occasional cluster reboot, at 
least after changing something in the startup.  Powering down the whole 
cluster is of course the worst, fortunately it was controlled rather 
than just due to the power going off (which I've experienced only a 
couple of times in the last forty years).