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---TOY clock
failures are quite commonly caused by a failed nickel-cadmium (NiCd) or
lithium battery, or by a failed Dallas chip.
4.2 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 DTSS (sometimes known as DECdtss), DCE DTS, and other techniques are commonly used. If you do not or cannot have IP access to one of the available time-base servers on the Internet, then you could use dial-up access to NIST or other authoritative site, or you can use a direct connection to a local authorative clock.
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) service), 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 stations WWV, WWVH, WWVB, or similar.
Processing the serial or hardware 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. Information on correctly drifting the OpenVMS system clock to match the time-base time is available within the logic of at least one OpenVMS Freeware package. (See Section 4.3 for a few potential hardware options.)
One example of acquring a time-base through local integrated hardware 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 have variously offered IRIG-based reader/generator modules for OpenVMS systems.
One of the easiest approaches is a network-based GPS or other similar receiver. Basically, this is a network server box that provides an NTP server with the necessary hardware for external synchronization. In addition to the antenna and the receiver and processing components, these devices provide a network interface (NIC) and support for an NTP time server, and applications including the NTP support within TCP/IP Services and within various third-party IP stacks can then be used to synchronize with the the NTP information provided by time-base receivers. No other host software is required, and no host configuration steps and no host software beyond NTP are required. (See Section 4.3 for a few potential hardware options.)
Differing time servers (DECnet-Plus DTSS, DCE DTS, 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.)
Unlike DECnet-Plus, TCP/IP Services NTP is not capable of connecting to a time-base other than the network time base or the local system clock. Third-party and open source NTP implementations are available for OpenVMS, as well.
Here are a few possibilities for providers of a GPS-based receiver with an embedded NTP server, strictly culled from the first few pages of a Google search. Availability, pricing, OpenVMS compatibility and other factors are not known.
For a direct-connected (local, non-IP, non-NTP) link, there are serial options available. Google finds Spectracom Corporation has a NetClock that could be used here, based on a quick look---I do not know if there is OpenVMS host software, but that would be possible to write for the ASCII data stream that the device supports. (Such coding requires knowledge of serial I/O, character processing, and knowledge of the clock drift API mechanisms in OpenVMS---there exists Freeware tools that could be used to learn how to tie into the clock drifting mechanisms of OpenVMS.)
Information on, and experiences or recommendations for or against these
or other similar devices is welcome.
4.3.1 Why do my cluster batch jobs start early?
Your system time is skewed across your cluster members, and the cluster member performing the queue management tasks has a system time set later than the system time of the member running the batch job.
This behaviour is most noticable when using SUBMIT/AFTER=TOMORROW and similar constructs, and use of /AFTER="TOMMOROW+00:01:00" or such is often recommended as a way to avoid this. The combination time value specified should be larger than the maximum expected time skew. In the example shown, the maximum cluster clock skew is assumed less than 1:00.
You can also maintain your system times in better synchronization, with
available tools described in Section 4.2 and elsewhere.
4.3.2 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.16 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 18.104.22.168.1, Section 4.1.1, and Section 4.3.4.
4.3.3 Resetting the system time into the past?
You can resynchronize system time using DCL commands such as SET TIME and SET TIME/CLUSTER, but these commands can and obviously will cause the current system time to be set backwards when the specified time predates the current system time. This time-resetting operation can cause application problems, and can adversely effect applications using absolute timers, applications that assume time values will always be unique and ascending values, and applications.
Setting the time backwards by values of even an hour has caused various run-time problems for applications and layered products. For this reason, this technique was not considered supported during the Year 2000 (Y2K) testing; a system or cluster reboot was strongly recommended as the correct means to avoid these problems.
Application programmers are encouraged to use the time-related and TDF-related events that are available with the $set_system_event system service, and/or to use UTC or similar time, as these techniques can permit the application to better survive retrograde clock events. (There is an ECO to repair problems seen in the DECnet-Plus support for generating TDF events from DTSS, and this applies to V7.3 (expected to be in ECO4 and later) V7.3-1 (expected to be in ECO3 and later) and V7.3-2 (expected to be in ECO1 and later). Apply the most current DECnet-Plus ECO kits for these OpenVMS releases, for best TDF event support from DECnet-Plus.)
See Section 4.3.4 and Section 4.3.1.
4.3.4 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 saving 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. (Do look at either not switching to daylight time, or (better) using UTC as your time-base, if this change-over is not feasible for your environment.)
See Section 4.3.4 and Section 4.3.3.
4.3.5 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.2.
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:
Also, for TCP/IP Services prior to V5.0, see the NTP template file:
Note that NTP does not provide for a Daylight Saving 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 DTS TDF management details to be determined.
In OpenVMS Alpha V6 releases (V6.1, V6.2, V6.2-1Hx, etc), 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 saving time (DST) switchover is handled automatically only when DCE DTS or DECnet-Plus DTSS is in use. In V7.3, OpenVMS can be configured to automatically switch over to daylight 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 time and standard time is correctly accomplished via the SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM command procedure procedure.
NTP (alone) does NOT provide automatic switch-over.
The DST switch-over does NOT drift the time value; the switch-over applies the entire difference as a unit, as is standard and expected practice. (Do look at either not switching to daylight time, or (better) using UTC as your time-base, if this one-hour change is not feasible within your environment.) (For information associated with drifting the systen time, please see Section 4.3.4.)
If you switch the TDF or DST 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 can include the need to restart the NFS
client and NTP. (In the case of NTP, will want to try to
"drift" the time (see Section 4.2 and see Section 4.3.4), and
will find that the DST switch-over will exceed the NTP-defined maximum
threshold allowed for drifting. Hence the NTP restart is presently
4.4.1 Creating, Updating and Managing Timezone Definitions?
One issue with the UTC implementation on OpenVMS is the behaviour of C functions and other programs that use SYS$TIMEZONE_RULE; the OpenVMS mechanism assumes all control over the timezone and the daylight time switchover. This allows calculation of the time by the C library and various applications.
This can be incompatible with a system or application that requires manual modifications to the DST or TDF settings, or that requires a local or customized timezone definition. For such a site to ensure the timekeeping is correct, the site must provide procedure that sets the local time and the TDF when the SYS$TIMEZONE_RULE says to do it.
If a site requires a non-standard time switch-over, as in coordinating with a shift change or due to changes in the local or regional timezone rules, the site will need to use the zic compiler to create a custom timezone rule.
Additionally, applications may need to have special actions taken or actions queued just before the time change takes effect. If the application source code is available, one of the best ways to handle this is via the TDF and time-change notification events available via the OpenVMS sys$set_system_event system service.
For information on zic and related tools used to manage the OpenVMS Timezone database, please see the HP 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.
For related information, see Section 22.214.171.124.
126.96.36.199 Customizing or Updating your TDF (Timezone) Setting?
Individual, local, and regional differences on the use (or the lack of use) of Daylight Saving Time (DST) are quite common, as are occasional regulatory changes to the particular applicable regional DST settings. (eg: The United States Government is expecting to change its DST rules starting in March of 2007; please see Section 188.8.131.52 for details.)
DST-related ECO kits are now available for various of the supported releases, please see the ECO FTP site for details.
If you need or wish to add, modify or remove DST rules 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, or potentially simply downloading a new set of DST rules. This requirement can arise, for instance, if your local region changes its timezone rules, or if you are using an OpenVMS release that does not have an ECO kit for the US DST rules available.)
The necessary zone line to add for support of the hypothetical new WhereEverLand timezone will probably look something like this:
# Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone WhereEver 2:00 - WhereEver
The OpenVMS source files for the timezone rules are stored here:
You'll then want to use the zic compiler to compile your own new timezone definition, or to compile a new set of timezone definitions that have been freshly downloaded from a published source.
The zic compiler is documented in the OpenVMS Documentation Set, and specifically in the HP C Run-Time Library Reference Manual. (Despite the name of this manual, it is part of the OpenVMS documentation set and not of the C manuals.)
Once you have created and compiled a new timezone rule (or have downloaded and have compiled a whole new set of timezone rules), use the SYS$MANAGER:UTC$TIME_SETUP.COM to select the new timezone if necessary---with V7.3 and later, this tool will automically notice the new timezone and will offer it, on earlier releases, you may/will have to hack the code of the tool somewhat to allow it to present the new timezone rule. (If an existing timezone rule is simply changing, you don't need this re-selection step.)
As mentioned in Section 4.4.2, please don't modify or redefine 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. Rather, please use the zic compiler and/or the UTC$TIME_SETUP.COM procedure.
For various published timezone rules or updated to same, see the tar.gz files (these are gzipped tar archives) available at:
These are gzipped tar archives, and are the pubished source used for the OpenVMS timezone rules on OpenVMS V7.3 and later, and within the predecessor C run-time environment timezone support used on older OpenVMS releases. You'll need to first gunzip and then use vmstar to unpack and access the contents of the archives.
The published timezone rules include the effective date ranges for the individual rules, so you can reload your rules prior to a particular set of new rules becoming effective. The effective dates for the particular timezone rules are additionally necessary to allow the appropriate translation of older dates and times within the appropriate historical context of the particular date and time value.
For related information, see Section 4.4.1.