topic Re: time went back an hour after reboot in Operating System - OpenVMS

time went back an hour after reboot

TMcB — Wed, 05 Apr 2006 03:41:48 GMT

One of our servers was rebooted last night.
After it came back up again, the time was an hour behind.

The time logicals we user are :
"SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM]GB-EIRE."
"SYS$TIMEZONE_DAYLIGHT_SAVING" = "1"
"SYS$TIMEZONE_DIFFERENTIAL" = "3600"
"SYS$TIMEZONE_NAME" = "BST"
"SYS$TIMEZONE_RULE" = "GMT0BST-1,M3.4.0/01,M10.5.0/02"

I had to correct the time using "set time".

Would anyone have any ideas what went wrong?

We have never configured DTSS, but I am suspicious that it may have something to do with it.

Thanks for your help.

Re: time went back an hour after reboot

Ian Miller. — Wed, 05 Apr 2006 03:55:05 GMT

which oonly goes to show rebooting is A Bad Thing :-)

What version of VMS, DECniet, TCPIP ?

What is the result of
@sys$manager:utc$time_setup show

Re: time went back an hour after reboot

TMcB — Wed, 05 Apr 2006 03:57:19 GMT

Hi

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 2
on a AlphaServer DS20 500 MHz running OpenVMS V7.3-2

DTSS is in use and will make changes to/from Daylight Saving Time.
(in time zones that use Daylight Saving Time)

LOCAL TIME ZONE = GB-EIRE -- DAYLIGHT TIME
LOCAL SYSTEM TIME = 5-APR-2006 09:56:29.60 (BST)
TIME DIFFERENTIAL FACTOR = 1:00
TIME ZONE RULE = GMT0BST-1,M3.4.0/01,M10.5.0/02
Change GMT to BST on the Fourth Sunday of March (26-Mar-2006) at 01:00
Change BST to GMT on the Last Sunday of October (29-Oct-2006) at 02:00

Also, I found the following entry in operator.log :
%JBC-W-SYSERROR, SYS$MANAGER:JBC$DST_COMMAND.COM daylight savings time process failed system service error at PC 00011EA0
-JBC-W-NOTIMZONRUL, SYS$TIMEZONE_RULE logical not defined, Daylight Savings Time clock adjustments are not possible

Re: time went back an hour after reboot

Chinraj Rajasekaran — Wed, 05 Apr 2006 07:02:07 GMT

Hi,

You say the system time went back after reboot... so

Can you check timezone parameter stored in the sysman startup database.

$ mc sysman startup show file UTC$CONFIGURE_TDF.COM /par

parameters to this file
P1: SET and P2:60 shoule be set properly.

regards
Raj

Re: time went back an hour after reboot

Robert_Boyd — Wed, 05 Apr 2006 07:09:22 GMT

After time changes it usuallly is important to make sure that the related bits on the system disk get updated. You didn't mention if this is an Alpha or a VAX.

This has happened to me many times in the past.

If you read the documentation for SET TIME there is a bit that is critical that often gets overlooked:

(From the OpenVMS FAQ)

4.1.1.2.3 EXE$GQ_SAVED_HWCLOCK
This cell is used by OpenVMS Alpha to keep track of the last time and date that EXE$GQ_SYSTIME was adjusted. It keeps the same time format as EXE$GQ_SYSTIME. The value in this cell gets updated in memory and on disk, every time EXE$GQ_SYSTIME gets adjusted.

* The system parameters SETTIME and TIMEPROMPTWAIT determine how the system time will be set.
* If SETTIME = 0
then EXE$INIT_HWCLOCK reads the hardware clock to set the system time.
o IF TIMEPROMPTWAIT > 0
THEN the value of TIMEPROMPTWAIT determines how long the user is prompted to enter the time and date. If time expires and no time has been entered the system acts as if TIMEPROMPTWAIT = 0.
o IF TIMEPROMPTWAIT = 0
THEN the system time is calculated from the contents of EXE$GQ_SAVED_HWCLOCK + 1.
o IF TIMEPROMPTWAIT < 0
THEN the user is prompted for the time and date and unable to continue until the information is entered.

Unlike the VAX, the Alpha hardware clock tracks the full date and time, not just the time of year. This means it is possible to boot from the CD-ROM media without entering the time at the CD-ROM bootstrap. (This provided that the time and date have been initialized, of course.)

IA-64 (Itanium) hardware time-keeping details to be added...
4.1.1.3 Why does VAX need a SET TIME at least once a year?

Because the VAX Time Of Year (TOY) has a resolution of 497 days, the VAX system time is stored using both the TOY and the OpenVMS VAX system image SYS.EXE. Because of the use of the combination of the TOY and SYS.EXE, you need to issue a SET TIME command (with the time parameter specified) at least once between January 1st and about April 11th of each year, and whenever you change system images (due to booting another OpenVMS VAX system, booting the standalone BACKUP image, an ECO that replaces SYS.EXE, etc).

