=:The OpenVMS Frequently Asked Questions(FAQ)C

The OpenVMS Frequently Asked Questions(FAQ)



 r \ ^  
PreviousContentsIndex

s

3.10 Access to the OpenVMS Netscape Navigator documentation?



HThe documentation URLs embedded into the browser itself may not operate Gcorrectly in all cases, and (for reasons not worthy of repeating here) redirects may not be available.

.You can manually access the documentation via:




A

Chapter 4
Time and Timekeeping


w

4.1 UTC vs GMT vs vs UT1/UT1/UT2 TDF? What are these acronyms?



FThe results of an international compromise---though some would say an Cinternational attempt to increase confusion---UTC is refered to as F"Coordinated Universal Time" (though not as CUT) in English Hand as "Temps Universel Coordinné" (though not as TUC) Din French. (No particular information exists to explain why UTC was Achosen over the equally nonsensical TCU, according to Ulysses T. =Clockmeister, one of the diplomats that helped establish the international compromise.)

DUniversal Time UT0 is solar time, UT1 is solar time corrected for a Cwobble in the Earth's orbit, and UT2 is UT1 corrected for seasonal Arotational variations in rotation due to the Earth's solar orbit.

HGMT---Greenwich Mean Time---is UT1. GMT is the time at the classic site @of the since-disbanded Royal Greenwich Observatory; at the most 6widely-known tourist attraction of Greenwich, England.

FUTC is based on an average across multiple atomic clocks, and is kept Awithin 0.9 seconds of GMT, through the insertion (or removal) of Aseconds. In other words, UTC matches GMT plus or minus up to 0.9 seconds, but UTC is not GMT.

FTDF is the Timezone Differential Factor, the interval of time between Cthe local time and UTC. Areas that celebrate daylight savings time G(DST) will see periodic changes to the TDF value, when the switch-over Hbetween daylight savings time and standard time occurs. The switch-over Eitself is entirely left to local governmental folks, and can and has Hvaried by political entity and politics, and the switch-over has varied )over the years even at the same location.

FIf your local OpenVMS system time is off by one hour (or whatever the Elocal DST change) for some or all applications, you probably need to @reset your local TDF. (For related details, please see sections ŽSection 4.4 and Section 10.23.0.0.0.1.) x>(Daylight Savings Time)

BFurther discussions of history and politics, the Royal Observers' Eoutbuildings, and the compromise that left the English with the Time CStandard (the Prime Meridian) and the French with the standards forHDistance and Weight (the Metric System) are left to other sources. Some 2of these other sources include the following URLs:

j

4.2 A brief history of OpenVMS Timekeeping, please?



FWhy does OpenVMS regards November 17, 1858 as the beginning of time...

BThe modified Julian date adopted by the Smithsonian Astrophysical Observatory (SAO)/for satellite tracking is Julian Day 2400000.5,4which turns out to be midnight on November 17, 1858.

GSAO started tracking satellites with an 8K (nonvirtual) 36-bit IBM 704 Din 1957 when Sputnik went into orbit. The Julian day was 2435839 on GJanuary 1, 1957. This is 11225377 octal, which was too big to fit into Ban 18-bit field. With only 8K of memory, the 14 bits left over by Gkeeping the Julian date in its own 36-bit word would have been wasted. HSAO also needed the fraction of the current day (for which 18 bits gave Fenough accuracy), so it was decided to keep the number of days in the Hleft 18 bits and the fraction of a day in the right 18 bits of one word.

>Eighteen bits allows the truncated Julian Day (the SAO day) toEgrow as large as 262143, which from November 17, 1858, allowed for 7 Hcenturies. Possibly, the date could only grow as large as 131071 (using G17 bits), but this still covers 3 centuries and leaves the possibility Fof representing negative time. The 1858 date preceded the oldest star Hcatalogue in use at SAO, which also avoided having to use negative time .in any of the satellite tracking calculations.

EThe original Julian Day (JD) is used by astronomers and expressed in >days since noon January 1, 4713 B.C. This measure of time was Aintroduced by Joseph Scaliger in the 16th century. It is named in+honor of his father, Julius Caesar Scaliger@(note that this Julian Day is different from the Julian calendar4that is named for the Roman Emperor Julius Caesar!).

HWhy 4713 BC? Scaliger traced three time cycles and found that they were Fall in the first year of their cyle in 4713 B.C. The three cycles are G15, 19, and 28 years long. By multiplying these three numbers (15 * 19 G* 28 = 7980), he was able to represent any date from 4713 B.C. through 3267 A.D.

CThe starting year was before any historical event known to him. In Dfact, the Jewish calendar marks the start of the world as 3761 B.C. EToday his numbering scheme is still used by astronomers to avoid the Ddifficulties of converting the months of different calendars in use during different eras.

The following web sites:



Gare all good time-related resources, some general and some specific to OpenVMS.O

4.2.1 Details of the OpenVMS system time-keeping?

R

4.2.1.1 VAX hardware time-keeping details...

3

4.2.1.1.1 TOY clock

EThis is battery backed up hardware timing circuitry used to keep the Bcorrect time of year during rebooting, power failures, and system Eshutdown. This clock only keeps track of months, days, and time. The Etime is kept relative to January 1st, at 00:00:00.00 of the year the clock was initiailized.;

4.2.1.1.2 EXE$GQ_SYSTIME

HThis is the OpenVMS VAX system time cell. This cell contains the number Hof 100ns intervals since a known reference. This cell is incremented by 0100000 every 10ms by an hardware interval timer.9

