=;The OpenVMS Frequently Asked Questions (FAQ)D

The OpenVMS Frequently Asked Questions (FAQ)



 r \ ^  
PreviousContentsIndex

S

4.1.1.2 Alpha hardware time-keeping details...

N

4.1.1.2.1 Battery-Backed Watch (BB_WATCH) Chip

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

GThe BB_WATCH time is used to initialize the running system time during Fbootstrap, and the BB_WATCH time is read when the SET TIME command is Hissued with no parameters; when the running system time is reset to the Fvalue stored in the BB_WATCH. The running system time is written into Bthe BB_WATCH when the SET TIME command is issued with a parameter.

FThe specification for maximum clock drift in the Alpha hardware clock Bis 50 parts per million (ppm), that is less than ±0.000050 Fseconds of drift per second, less than ±0.000050 days of drift Eper day, or less than ±0.000050 years of drift per year, etc. G(eg: An error of one second over a day-long interval is roughly 11ppm, Hor 1000000/(24*60*60).) Put another way, this is .005%, which is around -130 seconds per month or 26 minutes per year.

HThe software-maintained system time can drift more than this, primarily Hdue to other system activity. Typical causes of drift include extensive Ghigh-IPL code (soft memory errors, heavy activity at device IPLs, etc) Fthat are causing the processing of the clock interrupts to be blocked.=

4.1.1.2.2 EXE$GQ_SYSTIME

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

4.1.1.2.3 EXE$GQ_SAVED_HWCLOCK

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

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

<IA-64 (Itanium) hardware time-keeping details to be added...W

4.1.1.3 Why does VAX need a SET TIME at least once a year?



