The OpenVMS Frequently Asked Questions(FAQ)


Previous Contents Index

4.2.1.2 Alpha hardware time-keeping details...

4.2.1.2.1 Battery-Backed Watch (BB_WATCH) Chip

This is battery backed up hardware timing circuitry used to keep the correct time of year during rebooting, power failures, and system shutdown. This clock keeps track of date and time in 24 hour binary format.

4.2.1.2.2 EXE$GQ_SYSTIME

This is the OpenVMS Alpha system time cell. This cell contains the number of 100ns intervals since November 17, 1858 00:00:00.00. This cell is incremented by 100000 every 10ms by an hardware interval timer.

4.2.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. 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.2.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 no parameters) 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 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 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.2.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, 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.)

On most (all?) VAX systems, the battery that is associated with the TOY clock can be disconnected and replaced if (when) it fails---TOY clock failures are quite commonly caused by a failed nickel-cadmium (NiCd) or lithium battery, or by a failed Dallas chip.

4.3 Keeping the OpenVMS system time synchronized?

To help keep more accurate system time or to keep your system clocks synchronized, TCP/IP Services NTP, DECnet-Plus DECdtss, DCE DTSS, and other techniques are commonly used. If you do not have IP access to a time-base, then you could use dial-up access to NIST or other authoritative site.

There exists code around that processes the digital (ie: binary) format time that is available via a modem call into the NIST clock (the Automated Computer Telephone Service (ACTS)), and code that grabs the time off a GPS receiver digital link, or a receiver (effectively a radio and a codec) that processes the time signals from radio station WWV, WWVH, WWVB, or similar. (Processing these time protocols often involves little more than reading from an EIA232 (RS232) serial line from the receiver, something that is possible from most any language as well as directly from DCL.)

One example of acquring a time-base involves the IRIG time format (IRIG-A, -B, -G), a binary signal containing the current time in hours, minutes, seconds and days since the start of the current year. IRIG can also contain the time of day as the number of seconds since midnight. HP Custom Systems and third-party vendors offer various IRIG-based reader/generator modules for OpenVMS systems.

Differing time servers (DECnet-Plus DTSS, DCE DTSS, NTP, etc) do not coexist particularly well, particularly if you try to use all these together on the same node. Please pick and use just one. (If needed, you can sometimes configure one package to acquire its timebase from another protocol, but one and only one time server package should have direct control over the management of and drifting of the local OpenVMS system time. In the specific case of DECnet-Plus DTSS, older product versions and versions V7.3 and later provide a provider module, a module which permits DTSS to acquire its time from NTP. For details on this, please see the comments in the module DTSS$NTP_PROVIDER.C.)

Useful URLs:

4.3.1 Why does my OpenVMS system time drift?

Memory errors, hardware problems, or most anything operating at or above IPL 22 or IPL 24 (clock IPL is system family dependent; code executing at or above the clock IPL will block the processing of clock interrupts), can cause the loss of system time. Clock drift can also be caused by normal (thermal) clock variations and even by the expected level of clock drift.

When clock interrupts are blocked as a result of the activity of high-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. Correctable memory errors can be a common cause of system time loss, in other words. Heavy PCI bus traffic can also cause lost time.

One bug in this area involved the behaviour of certain graphics controllers including the ELSA GLoria Synergy PBXGK-BB; the PowerStorm 3D10T effectively stalling the PCI bus. See Section 5.15 for details on the ELSA GLoria Synergy controller, and make certain you have the current GRAPHICS ECO kit installed.

Clock drift can also be (deliberately) caused by the activity of the DTSS or NTP packages.

Also see Section 14.8, Section 14.15, and Section 4.3.2.

4.3.2 How can I drift the OpenVMS system time?

With DECdts and TCP/IP Services NTP, the system time value is "drifted" (rather than changed), to avoid the obvious problems that would arise with "negative time changes". The same basic clock drifting technique is used by most (all?) time servers operating on OpenVMS, typically using the support for this provided directly within OpenVMS.

An example of the technique used (on OpenVMS VAX) to drift the system time is the SETCLOCK tool on the OpenVMS Freeware.