4.2.1.1.3 EXE$GQ_TODCBASE

GThis cell contains the time and date the system time was last adjusted >by EXE$SETTIME. It uses the same format as EXE$GQ_SYSTIME. On Dadjustment of the system time a copy of EXE$GQ_SYSTIME is stored in Hthis cell in both memory and on disk. This cell is used to get the year for the system time.1

4.2.1.1.4 EXE$GL_TODR

GThis cell contains the time and date the system time was last adjusted by EXE$SETTIME.HIt uses the same format as the time of year clock. On adjustment of the Csystem time this cell gets saved back to both memory and disk. The Econtents of this cell are used to test the validity of the TOY clock.

CThe system parameters SETTIME and TIMEPROMPTWAIT determine how the system time will be set.IF SETTIME = 0
<THEN the contents of the TOY clock are compared to those of CEXE$GL_TODR. IF the TOY clock is more than a day behind EXE$GL_TODR
'THEN the TOY clock is presumed invalid.

0
  • IF SETTIME = 1 or the TOY clock is invalid
    ETHEN the value of TIMEPROMPTWAIT determines how to reset the time of year. IF TIMEPROMPTWAIT > 0
    FTHEN the user is prompted for the time and date, for a length of time (equal to TIMEPROMPTWAIT microfortnights. 

    HWhen booting a CD-ROM containing an OpenVMS VAX system, the system will Gtypically be deliberately configured prompt the user to input the time <-- this is necessary in order to boot with the correct time.

    4If either TIMEPROMPTWAIT or SETTIME are set to zero,HOpenVMS VAX will use the TOY clock to get the time of year, and the yearEwill be fetched from the CD-ROM. The value of the year on the CD-ROM Hmedia (saved within the SYS.EXE image) will most likely be that of when Dthe CD-ROM was made, and cannot be changed. Unless the current year Hhappens to be the same year as that on the CD-ROM, most likely the year Dwill be off. (Further, with the calculation of Leap Year also being Ddependent on the current year, there is a possibility that the date could be off too.)S

    4.2.1.2 Alpha hardware time-keeping details...

    N

    4.2.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.=

    4.2.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.2.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.2.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 FSYS.EXE, you need to issue a SET TIME command (with no parameters) at Fleast once between January 1st and about April 11th of each year, and Fwhenever you change system images (due to booting another OpenVMS VAX Bsystem, booting the standalone BACKUP image, an ECO that replaces SYS.EXE, etc).

    EThe SET TIME command is automatically issued during various standard BOpenVMS procedures such as SHUTDOWN, and it can also obviously be Dissued directly by a suitably privileged user. Issuing the SET TIME Dcommand resets the value stored in the TOY, and (if necessary) also Hupdates the portion 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.2.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.

    AOnce the interval clock is loaded, the system does not typically Creference the TOY again, unless a SET TIME (with no parameters) is Cissued. The interval clock value is updated by a periodic IPL22 or HIPL24 (depending on the specific implementation) interrupt. (When these Ainterrupts are blocked as a result of the activity of higher-IPL Gcode---such as extensive driver interrupt activity or a hardware error Hor a correctable (soft) memory error---the clock will "loose" Btime, and the time value reported to the user with appear to have slowed down.)

    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.3 Keeping the OpenVMS system time synchronized?

    

    ETo help keep more accurate system time or to keep your system clocks Fsynchronized, TCP/IP Services NTP, DECnet-Plus DECdtss, DCE DTSS, and Fother 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.

    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)), and code that>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 Bradio station WWV, WWVH, WWVB, or similar. (Processing these time Aprotocols often involves little more than reading from an EIA232 G(RS232) serial line from the receiver, something that is possible from 0most any language as well as directly from DCL.)

    AOne example of acquring a time-base 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. CHP Custom Systems and third-party vendors offer various IRIG-based -reader/generator modules for OpenVMS systems.

    DDiffering time servers (DECnet-Plus DTSS, DCE DTSS, 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.)

    Useful URLs:

    I

    4.3.1 Why does my OpenVMS system time drift?

    x>(TIME3)

    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 appear to Ehave slowed down. Correctable memory errors can be a common cause of !system time loss, in other words.

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

    ¦Also see Section 14.14, Section 14.29, and Section 4.3.2.K

    4.3.2 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.

    EFor those areas which switch between daylight savings 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 7definition of the switch between DST and standard time.^

    4.3.3 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-accessable 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.3.

    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 Eor if the system time is being controlled by some other time service H(such as DTSS or GPS), you can configure NTP to use the system clock as Fits reference source. This will mimic the master-clock functionality, Hand 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 
    
    
    

    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 
    
    
    

    DNote that NTP does not provide for a Daylight Savings 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:

    v

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

    

    +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.

    DCE DTSS TDF details TDB.

    GIn OpenVMS Alpha V6.1, V6.2, and V6.2-1Hx, 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.)

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

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

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

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

    FIf you switch the TDF or daylight savings time setting, you will also Fwant to restart or reconfigure any time-sensitive applications (those Gnot using the time differential factor (TDF) change event available in DV7.3 and later). Examples of these applications include the need to Grestart the NFS client and (yes) NTP. (NTP will want to try to "drift" hthe time (see Section 4.3), and will find the daylight savings time Hswitch-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:

     

    "
    1SET 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:

     

    "
    MCR DTSS$SET_TIMEZONE MODIFY 
    
    
    

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

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

     

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

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

    


     r Y \ ^  
    PreviousNextContentsIndex