EBecause the VAX Time Of Year (TOY) has a resolution of 497 days, the HVAX system time is stored using both the TOY and the OpenVMS VAX system Dimage SYS.EXE. Because of the use of the combination of the TOY and GSYS.EXE, you need to issue a SET TIME command (with the time parameter Especified) at least once between January 1st and about April 11th of Aeach year, and whenever you change system images (due to booting Hanother 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 Hautomatically issued during various standard OpenVMS procedures such as ESHUTDOWN, and it can also obviously be issued directly by a suitably Hprivileged user. Issuing the SET TIME command (with a parameter) resets Athe value stored in the TOY, and (if necessary) also updates the Cportion of the time (the current year) saved in the SYS.EXE system image.

GThis VAX TOY limit is the reason why OpenVMS VAX installation kits and Gstandalone BACKUP explicitly prompt for the time during bootstrap, and Ewhy the time value can "get weird" if the system crashes outside the G497 day window (if no SET TIME was issued to update the saved values), 6and why the time value can "get weird" if a different FSYS$SYSTEM:SYS.EXE is used (alternate system disk, standalone BACKUP, etc).M

4.1.2 How does OpenVMS VAX maintain system time?



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

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

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

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

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

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

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

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

4.2 Keeping the OpenVMS system time synchronized?



ETo help keep more accurate system time or to keep your system clocks Hsynchronized, TCP/IP Services NTP, DECnet-Plus DTSS (sometimes known as EDECdtss), DCE DTS, and other techniques are commonly used. If you do Gnot or cannot have IP access to one of the available time-base servers Don the Internet, then you could use dial-up access to NIST or other Bauthoritative site, or you can use a direct connection to a local authorative clock.

HThere exists code around that processes the digital (ie: binary) format Atime that is available via a modem call into the NIST clock (the >Automated Computer Telephone Service (ACTS) service), and codeCthat grabs the time off a GPS receiver digital link, or a receiver G(effectively a radio and a codec) that processes the time signals from +radio stations WWV, WWVH, WWVB, or similar.

GProcessing the serial or hardware time protocols often involves little Hmore than reading from an EIA232 (RS232) serial line from the receiver, Bsomething that is possible from most any language. Information on Hcorrectly drifting the OpenVMS system clock to match the time-base time His available within the logic of at least one OpenVMS Freeware package. \(See Section 4.3 for a few potential hardware options.)

FOne example of acquring a time-base through local integrated hardware involves the IRIG time formatH(IRIG-A, -B, -G), a binary signal containing the current time in hours, Hminutes, seconds and days since the start of the current year. IRIG can Falso contain the time of day as the number of seconds since midnight. AHP Custom Systems and third-party vendors have variously offered 8IRIG-based reader/generator modules for OpenVMS systems.

FOne of the easiest approaches is a network-based GPS or other similar Greceiver. Basically, this is a network server box that provides an NTP Dserver with the necessary hardware for external synchronization. In Daddition to the antenna and the receiver and processing components, Gthese devices provide a network interface (NIC) and support for an NTP Ftime server, and applications including the NTP support within TCP/IP FServices 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 Gconfiguration steps and no host software beyond NTP are required. (See WSection 4.3 for a few potential hardware options.)

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

HUnlike DECnet-Plus, TCP/IP Services NTP is not capable of connecting to Ha time-base other than the network time base or the local system clock. BThird-party and open source NTP implementations are available for OpenVMS, as well.

Useful URLs:

X

4.3 External time-base hardware?



HHere are a few possibilities for providers of a GPS-based receiver with Fan embedded NTP server, strictly culled from the first few pages of a FGoogle search. Availability, pricing, OpenVMS compatibility and other factors are not known.



GFor a direct-connected (local, non-IP, non-NTP) link, there are serial Foptions available. Google finds Spectracom Corporation has a NetClock Hthat could be used here, based on a quick look---I do not know if there Fis OpenVMS host software, but that would be possible to write for the BASCII data stream that the device supports. (Such coding requires Dknowledge of serial I/O, character processing, and knowledge of the Dclock 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.)

http://www.spectracomcorp.com/

HInformation on, and experiences or recommendations for or against these $or other similar devices is welcome.S

4.3.1 Why do my cluster batch jobs start early?



HYour system time is skewed across your cluster members, and the cluster Cmember performing the queue management tasks has a system time set ?later than the system time of the member running the batch job.

FThis behaviour is most noticable when using SUBMIT/AFTER=TOMORROW and Esimilar constructs, and use of /AFTER="TOMMOROW+00:01:00" or such is Eoften recommended as a way to avoid this. The combination time value Gspecified should be larger than the maximum expected time skew. In the Hexample shown, the maximum cluster clock skew is assumed less than 1:00.

HYou can also maintain your system times in better synchronization, with [available tools described in Section 4.2 and elsewhere.I

4.3.2 Why does my OpenVMS system time drift?



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

AWhen clock interrupts are blocked as a result of the activity of Ahigh-IPL code---such as extensive driver interrupt activity or a Ehardware error or a correctable (soft) memory error---the clock will E"loose" time, and the time value reported to the user with Fappear to have slowed down. Correctable memory errors can be a common Ecause 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 Gcontrollers including the ELSA GLoria Synergy PBXGK-BB; the PowerStorm m3D10T effectively stalling the PCI bus. See Section 5.16 for details on Bthe ELSA GLoria Synergy controller, and make certain you have the #current GRAPHICS ECO kit installed.

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

Also see Section 4.1.1.2.1, Section 4.1.1, and Section 4.3.4.S

4.3.3 Resetting the system time into the past?



<You can resynchronize system time using DCL commands such asDSET TIME and SET TIME/CLUSTER, but these commands can and obviously @will cause the current system time to be set backwards when the Especified time predates the current system time. This time-resetting Coperation can cause application problems, and can adversely effect Bapplications using absolute timers, applications that assume time Dvalues will always be unique and ascending values, and applications.

HSetting the time backwards by values of even an hour has caused various Brun-time problems for applications and layered products. For this Dreason, this technique was not considered supported during the Year H2000 (Y2K) testing; a system or cluster reboot was strongly recommended -as the correct means to avoid these problems.

CApplication programmers are encouraged to use the time-related and @TDF-related events that are available with the $set_system_eventGsystem service, and/or to use UTC or similar time, as these techniques Fcan permit the application to better survive retrograde clock events. H(There is an ECO to repair problems seen in the DECnet-Plus support for Ggenerating TDF events from DTSS, and this applies to V7.3 (expected to Dbe in ECO4 and later) V7.3-1 (expected to be in ECO3 and later) and BV7.3-2 (expected to be in ECO1 and later). Apply the most current DDECnet-Plus ECO kits for these OpenVMS releases, for best TDF event support from DECnet-Plus.)

sSee Section 4.3.4 and Section 4.3.1.K

4.3.4 How can I drift the OpenVMS system time?



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

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

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

DFor those areas which switch between daylight saving time (DST) and Cstandard time, the time value is not drifted. The time is Cadjusted by the entire interval. This procedure is inherent in the Ddefinition of the switch between DST and standard time. (Do look at Eeither not switching to daylight time, or (better) using UTC as your Etime-base, if this change-over is not feasible for your environment.)

tSee Section 4.3.4 and Section 4.3.3.^

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



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

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

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

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

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

HWith TCP/IP Services V5.0 and later, the only supported reference clock Gis the LCL (local system clock). If your system has an excellent clock Hor if the system time is being controlled by some other time service or Hperipheral (such as DTSS services, GPS services, a cesium clock, a GPIB Hcontroller or other similar time-related peripheral), you can configure ENTP to use the system clock as its reference source. This will mimic Ethe master-clock functionality, and will configre NTP as a stratum 1 Htime 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 




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

 

"
server 127.127.1.0 fudge 127.127.1.0 stratum 8 




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

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

 

"
master-clock 1 




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

 

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




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

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

z

4.4 Managing Timezones, Timekeeping, UTC, and Daylight Saving Time?



+You will want to use the command procedure:



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



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

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

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

0DCE DTS TDF management details to be determined.

HIn OpenVMS Alpha V6 releases (V6.1, V6.2, V6.2-1Hx, etc), the TDF value !is written to SYS$BASE_IMAGE.EXE.GWith OpenVMS Alpha V7.0 and later and with OpenVMS VAX V6.0 and later, SYS$SYSTEM:SYS$TIMEZONE.DATEcontains the TDF. This means that OpenVMS Alpha systems will need to 3have the TDF value reset manually---usually within -SYSTARTUP_VMS.COM---on reboots prior to V7.0.

GDuring OpenVMS Bootstrap, the SYSINIT module reads SYS$TIMEZONE.DAT to Eacquire the TDF for use in the system global cell EXE$GQ_TDF. This isEdone to ensure that the system boots with a valid TDF (a value which Hmay be zero). The UTC system services get the TDF from this cell. These Dservices, 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 Gconfigured and run, the image DTSS$SET_TIMEZONE.EXE is invoked and can override the4TDF and timezone rule settings from SYSINIT or from UTC$TIME_SETUP.COM---Gthis image runs even if DTSS is disabled. If the settings do not match H(due to inconsistencies in timezone specification in UTC$TIME_SETUP.COM @and NET$CONFIGURE.COM), DTSS will reset the values to match its definitions.)

HPrior to OpenVMS V7.3, daylight saving time (DST) switchover is handled >automatically only when DCE DTS or DECnet-Plus DTSS is in use.CIn V7.3, OpenVMS can be configured to automatically switch over to Hdaylight time, and also generates an event that interested applications Ecan use to detect the switch-over between standard time and daylight time.

AThe manual switchover between daylight time and standard time is @correctly accomplished via the SYS$EXAMPLES:DAYLIGHT_SAVINGS.COMcommand procedure procedure.



/  
Note

DNTP (alone) does NOT provide automatic switch-over.




/  
Note

@The DST switch-over does NOT drift the time value; the Hswitch-over applies the entire difference as a unit, as is standard and Fexpected practice. (Do look at either not switching to daylight time, Hor (better) using UTC as your time-base, if this one-hour change is not Dfeasible within your environment.) (For information associated with `drifting the systen time, please see Section 4.3.4.)


GIf you switch the TDF or DST setting, you will also want to restart or Freconfigure any time-sensitive applications (those not using the time Edifferential factor (TDF) change event available in V7.3 and later). GExamples of these applications can include the need to restart the NFS 9client 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 Gwill find that the DST switch-over will exceed the NTP-defined maximum Cthreshold allowed for drifting. Hence the NTP restart is presently required.)




 r Y \ ^  
PreviousNextContentsIndex