For information on the use of the EXE$GL_TIMEADJUST and EXE$GL_TICKLENGTH cells on OpenVMS Alpha, see OpenVMS AXP Internal and Data Structures, located on page 348.

For those areas which switch between daylight savings time (DST) and standard time, the time value is not drifted. The time is adjusted by the entire interval. This procedure is inherent in the definition of the switch between DST and standard time.

4.3.3 How can I configure TCP/IP Services NTP as a time provider?

An NTP time provider provides its idea of the current time to NTP clients via the NTP protocol. Most systems are NTP clients, but...

NTP has a heirarchy of layers, called strata. The further away from the actual NTP time source (Internet time servers are at stratum 1), the lower the strata (and the larger the number assigned the statum).

NTP explicity configured at stratum one provides time to NTP operating at lower strata, and the provided time is acquired based on the local system time or via some locally-accessible external time source.

NTP at other (lower) strata both receive time from higher strata and can provide time to lower strata, and automatically adjust the local stratum. The highest stratum is one, and the lowest available stratum is fifteen.

The TCP/IP Services NTP package can operate at any stratum, and can be configured as a peer, as a client, or as a broadcast server. NTP can also provide time to a DECnet-Plus DTSS network, see Section 4.3.

With TCP/IP Services V5.0 and later, the only supported reference clock is the LCL (local system clock). If your system has an excellent clock or if the system time is being controlled by some other time service or peripheral (such as DTSS services, GPS services, a cesium clock, a GPIB controller or other similar time-related peripheral), you can configure NTP to use the system clock as its reference source. This will mimic the master-clock functionality, and will configre NTP as a stratum 1 time server. To do this, enter the following commands in TCPIP$NTP.CONF:


server 127.127.1.0 prefer 
fudge 127.127.1.0 stratum 0 

For local-master functionality, the commands are very similiar. Use:


server 127.127.1.0 
fudge 127.127.1.0 stratum 8 

The difference between these two is the stratum, and the omission of the prefer keyword. Specifying a higher stratum allows the node to act as a backup NTP server, or potentially as the sole time server on an isolated network. The server will become active only when all other normal synchronization sources are unavailable. The use of "prefer" causes NTP to always use the specified clock as the time synchronization source.

With the TCP/IP Services versions prior to V5.0, the NTP management is rather more primitive. To configure the local OpenVMS system from an NTP client to an NTP server (on TCP/IP Services versions prior to V5.0), add the following line to the sys$specific:[ucx$ntp]ucx$ntp.conf file:


master-clock 1 

Also, for TCP/IP Services prior to V5.0, see the NTP template file:


SYS$SPECIFIC:[UCX$NTP]UCX$NTP.TEMPLATE 

Note that NTP does not provide for a Daylight Savings Time (DST) switch-over, that switch must arise from the timezone rules on the local system and/or from the SYS$EXAMPLES:DAYLIGHT_SAVINGS procedure. (Further, there is a known bug in SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM in V7.3, please obtain the available ECO kit.)

For current TCP/IP Services and related OpenVMS documentation, please see:

4.4 Managing Timezones, Timekeeping, UTC, and Daylight Savings?

You will want to use the command procedure:

to configure the OpenVMS Timezone Differential Factor (TDF) on OpenVMS V6.0 and later. Select the BOTH option. This configures the OpenVMS TDF settings, though it may or may not configure the TDF and the timezone rules needed or used by other software packages. Please do NOT directly invoke the following command procedures:

TCP/IP Services V5.0 and later use the OpenVMS TDF, UTC, and timezone support. Earlier versions use a TDF mechanism and timezone database that is internal to the TCP/IP Services package. Also on the earlier versions, the TDF must be manually configured within TCP/IP Services, in addition to the OpenVMS configuration of the TDF.

DECnet-Plus in V7.3 and later uses the OpenVMS TDF, UTC, and timezone support, and displays its timezone prompts using UTC$TIME_SETUP.COM. Earlier versions use a TDF TDF mechanism, timezone database, and automatic switch-over that is internal to the DECnet-Plus package. Also on earlier versions, the TDF must be configured within the DECnet-Plus DECdtss package, in addition to the OpenVMS configuration of the TDF.

