| Previous | Contents | Index |
The United States Federal Government is presently expecting to change its DST rules starting in March, 2007. (The change-over date and the planned change itself has not come to pass as of this writing, hence the phrasing used.)
As amended, US daylight time will be increased to be effective from the second Sunday in March through the first Sunday of November. Other countries, US local political geographies and businesses may or may not follow suite and implement these changes, obviously.
For further regulatory details, see the US Uniform Time Act of 1966 (15 U.S.C 260a(a)), as amended by the Energy Policy Act of 2005.
For details on how to create, customize or to download new rules and to
update your local timezone rules, please see Section 4.4.1.1.
4.4.2 Timezones and Time-related Logical Names?
Various logical names are used to manage time and timezones, and you should avoid direct modification of these logical names as the implementations are subtle and quick to change. As discussed in section Section 4.4.3, you will want to use the following command procedure to maintain the time and the timezone:
If you want to venture into uncharted territories and modify the TDF used within older releases of TCP/IP Services---within releases prior V5.0---you can attempt to use the following undocumented commands:
SET TIME/DIFF=[positive or negative TDF integer] GENERATE TIME |
to reset the value of the logical name UCX$TDF.
Prior to OpenVMS V7.3, the command:
$ SETTZ :== $SYS$SYSTEM:DTSS$SET_TIMEZONE $ SETTZ MODIFY |
can be used to modify the settings of the SYS$TIMEZONE_DAYLIGHT_SAVING, SYS$TIMEZONE_DIFFERENTIAL, and SYS$TIMEZONE_NAME system logical names based on the SYS$TIMEZONE_RULE.
The following are other TDF-related logical names used/available on OpenVMS systems, with typical daylight time and standard time settings for the US Eastern Time (ET) timezone.
$daylight_time:
$ DEFINE/SYSTEM/EXECUTIVE MAIL$TIMEZONE EDT
$ DEFINE/SYSTEM/EXECUTIVE NOTES$TIMEZONE "-0400 EDT"
$ DEFINE/SYSTEM/EXECUTIVE LISP$DAYLIGHT_SAVING_TIME_P true ! Not 'EDT'
$ DEFINE/SYSTEM/EXECUTIVE LISP$TIME_ZONE 05 ! Constant
$
$standard_time:
$ DEFINE/SYSTEM/EXECUTIVE MAIL$TIMEZONE EST
$ DEFINE/SYSTEM/EXECUTIVE NOTES$TIMEZONE "-0500 EST"
$ DEFINE/SYSTEM/EXECUTIVE LISP$DAYLIGHT_SAVING_TIME_P false ! Not 'EST'
$ DEFINE/SYSTEM/EXECUTIVE LISP$TIME_ZONE 05 ! Constant
$
$ DEFINE/SYSTEM/EXECUTIVE UCX$NFS_TIME_DIFFERENTIAL -
'f$integer(f$element(0," ",f$logical("notes$timezone"))/-100)'
|
For information on modifying these timezone logical names and on
managing the timezone rules, see Section 4.4.1.
4.4.3 How to troubleshoot TDF problems on OpenVMS?
This is an OpenVMS Alpha system prior to V7.0 and the startup is not invoking the procedure:
SYS$MANAGER:UTC$TIME_SETUP.COM |
This is an OpenVMS system prior to V6.0, where there is no OpenVMS TDF nor UTC available.
The version of the application does not use the OpenVMS TDF. This 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 DECnet-Plus DTSS mechanisms prior to the release associated with OpenVMS V7.3. (DCE DTS TDF management details to be determined.)
If you should find either of the following two timezone-related database files located in SYS$SPECIFIC:[SYSEXE]:
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 |
shows these files in SYS$SPECIFIC:[SYSEXE], then delete them and use 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 |
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.)
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. |
If your system time is being reported as being off by one hour (or
whatever the local DST change), please see sections Section 4.7,
Section 4.4 and Section 10.22.1.
4.5 Why does the SET TIME command fail? Help managing DTSS?
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 -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 |
This occurs if the time on the local system is controlled by a time service software, for example the distributed time service software (DTSS) provided as part of the DECnet-Plus installation. The DTSS 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); therefore, the usage of the SET TIME command (and the underlying $SETTIM system service) is disabled.
The first message is displayed on systems running DECnet-Plus V6.1 and earlier. On systems with newer DECnet-Plus software, the second (and more informative) message is given.
You shouldn't have to change the time manually - you should be doing this through the time server - but if you insist... you'll have to shutdown DTSS:
$ RUN SYS$SYSTEM:NCL DISABLE DTSS DELETE DTSS |
This will shutdown DTSS$CLERK. You may then change the system time as usual. To restart the DTSS software, type
$ @SYS$STARTUP:DTSS$STARTUP |
You will need a number of privileges to issue this command, and you must also be granted the NET$MANAGE identifer to shutdown and to restart DTSS.
If you wish to "permanently" disable DTSS on a system running DECnet-Plus, the above NCL sequence must be performed each time the system is bootstrapped. (On DECnet-Plus V7.3 and later, you can define the logical name NET$DISABLE_DTSS to disable the DTSS startup. This logical name must be defined in the command procedure SYLOGICALS.COM, as this logical name must be present and defined sufficiently early in the OpenVMS system bootstrap sequence for it to function.)
If DTSS is running and no time servers are configured, you can (and will) see the following messages at regular intervals:
%%%%%%%%%%% 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
eventUid 5FA70F4F-616E-11D3-A80E-08002BBEDB0F
entityUid DE9E97DE-6135-11D3-8004-AA000400BD1B
streamUid D6513A46-6135-11D3-8003-AA000400BD1B
|
You can either configure the appropriate number of time servers, or you can disable DTSS, or you can ignore it and (if OPCOM is set to write to the log via via the logical names in SYLOGICALS.COM/SYLOGICALS.TEMPLATE) clean out OPERATOR.LOG regularly.
You can also simply disable the display of these messages:
$ run sys$system:ncl
block event dispatcher outbound stream local_stream -
global filter -
((Node, DTSS), Too Few Servers Detected)
|
If you wish to disable the automatic TDF adjustment for the daylight time switch-over (on OpenVMS versions prior to V7.3), you can use the command:
$ run sys$system:ncl set dtss automatic TDF change = false |
or alternatively, you can set the local timezone to one that does not include the automatic daylight time change-over.
OpenVMS V7.3 and later simplify time and timezone management.
4.6 Setting time on AlphaServer ES47, ES80, GS1280 console?
To set the base system time on an member of the AlphaServer ES47, AlphaServer ES80 or AlphaServer GS1280 series system family, you must access the Platform Management Utility (PMU). The PMU is implemented within this family of related AlphaServer systems, and is part of a layer providing services beyond those of the traditional Alpha SRM console layer, and within a layer architecturally implemented beneath the SRM console. In particular, the PMU and related management components are used to provide services across multiple vPars or nPars partitions. In particular, the SRM obtains and manages the local system time on these systems as a delta time offset from the underlying base system time. Neither the SRM console nor OpenVMS directly accesses nor alters the underlying base system time nor other information maintained within the PMU layer.
The PMU uses the System Management components, centrally including the Backplane Manager (MBM) module found in each drawer, user interface, PCI and CPU management components, and the interconnections among these provided by the private system management LAN. When the system has power applied and the main breakers are on, the MBMs are active.
The PMU offers a command line interface for a serial communications or telnet connection and allows command and control of the MBM, and of the server. The PMU and the MBM system management components are responsible for the following tasks:
You can use the MBM commands SHOW TIME and SET TIME to view and to manipulate the base system time. The delta time value for the primary MBM will be indicated, and it is this value in conjunction with the base time that is used to generate the time available to OpenVMS via the SRM console. If you issue a SET TIME=time command from OpenVMS, the delta time will change, but not the MBM base system time. If you change the MBM base system time, the calculated time available to OpenVMS via the SRM console(s) will change. (Resetting the base time thus involves changing the base system time, and then issuing SET TIME=time command(s) to each of the OpenVMS vPars or nPars environments to adjust the respective delta time values.) Rebooting, resetting or issuing an MBM SET TIME will reset the system time.
Typically, you will want to establish the MBM time value once, and probably setting it to UTC or such, and you will then want to boot each partition conversationally, setting the SETTIME system parameter to force the entry of the time within each booting system environment. Once the MBM time value has been set once, you will typically not want to alter it again. You will typically want to manage and modify only the time values within each partition.
The time and data values stored in the primary MBM and replicated in the zero or more secondary MBMs that might be present within the system are coordinated.
To enter the PMU from the SRM console, and to exit back to SRM:
MBM - (PMU, Platform Management Utility)
From SRM P00> enter {Esc} {Esc} MBM
CTRL/[ CTRL/[ MBM (MBM must be uppercase)
MBM> connect (to exit to SRM)
|
The [CTRL/][ is the escape character. Use the cited key sequences to enter the PMU. You can also access the PMU through a modem, or from a terminal or terminal emulator or terminal server connected to the server management LAN. Having the server management LAN bridged to an untrusted LAN can be unwise, however, and with risks analogous to those of configuring a traditional VAX or Alpha console serial line to an open terminal server or to a dial-in modem.
See the AlphaServer GS1280 documentation for additional information.
4.7 UTC vs GMT vs vs UT1/UT1/UT2 TDF? What are these acronyms?
The results of an international compromise---though some would say an international attempt to increase confusion---UTC is refered to as "Coordinated Universal Time" (though not as CUT) in English and as "Temps Universel Coordinné" (though not as TUC) in French. (No particular information exists to explain why UTC was chosen over the equally nonsensical TCU, according to Ulysses T. Clockmeister, one of the diplomats that helped establish the international compromise.)
Universal Time UT0 is solar time, UT1 is solar time corrected for a wobble in the Earth's orbit, and UT2 is UT1 corrected for seasonal rotational variations in rotation due to the Earth's solar orbit.
GMT---Greenwich Mean Time---is UT1. GMT is the time at the classic site of the since-disbanded Royal Greenwich Observatory; at the most widely-known tourist attraction of Greenwich, England.
UTC is based on an average across multiple atomic clocks, and is kept within 0.9 seconds of GMT, through the insertion (or removal) of seconds. In other words, UTC matches GMT plus or minus up to 0.9 seconds, but UTC is not GMT.
TDF is the Timezone Differential Factor, the interval of time between the local time and UTC. Areas that celebrate daylight saving time (DST) will see periodic changes to the TDF value, when the switch-over between daylight time and standard time occurs. The switch-over itself is entirely left to local governmental folks, and can and has varied by political entity and politics, and the switch-over has varied over the years even at the same location.
If your local OpenVMS system time is off by one hour (or whatever the local 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.22.1.)
Further discussions of history and politics, the Royal Observers' outbuildings, and the compromise that left the English with the Time Standard (the Prime Meridian) and the French with the standards for Distance and Weight (the Metric System) are left to other sources. Some of these other sources include the following URLs:
No standards-compliant NTP or SNTP server is reportedly capable of synchronizing with the Microsoft Windows w32time services.
Further, NTP clients are not generally capable of synchronizing with an SNTP server.
Open Source (Free) NTP servers (qv: OpenNTP) are available for Microsoft Windows platforms, and TCP/IP Services and third-party packages all provide NTP servers for OpenVMS, and NTP and SNTP clients can synchronize with these srvers.
| Previous | Next | Contents | Index |