f- OpenVMS FAQ -&- page 5)b @5z

HP OpenVMS Systems Documentation

 q> $"b,
Content starts here"D

The OpenVMS Frequently Asked Questions (FAQ)


 l n  
PreviousContentsIndex

S

4.1.1.2 Alpha hardware time-keeping details...

N

4.1.1.2.1 Battery-Backed Watch (BB_WATCH) Chip

DThis is battery backed up hardware timing circuitry used to keep theAcorrect time of year during rebooting, power failures, and systemCshutdown. This clock keeps track of date and time in 24 hour binaryformat.

FThe BB_WATCH time is used to initialize the running system time duringEbootstrap, and the BB_WATCH time is read when the SET TIME command isGissued with no parameters; when the running system time is reset to theEvalue stored in the BB_WATCH. The running system time is written intoBthe BB_WATCH when the SET TIME command is issued with a parameter.

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

GThe software-maintained system time can drift more than this, primarilyGdue to other system activity. Typical causes of drift include extensiveFhigh-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

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

4.1.1.2.3 EXE$GQ_SAVED_HWCLOCK

EThis cell is used by OpenVMS Alpha to keep track of the last time andGdate that EXE$GQ_SYSTIME was adjusted. It keeps the same time format asDEXE$GQ_SYSTIME. The value in this cell gets updated in memory and on.disk, every time EXE$GQ_SYSTIME gets adjusted.
    H
  • The system parameters SETTIME and TIMEPROMPTWAIT determine how the system time will be set.
  • If SETTIME = 0
    Fthen EXE$INIT_HWCLOCK reads the hardware clock to set the system time.
    • IF TIMEPROMPTWAIT > 0
      @THEN the value of TIMEPROMPTWAIT determines how long the user isDprompted to enter the time and date. If time expires and no time has6been entered the system acts as if TIMEPROMPTWAIT = 0.
    • IF TIMEPROMPTWAIT = 0
      7THEN the system time is calculated from the contents ofEXE$GQ_SAVED_HWCLOCK + 1.
    • IF TIMEPROMPTWAIT < 0
      FTHEN the user is prompted for the time and date and unable to continue!until the information is entered.
    