Application code using HP C (formerly Compaq C, formerly DEC C) will use the OpenVMS UTC and TDF mechanisms when the C code is compiled on OpenVMS V7.0 and later (and when the macro _VMS_V6_SOURCE is NOT defined). HP C does NOT use the OpenVMS UTC and TDF mechanisms when the C code is compiled on OpenVMS releases prior to V7.0, or when the preprocessor declaration _VMS_V6_SOURCE is declared.

DCE DTSS TDF details TDB.

In OpenVMS Alpha V6.1, V6.2, and V6.2-1Hx, the TDF value is written to SYS$BASE_IMAGE.EXE. With OpenVMS Alpha V7.0 and later and with OpenVMS VAX V6.0 and later, SYS$SYSTEM:SYS$TIMEZONE.DAT contains the TDF. This means that OpenVMS Alpha systems will need to have the TDF value reset manually---usually within SYSTARTUP_VMS.COM---on reboots prior to V7.0.

During OpenVMS Bootstrap, the SYSINIT module reads SYS$TIMEZONE.DAT to acquire the TDF for use in the system global cell EXE$GQ_TDF. This is done to ensure that the system boots with a valid TDF (a value which may be zero). The UTC system services get the TDF from this cell. These services, as well as the HP C RTL, must have a valid TDF. (Prior to OpenVMS V7.3, if either DECnet-Plus or DECnet/VAX Extensions is configured and run, the image DTSS$SET_TIMEZONE.EXE is invoked and can override the TDF and timezone rule settings from SYSINIT or from UTC$TIME_SETUP.COM--- this image runs even if DTSS is disabled. If the settings do not match (due to inconsistencies in timezone specification in UTC$TIME_SETUP.COM and NET$CONFIGURE.COM), DTSS will reset the values to match its definitions.)

Prior to OpenVMS V7.3, daylight savings time switchover is handled automatically only when DCE DTSS or DECnet-Plus DTSS is in use. In V7.3, OpenVMS can be configured to automatically switch over to daylight savings time, and also generates an event that interested applications can use to detect the switch-over between standard time and daylight time.

The manual switchover between daylight savings time and standard time is correctly accomplished via the SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM command procedure procedure.

Note: NTP (alone) does NOT provide automatic switch-over.

Note: The DST switch-over does NOT drift the time value; the switch-over applies the entire difference as a unit.

If you switch the TDF or daylight savings time setting, you will also want to restart or reconfigure any time-sensitive applications (those not using the time differential factor (TDF) change event available in V7.3 and later). Examples of these applications include the need to restart the NFS client and (yes) NTP. (NTP will want to try to "drift" the time (see Section 4.3), and will find the daylight savings time switch-over to be far too large to "drift". Hence the NTP restart.) You can also use the (undocumented) TCP/IP Services (prior to V5.0) commands:


SET TIME/DIFF=[positive or negative TDF integer] 
GENERATE TIME 

to reset the value of the logical name UCX$TDF.

Prior to V7.3, the command:


$ SETTZ :== $SYS$SYSTEM:DTSS$SET_TIMEZONE 
$ SETTZ MODIFY 

can be used to modify the settings of the SYS$TIMEZONE_DAYLIGHT_SAVING, SYS$TIMEZONE_DIFFERENTIAL, and SYS$TIMEZONE_NAME system logical names based on the SYS$TIMEZONE_RULE.

The following are other TDF-related logical names used/available on OpenVMS systems, with typical Daylight Savings and Standard Settings for the US Eastern Time (ET) timezone.


$daylight_time: 
$ DEFINE/SYSTEM/EXECUTIVE MAIL$TIMEZONE EDT 
$ DEFINE/SYSTEM/EXECUTIVE NOTES$TIMEZONE "-0400 EDT" 
$ DEFINE/SYSTEM/EXECUTIVE LISP$DAYLIGHT_SAVING_TIME_P true  ! Not 'EDT' 
$ DEFINE/SYSTEM/EXECUTIVE LISP$TIME_ZONE 05   ! Constant 
$ 
$standard_time: 
$ DEFINE/SYSTEM/EXECUTIVE MAIL$TIMEZONE EST 
$ DEFINE/SYSTEM/EXECUTIVE NOTES$TIMEZONE "-0500 EST" 
$ DEFINE/SYSTEM/EXECUTIVE LISP$DAYLIGHT_SAVING_TIME_P false ! Not 'EST' 
$ DEFINE/SYSTEM/EXECUTIVE LISP$TIME_ZONE 05   ! Constant 
$ 
$ DEFINE/SYSTEM/EXECUTIVE UCX$NFS_TIME_DIFFERENTIAL - 
    'f$integer(f$element(0," ",f$logical("notes$timezone"))/-100)' 

