| Previous | \Contents | ^Index |
H Your system time is skewed across your cluster members, and the cluster C member performing the queue management tasks has a system time set ? later than the system time of the member running the batch job.
F This behaviour is most noticable when using SUBMIT/AFTER=TOMORROW and E similar constructs, and use of /AFTER="TOMMOROW+00:01:00" or such is E often recommended as a way to avoid this. The combination time value G specified should be larger than the maximum expected time skew. In the H example shown, the maximum cluster clock skew is assumed less than 1:00.
H You can also maintain your system times in better synchronization, with [ available tools described in Section 4.2 and elsewhere. I 4.2.2 Why does my OpenVMS system time drift?
C Memory errors, hardware problems, or most anything operating at or C above IPL 22 or IPL 24 (clock IPL is system family dependent; code G executing at or above the clock IPL will block the processing of clock H interrupts), can cause the loss of system time. Clock drift can also be E caused by normal (thermal) clock variations and even by the expected level of clock drift.
A When clock interrupts are blocked as a result of the activity of A high-IPL code---such as extensive driver interrupt activity or a E hardware error or a correctable (soft) memory error---the clock will E "loose" time, and the time value reported to the user with F appear to have slowed down. Correctable memory errors can be a common E 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 G controllers including the ELSA GLoria Synergy PBXGK-BB; the PowerStorm m 3D10T effectively stalling the PCI bus. See Section 5.16 for details on B the ELSA GLoria Synergy controller, and make certain you have the # current GRAPHICS ECO kit installed.
E Clock drift can also be (deliberately) caused by the activity of the DTSS or NTP packages.
¥ Also see Section 14.8, Section 14.15, and Section 4.2.4. S 4.2.3 Resetting the system time into the past?
< You can resynchronize system time using DCL commands such as D SET TIME and SET TIME/CLUSTER, but these commands can and obviously @ will cause the current system time to be set backwards when the E specified time predates the current system time. This time-resetting C operation can cause application problems, and can adversely effect B applications using absolute timers, applications that assume time D values will always be unique and ascending values, and applications.
H Setting the time backwards by values of even an hour has caused various B run-time problems for applications and layered products. For this D reason, this technique was not considered supported during the Year H 2000 (Y2K) testing; a system or cluster reboot was strongly recommended - as the correct means to avoid these problems.
C Application programmers are encouraged to use the time-related and @ TDF-related events that are available with the $set_system_event G system service, and/or to use UTC or similar time, as these techniques F can permit the application to better survive retrograde clock events. H (There is an ECO to repair problems seen in the DECnet-Plus support for G generating TDF events from DTSS, and this applies to V7.3 (expected to D be in ECO4 and later) V7.3-1 (expected to be in ECO3 and later) and B V7.3-2 (expected to be in ECO1 and later). Apply the most current D DECnet-Plus ECO kits for these OpenVMS releases, for best TDF event support from DECnet-Plus.)
s See Section 4.2.4 and Section 4.2.1. K 4.2.4 How can I drift the OpenVMS system time?
H With DECdts and TCP/IP Services NTP, the system time value is "drifted" F (rather than changed), to avoid the obvious problems that would arise F with "negative time changes". The same basic clock drifting technique D is used by most (all?) time servers operating on OpenVMS, typically < using the support for this provided directly within OpenVMS.
F An example of the technique used (on OpenVMS VAX) to drift the system 2 time is the SETCLOCK tool on the OpenVMS Freeware.
8 For information on the use of the EXE$GL_TIMEADJUST and G EXE$GL_TICKLENGTH cells on OpenVMS Alpha, see OpenVMS AXP Internal . and Data Structures, located on page 348.
E For those areas which switch between daylight savings time (DST) and C standard time, the time value is not drifted. The time is C adjusted by the entire interval. This procedure is inherent in the 7 definition of the switch between DST and standard time.
t See Section 4.2.4 and Section 4.2.3. ^ 4.2.5 How can I configure TCP/IP Services NTP as a time provider?
B An NTP time provider provides its idea of the current time to NTP B clients via the NTP protocol. Most systems are NTP clients, but...
H NTP has a heirarchy of layers, called strata. The further away from the E actual NTP time source (Internet time servers are at stratum 1), the A lower the strata (and the larger the number assigned the statum).
G NTP explicity configured at stratum one provides time to NTP operating F at lower strata, and the provided time is acquired based on the local @ system time or via some locally-accessible external time source.
E NTP at other (lower) strata both receive time from higher strata and E can provide time to lower strata, and automatically adjust the local F stratum. The highest stratum is one, and the lowest available stratum is fifteen.
G The TCP/IP Services NTP package can operate at any stratum, and can be E configured as a peer, as a client, or as a broadcast server. NTP can e also provide time to a DECnet-Plus DTSS network, see Section 4.2.
H With TCP/IP Services V5.0 and later, the only supported reference clock G is the LCL (local system clock). If your system has an excellent clock H or if the system time is being controlled by some other time service or H peripheral (such as DTSS services, GPS services, a cesium clock, a GPIB H controller or other similar time-related peripheral), you can configure E NTP to use the system clock as its reference source. This will mimic E the master-clock functionality, and will configre NTP as a stratum 1 H 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 |
D For local-master functionality, the commands are very similiar. Use:
|
" server 127.127.1.0 fudge 127.127.1.0 stratum 8 |
E The difference between these two is the stratum, and the omission of G the prefer keyword. Specifying a higher stratum allows the node to act E as a backup NTP server, or potentially as the sole time server on an D isolated network. The server will become active only when all other D normal synchronization sources are unavailable. The use of "prefer" 9 causes NTP to always use the specified clock as the time synchronization source.
G With the TCP/IP Services versions prior to V5.0, the NTP management is E rather more primitive. To configure the local OpenVMS system from an B NTP client to an NTP server (on TCP/IP Services versions prior to H V5.0), add the following line to the sys$specific:[ucx$ntp]ucx$ntp.conf file:
|
" master-clock 1 |
C Also, for TCP/IP Services prior to V5.0, see the NTP template file:
|
" ' SYS$SPECIFIC:[UCX$NTP]UCX$NTP.TEMPLATE |
D Note that NTP does not provide for a Daylight Savings Time (DST) C switch-over, that switch must arise from the timezone rules on the E local 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.)
F For current TCP/IP Services and related OpenVMS documentation, please see:
v+ You will want to use the command procedure:
G to configure the OpenVMS Timezone Differential Factor (TDF) on OpenVMS H V6.0 and later. Select the BOTH option. This configures the OpenVMS TDF F settings, though it may or may not configure the TDF and the timezone H rules needed or used by other software packages. Please do NOT directly ( invoke the following command procedures:
F TCP/IP Services V5.0 and later use the OpenVMS TDF, UTC, and timezone D support. Earlier versions use a TDF mechanism and timezone database E that is internal to the TCP/IP Services package. Also on the earlier F versions, the TDF must be manually configured within TCP/IP Services, 4 in addition to the OpenVMS configuration of the TDF.
F DECnet-Plus in V7.3 and later uses the OpenVMS TDF, UTC, and timezone E support, and displays its timezone prompts using UTC$TIME_SETUP.COM. A Earlier versions use a TDF TDF mechanism, timezone database, and H automatic switch-over that is internal to the DECnet-Plus package. Also G on earlier versions, the TDF must be configured within the DECnet-Plus E DECdtss package, in addition to the OpenVMS configuration of the TDF.
E Application code using HP C (formerly Compaq C, formerly DEC C) will F use the OpenVMS UTC and TDF mechanisms when the C code is compiled on A OpenVMS V7.0 and later (and when the macro _VMS_V6_SOURCE is NOT H defined). HP C does NOT use the OpenVMS UTC and TDF mechanisms when the C code is E compiled on OpenVMS releases prior to V7.0, or when the preprocessor ' declaration _VMS_V6_SOURCE is declared.
H In OpenVMS Alpha V6 releases (V6.1, V6.2, V6.2-1Hx, etc), the TDF value ! is written to SYS$BASE_IMAGE.EXE. G With OpenVMS Alpha V7.0 and later and with OpenVMS VAX V6.0 and later, SYS$SYSTEM:SYS$TIMEZONE.DAT E contains the TDF. This means that OpenVMS Alpha systems will need to 3 have the TDF value reset manually---usually within - SYSTARTUP_VMS.COM---on reboots prior to V7.0.
G During OpenVMS Bootstrap, the SYSINIT module reads SYS$TIMEZONE.DAT to E acquire the TDF for use in the system global cell EXE$GQ_TDF. This is E done to ensure that the system boots with a valid TDF (a value which H may be zero). The UTC system services get the TDF from this cell. These D 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 G configured and run, the image DTSS$SET_TIMEZONE.EXE is invoked and can override the 4 TDF and timezone rule settings from SYSINIT or from UTC$TIME_SETUP.COM--- G this 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.)
C Prior to OpenVMS V7.3, daylight savings time switchover is handled > automatically only when DCE DTS or DECnet-Plus DTSS is in use. C In V7.3, OpenVMS can be configured to automatically switch over to C daylight savings time, and also generates an event that interested E applications can use to detect the switch-over between standard time and daylight time.
F The manual switchover between daylight savings time and standard time C is correctly accomplished via the SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM command procedure procedure.
D NTP (alone) does NOT provide automatic switch-over. |
@ The DST switch-over does NOT drift the time value; the H switch-over applies the entire difference as a unit, as is standard and expected practice. |
F If you switch the TDF or daylight savings time setting, you will also F want to restart or reconfigure any time-sensitive applications (those G not using the time differential factor (TDF) change event available in D V7.3 and later). Examples of these applications include the need to G restart the NFS client and (yes) NTP. (NTP will want to try to "drift" h the time (see Section 4.2), and will find the daylight savings time H switch-over to be far too large to "drift". Hence the NTP restart.) You @ can also use the (undocumented) TCP/IP Services (prior to V5.0) commands:
|
" 1 SET TIME/DIFF=[positive or negative TDF integer] GENERATE TIME |
/ to reset the value of the logical name UCX$TDF.
Prior to V7.3, the command:
|
" * $ SETTZ :== $SYS$SYSTEM:DTSS$SET_TIMEZONE $ SETTZ MODIFY |
H can be used to modify the settings of the SYS$TIMEZONE_DAYLIGHT_SAVING, F SYS$TIMEZONE_DIFFERENTIAL, and SYS$TIMEZONE_NAME system logical names based on the SYS$TIMEZONE_RULE.
D The following are other TDF-related logical names used/available on E OpenVMS 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)' |
G One issue with the UTC implementation on OpenVMS is the behaviour of C D functions and other programs that use SYS$TIMEZONE_RULE; the OpenVMS F mechanism assumes all control over the timezone and the daylight time E switchover. This allows calculation of the time by the C library and various applications.
D This can be incompatible with a system or application that requires D manual modifications to the DST or TDF settings. For such a site to H ensure the timekeeping is correct, the site must provide procedure that F sets the local time and the TDF when the SYS$TIMEZONE_RULE says to do it.
G If a site requires a non-standard time switch-over, as in coordinating B with a shift change, the site will need to use the ZIC utility to create a custom timezone rule.
E Additionally, applications may need to have special actions taken or @ actions queued just before the time change takes effect. If the E application source code is available, one of the best ways to handle F this is via the TDF and time-change notification events available via the OpenVMS sys$set_system_event system service.
D For information on ZIC and related tools used to manage the OpenVMS C Timezone database, please see the DEC C Run-time Library Utilities @ Reference Manual---though the title would imply otherwise, this D particular manual is part of the OpenVMS documentation set, and not G part of the HP C (formerly Compaq C, formerly DEC C) documentation set. O 4.3.1 How to troubleshoot TDF problems on OpenVMS?
E This is an OpenVMS Alpha system prior to V7.0 and the startup is not invoking the procedure:
|
" SYS$MANAGER:UTC$TIME_SETUP.COM |
G This is an OpenVMS system prior to V6.0, where there is no OpenVMS TDF nor UTC available.
B The version of the application does not use the OpenVMS TDF. This F includes TCP/IP Services prior to V5.0, applications using HP C built = on or targeting OpenVMS prior to V7.0, and systems using the A DECnet-Plus DTSS mechanisms prior to the release associated with OpenVMS V7.3. (DCE TDF TBD.)
@ If you should find either of the following two timezone-related 0 database files located in SYS$SPECIFIC:[SYSEXE]:
F These two files are in an erroneous location and must be recreated in the correct directory:
|
" SYS$COMMON:[SYSEXE] |
If the DCL command:
|
" ) $ DIRECTORY SYS$SYSTEM:SYS$TIMEZONE*.DAT |
E shows these files in SYS$SPECIFIC:[SYSEXE], then delete them and use 0 SYS$MANAGER:UTC$TIME_SETUP.COM to recreate them.
/ On OpenVMS versions prior to V7.3, if the file:
|
" # $ SYS$STARTUP:DTSS$UTC_STARTUP.COM |
7 is present on your system, then you may need to invoke:
|
" - $ @SYS$UPDATE:DTSS$INSTALL_TIMEZONE_RULE.COM |
> to recreate the timezone files correctly. Invoke this command @ immediately after [re]executing SYS$MANAGER:UTC$TIME_SETUP.COM.)
D If SYS$UPDATE:DTSS$INSTALL_TIMEZONE_RULE.COM is not present on your < system, then you may need to execute the following commands:
|
" * $ DELETE SYS$STARTUP:DTSS$UTC_STARTUP.COM * $ DEASSIGN/SYSTEM/EXEC SYS$TIMEZONE_RULE. |
C If your system time is being reported as being off by one hour (or f whatever the local DST change), please see sections Section 4.6, j Section 4.3 and Section 10.22.1. L 4.3.2 Customizing your TDF (Timezone) Setting?
G Individual, local, and regional differences on the use (or the lack of 5 use) of Daylight Savings Time (DST) are quite common.
F If you need to add (or remove) daylight savings time for your area or H otherwise alter the rules for your local area, you will probably end up 2 creating a variation to an existing timezone rule.
D The necessary zone line to add for WhereEverLand will probably look something like this:
|
" @ # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] : Zone WhereEver 2:00 - WhereEver |
4 The OpenVMS source file for the timezone rules here:
|
" ) SYS$COMMON:[SYS$ZONEINFO.SYSTEM.SOURCES] |
C You'll then want to ZIC this to create your own timezone definiton.
@ ZIC is documented in the OpenVMS Documentation Set, in the HP C G Run-Time Library Reference Manual. (Despite the name of the manual, it @ is part of the OpenVMS documentation set and not the C manuals.)
F Once you have created the new rule, use SYS$MANAGER:UTC$TIME_SETUP.COM H to select the new timezone---with V7.3 and later, this tool will notice F the new timezone and will offer it, on earlier releases, you may/will F have to hack the tool somewhat. (Don't even think of trying to define the TZ G logical name (found on older configurations), or the SYS$TIMEZONE_NAME logical name, H or any other time- or timezone-related logical names directly yourself.)
H For various timezone rules, see the tar.gz files (these are gzipped tar archives) available at:
E If you try to set the system time with the SET TIME command, and see one of the following messages:
|
" $ %SET-E-NOTSET, error modifying time 1 -SYSTEM-F-IVSSRQ, invalid system service request $ %SET-E-NOTSET, error modifying time \ -SYSTEM-E-TIMENOTSET, time service enabled; enter a time service command to update the time |
D This occurs if the time on the local system is controlled by a time D service software, for example the distributed time service software B (DTSS) provided as part of the DECnet-Plus installation. The DTSS B software communicates with one or more time servers to obtain the > current time. It entirely controls the local system time (for ; DECnet-Plus, there is a process named DTSS$CLERK for this); A therefore, the usage of the SET TIME command (and the underlying $ $SETTIM system service) is disabled.
G The first message is displayed on systems running DECnet-Plus V6.1 and E earlier. On systems with newer DECnet-Plus software, the second (and # more informative) message is given.
E You shouldn't have to change the time manually - you should be doing C this through the time server - but if you insist... you'll have to shutdown DTSS:
|
" $ RUN SYS$SYSTEM:NCL DISABLE DTSS DELETE DTSS |
F This will shutdown DTSS$CLERK. You may then change the system time as ) usual. To restart the DTSS software, type
|
" $ @SYS$STARTUP:DTSS$STARTUP |
D You will need a number of privileges to ussue this command, and you A must also be granted the NET$MANAGE identifer to shutdown and to restart DTSS.
H If you wish to "permanently" disable DTSS on a system running D DECnet-Plus, the above NCL sequence must be performed each time the G system is bootstrapped. (On DECnet-Plus V7.3 and later, you can define ! the logical name NET$DISABLE_DTSS G to disable the DTSS startup. This logical name must be defined in the " command procedure SYLOGICALS.COM, H as this logical name must be present and defined sufficiently early in ; the OpenVMS system bootstrap sequence for it to function.)
D If DTSS is running and no time servers are configured, you can (and 6 will) see the following messages at regular intervals:
|
" 9 %%%%%%%%%%% OPCOM 2-SEP-1999 19:41:20.29 %%%%%%%%%%% # Message from user SYSTEM on UNHEDI ? Event: Too Few Servers Detected from: Node LOCAL:.mynode DTSS, . at: 1999-09-02-19:41:20.296-04:00Iinf Number Detected=0, Number Required=1 8 eventUid 5FA70F4F-616E-11D3-A80E-08002BBEDB0F 8 entityUid DE9E97DE-6135-11D3-8004-AA000400BD1B 8 streamUid D6513A46-6135-11D3-8003-AA000400BD1B |
H You can either configure the appropriate number of time servers, or you H can disable DTSS, or you can ignore it and (if OPCOM is set to write to % the log via via the logical names in E SYLOGICALS.COM/SYLOGICALS.TEMPLATE) clean out OPERATOR.LOG regularly.
: You can also simply disable the display of these messages:
|
" $ run sys$system:ncl D block event dispatcher outbound stream local_stream global filter - - ((Node, DTSS), Too Few Servers Detected) |
A If you wish to disable the automatic TDF adjustment for daylight B savings time (on OpenVMS versions prior to V7.3), you can use the command:
|
" $ run sys$system:ncl & set dtss automatic TDF change = false |
F or alternatively, you can set the local timezone to one that does not 8 include the automatic daylight savings time change-over.
= OpenVMS V7.3 and later simplify time and timezone management.
| Previous | YNext | \Contents | ^Index |