VMS boot problem

[Trace Trembath]

I have a system that has been running for almost 18 months now. However, it was rebooted recently and is giving the following prompt for date and time after the VMS banner;

PLEASE ENTER DATE AND TIME (DD-MMM-YYYY HH:MM)

I think the internal real-time clock battery needs to be replaced.

Is there anything else that could cause this behavior?

[Lokesh_2]

Hi,

I have alpha system which I use both for unix & VMS. I face the similar problem, whenever I boot VMS after Unix ( i mean , if UNIX is running and then I shut it down and boot it with VMS system disk, it will ask me date and time ) .

As it seems you are simply rebooting your VMS box, then the problem is most likely to be bad battery.

Best regards,
Lokesh

[Lokesh_2]

check also for the sysgen parameter SETTIME ?

************************************
SETTIME

SETTIME enables (1) or disables (0) solicitation of the time of
day each time the system is booted. This parameter should usually
be off (0), so that the system sets the time of day at boot time
to the value of the processor time-of-day register. You can reset
the time after the system is up with the DCL command SET TIME
(see the OpenVMS DCL Dictionary).



SYSGEN>
SYSGEN> SHO SETTIME
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
SETTIME 0 0 0 1 Boolean
SYSGEN>


Best regards,
Lokesh

[Lokesh_2]

and i just confirmed same with my alpha machine. If sysgen parameter SETTIME is set to 1 , then during reboot system will ask for date and time.

Best regards,
Lokesh

[Antoniov.]

Hi Trace,
what os version are you using? And what hardware?
Som year ago, my customes have buyed AXP 400 with OpenVMS V6.2. All computer (ALL) have this problem during booting. Dec (not yet Compaq) send us two patch to correct this problem.

Bye
Antoniov

[Trace Trembath]

The OS is OpenVMS 7.2-1 and it is a DS20. It has been running smoothly since May 2002.

I've been told that the battery has been replaced, but with no apparent result.

I've checked the settime parameter and it is correctly set to 0.

So I'm still baffled.

Many thanks for any and all help!

[John Gillings · Accepted solution]

Trace,

Apart from being forced by the SETTIME SYSGEN parameter, OpenVMS will prompt for the date and time whenever the last known time fails a sanity check against the hardware clock. This will occur if the clock battery fails, but it will also fail if you don't issue SET TIME commands at "reasonable" intervals.

VMS timekeeping is somewhat complex (some would say bizzare), so I won't try to explain it all. For this issue you need to know that the SET TIME command stores the current date and time in SYS$LOADABLE_IMAGES:SYS$BASE_IMAGE.EXE. If the stored value is more than 497 days from the hardware clock, VMS will ask for the date and time.

So, try issuing a SET TIME command (no need to enter an actual time, just SET TIME). This should update both the hardware clock, and the stored date/time to the current time. If you still get the prompt on the next boot, check the hardare.

Make sure you issue at least one SET TIME command per year, and preferably before 13th May.

It is possible to find the time in SYS$BASE_IMAGE.EXE, but it moves around from version to version. If you're interested, take a copy of SYS$BASE_IMAGE before issuing the SET TIME command, then use DIFF/MODE=HEX to find the block that changed. There are two copies of the time stored from BYTE 0 of the changed block. You can format the time from DCL like this (warning, undocumented hack!):

(output from DIFF - V7.2-2)
RECORD NUMBER 242 (000000F2) LENGTH 512 (00000200)

00A28C89 AEE86400 00A28C89 AEE86400 .dè..¢..dè..¢. 000000
^---------------^ ^----------------^
copy 2 copy 1

$ tim[32,32]=%x00A28C89 ! high longword
$ tim[0,32]=%xAEE86400 ! low longword
$ date=F$FAO("!%D",F$CVUI(32,32,F$FAO("!AD",8,tim)))
$ show sym date
DATE = "12-NOV-2003 09:42:00.00"

BTW - Tru64 Unix and OpenVMS use the hardware clock differently, so alternate booting will always end up with the hardware clock being out of synch with the softwar

[Victor Mendham]

You might need to keep an eye on your batteries. We have an old VAX and it's about $700 to get a battery. More importantly, if you lose the cache battery in HSC, HSJ, or other controllers, then you may lose disks (not the data) and redundancy may be affected.

It might be wise to have your systems checked at least twice a year for such things as latest Firmware, Batteries etc.
Ask the your maintenance vendor (is it HP) to confirm version of firmware on all cards/boards, then compare to latest version (u may not want to run it) and when they bring the system down to check firmware, get them to replace batteries, not too sure how they would check them, but if one is gone, perhaps time to replace all.

[Trace Trembath]

John,

What is the significance of the May 13th date? Does it apply to every May 13th or just May 13, 2004?

[Lokesh_2]

Hi,

It needs be done every year. See the below link ( check artical 6.9.1.1 )

http://h71000.www7.hp.com/doc/731FINAL/6017/6017pro_019.html#resetting_system_time

Best regards,
Lokesh

[Derek Haining]

By the way, it used to be the case that
the SYS$SYSTEM:SHUTDOWN.COM command procedure would execute a $ SET TIME command
before running OPCCRASH.EXE. This, as is
mentioned earlier, causes the time to be
updated in the loadable image file.

Your ntoe said that you rebooted the system
after 18 months. Was this via a hard crash
reboot, or a shutdown and reboot process. If not done by the shutdown procedure, this
problem could easliy be being caused by
the fact that the loadable image may never
have been adjusted. Just a thought.

[John Gillings]

13th May... Oops, sorry, wrong date. It should be 11th April. This is the rollover point of the Time Of Year (TOY) clock, measured from 1st January in the previous year.

It's a 32 bit counter, incremented every 10msec, so the limit is 497 days. However, there is a bias of 31 days to detect loss of power, so the rollover point is 466 days. 1st Jan + 466 days => 11th April in the following year.