For information on ZIC and related tools used to manage the OpenVMS Timezone database, please see the DEC C Run-time Library Utilities Reference Manual---though the title would imply otherwise, this particular manual is part of the OpenVMS documentation set, and not part of the HP C (formerly Compaq C, formerly DEC C) documentation set.

4.4.1 How to troubleshoot TDF problems on OpenVMS?

This is an OpenVMS Alpha system prior to V7.0 and the startup is not invoking the procedure:


SYS$MANAGER:UTC$TIME_SETUP.COM 

This is an OpenVMS system prior to V6.0, where there is no OpenVMS TDF nor UTC available.

The version of the application does not use the OpenVMS TDF. This includes TCP/IP Services prior to V5.0, applications using HP C built on or targeting OpenVMS prior to V7.0, and systems using the DECnet-Plus DTSS mechanisms prior to the release associated with OpenVMS V7.3. (DCE TDF TBD.)

If you should find either of the following two timezone-related database files located in SYS$SPECIFIC:[SYSEXE]:

These two files are in an erroneous location and must be recreated in the correct directory:


SYS$COMMON:[SYSEXE] 

If the DCL command:


$ DIRECTORY SYS$SYSTEM:SYS$TIMEZONE*.DAT 

shows these files in SYS$SPECIFIC:[SYSEXE], then delete them and use SYS$MANAGER:UTC$TIME_SETUP.COM to recreate them.

On OpenVMS versions prior to V7.3, if the file:


$ SYS$STARTUP:DTSS$UTC_STARTUP.COM 

is present on your system, then you may need to invoke:


$ @SYS$UPDATE:DTSS$INSTALL_TIMEZONE_RULE.COM 

to recreate the timezone files correctly. Invoke this command immediately after [re]executing SYS$MANAGER:UTC$TIME_SETUP.COM.)

If SYS$UPDATE:DTSS$INSTALL_TIMEZONE_RULE.COM is not present on your system, then you may need to execute the following commands:


$ DELETE SYS$STARTUP:DTSS$UTC_STARTUP.COM 
$ DEASSIGN/SYSTEM/EXEC SYS$TIMEZONE_RULE. 

If your system time is being reported as being off by one hour (or whatever the local DST change), please see sections Section 4.1, Section 4.4 and Section 10.22.1.

4.4.2 Customizing your TDF (Timezone) Setting?

Individual, local, and regional differences on the use (or the lack of use) of Daylight Savings Time (DST) are quite common.

If you need to add (or remove) daylight savings time for your area or otherwise alter the rules for your local area, you will probably end up creating a variation to an existing timezone rule.

The necessary zone line to add for WhereEverLand will probably look something like this:


# Zone  NAME            GMTOFF  RULES/SAVE      FORMAT  [UNTIL] 
Zone    WhereEver       2:00    -               WhereEver 

The OpenVMS source file for the timezone rules here:


SYS$COMMON:[SYS$ZONEINFO.SYSTEM.SOURCES] 

You'll then want to ZIC this to create your own timezone definiton.

ZIC is documented in the OpenVMS Documentation Set, in the HP C Run-Time Library Reference Manual. (Despite the name of the manual, it is part of the OpenVMS documentation set and not the C manuals.)

Once you have created the new rule, use SYS$MANAGER:UTC$TIME_SETUP.COM to select the new timezone---with V7.3 and later, this tool will notice the new timezone and will offer it, on earlier releases, you may/will have to hack the tool somewhat. (Don't even think of trying to define the TZ logical name (found on older configurations), or the SYS$TIMEZONE_NAME logical name, or any other time- or timezone-related logical names directly yourself.)

For various timezone rules, see the tar.gz files (these are gzipped tar archives) available at:


Previous Next Contents Index