GUnlike the VAX, the Alpha hardware clock tracks the full date and time,Enot just the time of year. This means it is possible to boot from theECD-ROM media without entering the time at the CD-ROM bootstrap. (ThisBprovided 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?



DBecause the VAX Time Of Year (TOY) has a resolution of 497 days, theGVAX system time is stored using both the TOY and the OpenVMS VAX systemCimage SYS.EXE. Because of the use of the combination of the TOY andFSYS.EXE, you need to issue a SET TIME command (with the time parameterDspecified) at least once between January 1st and about April 11th of@each year, and whenever you change system images (due to bootingGanother OpenVMS VAX system, booting the standalone BACKUP image, an ECOthat replaces SYS.EXE, etc).

>The SET TIME command (with the current time as a parameter) isGautomatically issued during various standard OpenVMS procedures such asDSHUTDOWN, and it can also obviously be issued directly by a suitablyGprivileged user. Issuing the SET TIME command (with a parameter) resets@the value stored in the TOY, and (if necessary) also updates theBportion of the time (the current year) saved in the SYS.EXE systemimage.

FThis VAX TOY limit is the reason why OpenVMS VAX installation kits andFstandalone BACKUP explicitly prompt for the time during bootstrap, andDwhy the time value can "get weird" if the system crashes outside theF497 day window (if no SET TIME was issued to update the saved values),5and why the time value can "get weird" if a differentESYS$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.

DThe VAX hardware clock is called the TOY ("Time Of Year") clock. TheCregister associated with the clock is called the TODR ("Time Of Day Register").

FThe 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-bitEcounter, incremented every 10ms, and thus has a capacity of circa 497days.

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

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

DOnce the interval clock is loaded into the running system as part ofEthe system bootstrap, the system does not typically reference the TOYagain, unless aE SET TIME (with no parameters) is issued. The interval clock value is@ updated by a periodic IPL22 or IPL24 (depending on the specificC implementation) interrupt. (When these interrupts are blocked as aE result of the activity of higher-IPL code---such as extensive driverF interrupt activity or a hardware error or a correctable (soft) memoryB error---the clock will "loose" time, and the time value7 reported to the user with appear to have slowed down.)

CWhen SET TIME is issued with no parameters, the TOY clock is loadedBinto the system clock; the running system clock is set to the timeDstored in the TOY clock. This assumes the TOY clock is more accurate/than the system clock, as is normally the case.

GOn most (all?) VAX systems, the battery that is associated with the TOYEclock can be disconnected and replaced if (when) it fails---TOY clockGfailures 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?



DTo help keep more accurate system time or to keep your system clocksGsynchronized, TCP/IP Services NTP, DECnet-Plus DTSS (sometimes known asDDECdtss), DCE DTS, and other techniques are commonly used. If you doFnot or cannot have IP access to one of the available time-base serversCon the Internet, then you could use dial-up access to NIST or otherAauthoritative site, or you can use a direct connection to a localauthorative clock.

GThere 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 codeBthat grabs the time off a GPS receiver digital link, or a receiverF(effectively a radio and a codec) that processes the time signals from+radio stations WWV, WWVH, WWVB, or similar.

FProcessing the serial or hardware time protocols often involves littleGmore than reading from an EIA232 (RS232) serial line from the receiver,Asomething that is possible from most any language. Information onGcorrectly drifting the OpenVMS system clock to match the time-base timeGis available within the logic of at least one OpenVMS Freeware package.l(See Section 4.3 for a few potential hardware options.)

EOne example of acquring a time-base through local integrated hardwareinvolves the IRIG time formatG(IRIG-A, -B, -G), a binary signal containing the current time in hours,Gminutes, seconds and days since the start of the current year. IRIG canEalso contain the time of day as the number of seconds since midnight.@HP Custom Systems and third-party vendors have variously offered8IRIG-based reader/generator modules for OpenVMS systems.

EOne of the easiest approaches is a network-based GPS or other similarFreceiver. Basically, this is a network server box that provides an NTPCserver with the necessary hardware for external synchronization. InCaddition to the antenna and the receiver and processing components,Fthese devices provide a network interface (NIC) and support for an NTPEtime server, and applications including the NTP support within TCP/IPEServices 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 hostFconfiguration steps and no host software beyond NTP are required. (SeegSection 4.3 for a few potential hardware options.)

CDiffering time servers (DECnet-Plus DTSS, DCE DTS, NTP, etc) do notCcoexist particularly well, particularly if you try to use all theseDtogether on the same node. Please pick and use just one. (If needed,Dyou can sometimes configure one package to acquire its timebase fromFanother protocol, but one and only one time server package should haveGdirect control over the management of and drifting of the local OpenVMSDsystem time. In the specific case of DECnet-Plus DTSS, older productAversions and versions V7.3 and later provide a provider module, aFmodule which permits DTSS to acquire its time from NTP. For details onAthis, please see the comments in the module DTSS$NTP_PROVIDER.C.)

GUnlike DECnet-Plus, TCP/IP Services NTP is not capable of connecting toGa time-base other than the network time base or the local system clock.AThird-party and open source NTP implementations are available forOpenVMS, as well.

Useful URLs:

X

4.3 External time-base hardware?



GHere are a few possibilities for providers of a GPS-based receiver withEan embedded NTP server, strictly culled from the first few pages of aEGoogle search. Availability, pricing, OpenVMS compatibility and otherfactors are not known.



FFor a direct-connected (local, non-IP, non-NTP) link, there are serialEoptions available. Google finds Spectracom Corporation has a NetClockGthat could be used here, based on a quick look---I do not know if thereEis OpenVMS host software, but that would be possible to write for theAASCII data stream that the device supports. (Such coding requiresCknowledge of serial I/O, character processing, and knowledge of theCclock drift API mechanisms in OpenVMS---there exists Freeware tools>that could be used to learn how to tie into the clock driftingmechanisms of OpenVMS.)

http://www.spectracomcorp.com/

GInformation 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?



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

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

GYou can also maintain your system times in better synchronization, withkavailable tools described in Section 4.2 and elsewhere.I

4.3.2 Why does my OpenVMS system time drift?



BMemory errors, hardware problems, or most anything operating at orBabove IPL 22 or IPL 24 (clock IPL is system family dependent; codeFexecuting at or above the clock IPL will block the processing of clockGinterrupts), can cause the loss of system time. Clock drift can also beMDcaused by normal (thermal) clock variations and even by the expectedlevel of clock drift.>

v@When clock interrupts are blocked as a result of the activity of@high-IPL code---such as extensive driver interrupt activity or aDhardware error or a correctable (soft) memory error---the clock willD"loose" time, and the time value reported to the user withEappear to have slowed down. Correctable memory errors can be a common"Dcause of system time loss, in other words. Heavy PCI bus traffic canalso cause lost time.d

i?One bug in this area involved the behaviour of certain graphicscFcontrollers including the ELSA GLoria Synergy PBXGK-BB; the PowerStorm|3D10T effectively stalling the PCI bus. See Section 5.16 for details onAthe ELSA GLoria Synergy controller, and make certain you have theg#current GRAPHICS ECO kit installed.n

aDClock drift can also be (deliberately) caused by the activity of theDTSS or NTP packages.e

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

4.3.3 Resetting the system time into the past?

w

1<You can resynchronize system time using DCL commands such asCSET TIME and SET TIME/CLUSTER, but these commands can and obviouslyhGSetting the time backwards by values of even an hour has caused variouscArun-time problems for applications and layered products. For thisoCreason, this technique was not considered supported during the YeartG2000 (Y2K) testing; a system or cluster reboot was strongly recommendedm-as the correct means to avoid these problems.e

BApplication programmers are encouraged to use the time-related and@TDF-related events that are available with the $set_system_eventFsystem service, and/or to use UTC or similar time, as these techniquesEcan permit the application to better survive retrograde clock events. G(There is an ECO to repair problems seen in the DECnet-Plus support fortFgenerating TDF events from DTSS, and this applies to V7.3 (expected toCbe in ECO4 and later) V7.3-1 (expected to be in ECO3 and later) and0AV7.3-2 (expected to be in ECO1 and later). Apply the most currentrCDECnet-Plus ECO kits for these OpenVMS releases, for best TDF eventnsupport from DECnet-Plus.)

aSee Section 4.3.4 and Section 4.3.1.rK

4.3.4 How can I drift the OpenVMS system time?

f

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

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

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

mCFor those areas which switch between daylight saving time (DST) and Bstandard time, the time value is not drifted. The time isBadjusted by the entire interval. This procedure is inherent in theCdefinition of the switch between DST and standard time. (Do look at Deither not switching to daylight time, or (better) using UTC as yourEtime-base, if this change-over is not feasible for your environment.)i

aSee Section 4.3.4 and Section 4.3.3.^

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



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

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

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

tDNTP at other (lower) strata both receive time from higher strata andDcan provide time to lower strata, and automatically adjust the localEstratum. The highest stratum is one, and the lowest available stratuma is fifteen.l

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

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

s 
e
"
server 127.127.1.0 prefertfudge 127.127.1.0 stratum 0

=


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

/ 
a
"
server 127.127.1.0fudge 127.127.1.0 stratum 8i

i


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

FWith the TCP/IP Services versions prior to V5.0, the NTP management isDrather more primitive. To configure the local OpenVMS system from anANTP client to an NTP server (on TCP/IP Services versions prior toaGV5.0), add the following line to the sys$specific:[ucx$ntp]ucx$ntp.confrfile:c

 
r
"
master-clock 1




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

T 
l
"
&SYS$SPECIFIC:[UCX$NTP]UCX$NTP.TEMPLATE

e


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

OEFor current TCP/IP Services and related OpenVMS documentation, pleaselsee:

nz

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



l+You will want to use the command procedure:a

    $
  • SYS$MANAGER:UTC$TIME_SETUP.COM
?

1Fto configure the OpenVMS Timezone Differential Factor (TDF) on OpenVMSGV6.0 and later. Select the BOTH option. This configures the OpenVMS TDFmEsettings, though it may or may not configure the TDF and the timezone.Grules needed or used by other software packages. Please do NOT directlye(invoke the following command procedures:

    =
  • SYS$MANAGER:UTC$CONFIGURE_TDF.COM ! do not directly usee>
  • SYS$MANAGER:UTC$TIMEZONE_SETUP.COM ! do not directly use
2

ETCP/IP Services V5.0 and later use the OpenVMS TDF, UTC, and timezonesCsupport. Earlier versions use a TDF mechanism and timezone databasedDthat is internal to the TCP/IP Services package. Also on the earlierEversions, the TDF must be manually configured within TCP/IP Services,x4in addition to the OpenVMS configuration of the TDF.

fEDECnet-Plus in V7.3 and later uses the OpenVMS TDF, UTC, and timezoneaDsupport, and displays its timezone prompts using UTC$TIME_SETUP.COM.@Earlier versions use a TDF TDF mechanism, timezone database, andGautomatic switch-over that is internal to the DECnet-Plus package. Also3Fon earlier versions, the TDF must be configured within the DECnet-PlusEDECdtss package, in addition to the OpenVMS configuration of the TDF.l

mDApplication code using HP C (formerly Compaq C, formerly DEC C) willEuse the OpenVMS UTC and TDF mechanisms when the C code is compiled onh@OpenVMS V7.0 and later (and when the macro _VMS_V6_SOURCE is NOTGdefined). HP C does NOT use the OpenVMS UTC and TDF mechanisms when ther C code isoDcompiled on OpenVMS releases prior to V7.0, or when the preprocessor'declaration _VMS_V6_SOURCE is declared.I

y0DCE DTS TDF management details to be determined.

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

FDuring OpenVMS Bootstrap, the SYSINIT module reads SYS$TIMEZONE.DAT toEacquire the TDF for use in the system global cell EXE$GQ_TDF. This isDdone to ensure that the system boots with a valid TDF (a value whichGmay be zero). The UTC system services get the TDF from this cell. ThesecCservices, as well as the HP C RTL, must have a valid TDF. (Prior tow?OpenVMS V7.3, if either DECnet-Plus or DECnet/VAX Extensions isEFconfigured and run, the image DTSS$SET_TIMEZONE.EXE is invoked and can override the3TDF and timezone rule settings from SYSINIT or fromdUTC$TIME_SETUP.COM--- Fthis image runs even if DTSS is disabled. If the settings do not matchG(due to inconsistencies in timezone specification in UTC$TIME_SETUP.COMo?and NET$CONFIGURE.COM), DTSS will reset the values to match itse definitions.)c

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

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

w

/b  r
Note

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

r

/q h p
Note

?The DST switch-over does NOT drift the time value; theGswitch-over applies the entire difference as a unit, as is standard andrEexpected practice. (Do look at either not switching to daylight time,sGor (better) using UTC as your time-base, if this one-hour change is nottCfeasible within your environment.) (For information associated with"pdrifting the systen time, please see Section 4.3.4.)
g

Section 4.2 and see Section 4.3.4), andsFwill find that the DST switch-over will exceed the NTP-defined maximumBthreshold allowed for drifting. Hence the NTP restart is presently required.)M




 i .l n  i
PreviousNextContentsIndex

 

s#t6MTROW andDsimilar constructs, and use of /AFTER="TOMMOROW+00:01:00" or such isDoften recommended as a way to avoid this. The combination time valueFspecified should be larger than the maximum expected time skew. In theHexample shown, the maximum cluster clock skew is assumed less than 1:00.

GYou can also maintain your筗c T0PENPLUS'HPWEB_LEFT-LOCAL.INC;BEAVIS DISK$WEB3 .2CB(y筗c @ META.INC;BEAVIS DISK$WEB3 .2CB(y筗 c AINDEX.HTM;BEAVIS DISK$WEB3 *.2CB(y筗 c F"LEFT-LOCAL.INC;BEAVIS DISK$WEB3  .2CB(y筗 c D OPENPLUS.GIF;BEAVIS DISK$WEB3  .2CB(y筗 c S/US-ONE'HPWEB_LEFT-LOCAL.INC;BEAVIS DISK$WEB3 .2CB(y筗 c