| Previous | Contents | Index |
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:
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:
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 |