The SET TIME command (with the current time as a parameter) is automatically issued during various standard OpenVMS procedures such as SHUTDOWN, and it can also obviously be issued directly by a suitably privileged user. Issuing the SET TIME command (with a parameter) resets the value stored in the TOY, and (if necessary) also updates the portion of the time (the current year) saved in the SYS.EXE system image.

This VAX TOY limit is the reason why OpenVMS VAX installation kits and standalone BACKUP explicitly prompt for the time during bootstrap, and why the time value can "get weird" if the system crashes outside the 497 day window (if no SET TIME was issued to update the saved values), and why the time value can "get weird" if a different SYS$SYSTEM:SYS.EXE is used (alternate system disk, standalone BACKUP, etc).
4.1.2 How does OpenVMS VAX maintain system time?

VAX systems maintain an interval clock, and a hardware clock.

The VAX hardware clock is called the TOY ("Time Of Year") clock. The register associated with the clock is called the TODR ("Time Of Day Register").

The TOY clock---as used---stores time relative to January first of the current year, starting at at 00:00:00.00. It is a 100 Hz, 32-bit counter, incremented every 10ms, and thus has a capacity of circa 497 days.

OpenVMS (on the VAX platform) stores system date information---and in particular, the current year---in the system image, SYS$SYSTEM:SYS.EXE.

The TOY is used, in conjunction with the base date that is stored and retrieved from the system image, to initialize the interval clock value that is stored in EXE$GQ_SYSTIME.

Once the interval clock is loaded into the running system as part of the system bootstrap, the system does not typically reference the TOY again, unless a SET TIME (with no parameters) is issued. The interval clock value is updated by a periodic IPL22 or IPL24 (depending on the specific implementation) interrupt. (When these interrupts are blocked as a result of the activity of higher-IPL code---such as extensive driver interrupt activity or a hardware error or a correctable (soft) memory error---the clock will "loose" time, and the time value reported to the user with appear to have slowed down.)

When SET TIME is issued with no parameters, the TOY clock is loaded into the system clock; the running system clock is set to the time stored in the TOY clock. This assumes the TOY clock is more accurate than the system clock, as is normally the case.

On most (all?) VAX systems, the battery that is associated with the TOY clock can be disconnected and replaced if (when) it fails

Re: time went back an hour after reboot

TMcB — Wed, 05 Apr 2006 07:49:53 GMT

system details are :
HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 2
on a AlphaServer DS20 500 MHz running OpenVMS V7.3-2

mc sysman startup show file UTC$CONFIGURE_TDF.COM /par
%SYSMAN-I-NODERR, error returned from node ALFAT0
-STARTUP-E-FILNOTFND, STARTUP file UTC$CONFIGURE_TDF.COM not found

What sets the time during startup?

What sets the logicals during startup (they do not appear in sylogicals.com)

Re: time went back an hour after reboot

Volker Halle — Wed, 05 Apr 2006 07:51:26 GMT

Raj,

$ mc sysman startup show file UTC$CONFIGURE_TDF.COM /par

This procedure is obsolete and should not be used anymore ! Timezone changes should only be done by using SYS$MANAGER:UTC$TIME_SETUP.COM, which will put the correct information into SYS$MANAGER:{DTSS|TDF}$UTC_STARTUP.COM

Volker.

Re: time went back an hour after reboot

Volker Halle — Wed, 05 Apr 2006 08:08:43 GMT

TMcB,

VMS$BASEENVIRON-050_VMS.COM calls TDF$UTC_STARTUP.COM, if DTSS is not in use. Otherwise DTSS$UTC_STARTUP.COM is called (from NET$STARTUP.COM).

Either one of these 2 procedures is called during startup to set the timezone logicals. The timezone information in these procedures is maintained by @UTC$TIME_SETUP - the ONLY procedure to be used to modify timezone related information.

I assume that this is a standalone node, otherwise it would've got the correct time from another member in the cluster.

During startup, the time must be obtained from the HWCLOCK. If that clock did NOT get updated after the change to BST, this may explain, why the system came up one hour behind the correct time.

I've started using

$ SET AUDIT/ALARM/ENABLE=TIME
$ SET AUDIT/AUDIT/ENABLE=TIME

on our systems to be able to tell, when and by whom the system clock has been changed.

You can look at the last time written to the HWLOCK with ANA/SYS
SDA> EXA/TIME EXE$GQ_SAVED_HWCLOCK

But it may now be too late to find out, why the system came up with a bad time.

Volker.

Re: time went back an hour after reboot

Volker Halle — Wed, 05 Apr 2006 10:36:38 GMT

TMcB,

I've checked a couple of V7.3-2 systems running DTSS and their EXE$GQ_SAVED_HWCLOCK value was 26-MAR-2006 03:00 (the time we switched to during the MET to MEST DST time change on the last sunday in March).

If - for whatever reason - DTSS failed to correctly update the HWCLOCK on your system, this may explain the behaviour you've seen. The $SET TIME="''f$time()'" in SHUTDOWN.COM would not work if DTSS is still enabled during shutdown.

Did you correctly and cleanly shut down the system ?

Volker.

Re: time went back an hour after reboot

TMcB — Wed, 05 Apr 2006 10:38:53 GMT

Hi Vokker

We dont use DTSS

The server was rebooted cleanly

Re: time went back an hour after reboot

Volker Halle — Wed, 05 Apr 2006 10:42:58 GMT

Hi,

your output from @UTC$TIME_SETUP SHOW seems to indicate otherwise:

DTSS is in use and will make changes to/from Daylight Saving Time.
(in time zones that use Daylight Saving Time)

$ SHOW LOG *DTSS*
$ MC NCL SHOW DTSS
$ DIR SYS$SYSTEM:DTSS$SERVICE.EXE

Volker.

Re: time went back an hour after reboot

Robert_Boyd — Wed, 05 Apr 2006 11:00:07 GMT

If you're not using DTSS you really should define the logical to tell the system startup procedures that by putting this in SYLOGICALS.COM:

$ define/system/exec NET$DISABLE_DTSS 1

If you don't do this, it is possible to get some odd behavior due to assumptions made by the startup procedures.

Robert

Re: time went back an hour after reboot

Volker Halle — Wed, 05 Apr 2006 11:09:11 GMT

@UTC$TIME_SETUP.COM SHOW explicitly looks for a DTSS$SERVER or DTSS$CLERK process to determine, whether DTSS is in use.

Check with $ SHOW SYS/PROC=DTSS*

Volker.

Re: time went back an hour after reboot

TMcB — Mon, 10 Apr 2006 05:41:42 GMT

UPDATE - TIME STILL ONE HOUR OUT AFTER REBOOT

I was able to reboot the server a few times over the weekend - and it looks
loke the problem is no closer to being resolved.

NTP and DTSS are disabled ("NET$DISABLE_DTSS" = "1")

I configured the sysgen param
> mc sysgen show auto*
Parameter Name Current Default Min. Max. Unit
Dynamic
-------------- ------- ------- ------- ------- ----
-------
AUTO_DLIGHT_SAV 1 0 0 1
Boolean

I installed the following patches

DEC AXPVMS VMS732_JOBCTL V2.0 Patch Install 09-APR-2006
13:01:44
DEC AXPVMS VMS732_TDF V3.0 Patch Install 09-APR-2006
13:01:44

The server was rebooted, and during the boot process the console
displayed
:
openvms startup has begun at 11:05
When the time was really 12:05

Before each reboot, the time was definately correct.

When it came up an hour out I used "utc$time_setup" to correct it.

Any more ideas on where the time could be going back an hour?

Thanks

Terry

After reboot :

> @sys$manager:utc$time_setup show

AUTO_DLIGHT_SAV is set to "1".
OpenVMS will automatically change to/from Daylight Saving Time.
(in time zones that use Daylight Saving Time)
LOCAL TIME ZONE = GB-EIRE -- DAYLIGHT TIME
LOCAL SYSTEM TIME = 9-APR-2006 11:49:35.58 (BST)
TIME DIFFERENTIAL FACTOR = 1:00
TIME ZONE RULE = GMT0BST-1,M3.4.0/01,M10.5.0/02
Change GMT to BST on the Fourth Sunday of March (26-Mar-2006) at
01:00
Change BST to GMT on the Last Sunday of October (29-Oct-2006) at
02:00

Logicals after reboot :
"SYS$DST_DELTA_TIME" = "ffff60cd265d37bd"
"SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM]GB-EIRE."
"SYS$TIMEZONE_DAYLIGHT_SAVING" = "1"
"SYS$TIMEZONE_DIFFERENTIAL" = "3600"
"SYS$TIMEZONE_NAME" = "BST"
"SYS$TIMEZONE_RULE" = "GMT0BST-1,M3.4.0/01,M10.5.0/02"

Re: time went back an hour after reboot

Volker Halle — Mon, 10 Apr 2006 06:54:41 GMT

Terry,

I've done a quick test on my OpenVMS Alpha V7.3-1 home system: set timezone to GB-EIRE and a reboot and the time after boot looks o.k.

I noted that EXE$GQ_SAVED_HWCLOCK seems to reflect the time in the HWCLOCK at boot time. This value normally contains the last time written to the HWCLOCK.

During shutdown, the time will be written to the HWCLOCK with SET TIME="''f$time()'".

You can examine this value with:

$ ANAL/SYS
SDA> EXA/TIME exe$gq_saved_hwclock

If you have another chance to reboot your server, consider to add this command into SHUTDOWN.COM before the $run sys$system:opccrash command and capture the console output.

Also check this value during or immediately after startup.

During boot, OpenVMS can only access the value of the HWCLOCK.

Also consider to enable TIME auditing:

$ SET AUDIT/ALARM/ENABLE=TIME
$ SET AUDIT/AUDIT/ENABLE=TIME

$ SET TIME (without any parameter) will read the HWCLOCK value and set the system time accordingly.

Volker.