|
HP OpenVMS Systems Documentation |
|
The OpenVMS Frequently Asked Questions (FAQ)
4.4.1 Creating, Updating and Managing Timezone Definitions?One issue with the UTC implementation on OpenVMS is the behaviour of C functions and other programs that use SYS$TIMEZONE_RULE; the OpenVMS mechanism assumes all control over the timezone and the daylight time switchover. This allows calculation of the time by the C library and various applications. This can be incompatible with a system or application that requires manual modifications to the DST or TDF settings, or that requires a local or customized timezone definition. For such a site to ensure the timekeeping is correct, the site must provide procedure that sets the local time and the TDF when the SYS$TIMEZONE_RULE says to do it. If a site requires a non-standard time switch-over, as in coordinating with a shift change or due to changes in the local or regional timezone rules, the site will need to use the zic compiler to create a custom timezone rule. Additionally, applications may need to have special actions taken or actions queued just before the time change takes effect. If the application source code is available, one of the best ways to handle this is via the TDF and time-change notification events available via the OpenVMS sys$set_system_event system service. For information on zic and related tools used to manage the OpenVMS Timezone database, please see the HP C Run-time Library Utilities Reference Manual---though the title would imply otherwise, this particular manual is part of the OpenVMS documentation set, and not part of the HP C (formerly Compaq C, formerly DEC C) documentation set.
For related information, see Section 4.4.1.1.
Individual, local, and regional differences on the use (or the lack of use) of Daylight Saving Time (DST) are quite common, as are occasional regulatory changes to the particular applicable regional DST settings. (eg: The United States Government is expecting to change its DST rules starting 1-Mar-2007; please see Section 4.4.1.2 for details.) If you need to add, modify or remove DST rules for your area, or otherwise alter the rules for your local area, you will probably end up creating a variation to an existing timezone rule, or potentially simply downloading a new set of DST rules. This requirement can arise, for instance, if your local region changes its timezone rules. The necessary zone line to add for support of the hypothetical new WhereEverLand timezone will probably look something like this:
The OpenVMS source files for the timezone rules are stored here:
You'll then want to use the zic compiler to compile your own new timezone definition, or to compile a new set of timezone definitions that have been freshly downloaded from a published source. The zic compiler is documented in the OpenVMS Documentation Set, and specifically in the HP C Run-Time Library Reference Manual. (Despite the name of this manual, it is part of the OpenVMS documentation set and not of the C manuals.) Once you have created and compiled a new timezone rule (or have downloaded and have compiled a whole new set of timezone rules), use the SYS$MANAGER:UTC$TIME_SETUP.COM to select the new timezone if necessary---with V7.3 and later, this tool will automically notice the new timezone and will offer it, on earlier releases, you may/will have to hack the code of the tool somewhat to allow it to present the new timezone rule. (If an existing timezone rule is simply changing, you don't need this re-selection step.)
For various published timezone rules or updated to same, see the tar.gz files (these are gzipped tar archives) available at:
These are gzipped tar archives, and are the pubished source used for the OpenVMS timezone rules on OpenVMS V7.3 and later, and within the predecessor C run-time environment timezone support used on older OpenVMS releases. You'll need to first gunzip and then use vmstar to unpack and access the contents of the archives. The published timezone rules include the effective date ranges for the individual rules, so you can reload your rules prior to a particular set of new rules becoming effective. The effective dates for the particular timezone rules are additionally necessary to allow the appropriate translation of older dates and times within the appropriate historical context of the particular date and time value.
For related information, see Section 4.4.1.
The United States Federal Government is presently expecting to change its DST rules starting with 1-Mar-2007. As amended, US daylight time will be increased to run from the second Sunday in March through the first Sunday of October, inclusive. 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.
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:
to reset the value of the logical name UCX$TDF. Prior to OpenVMS V7.3, the command:
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.
For information on modifying these timezone logical names and on
managing the timezone rules, see Section 4.4.1.
This is an OpenVMS Alpha system prior to V7.0 and the startup is not invoking the procedure:
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:
If the DCL command:
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:
is present on your system, then you may need to invoke:
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:
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.
If you try to set the system time with the SET TIME command, and see one of the following messages:
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:
This will shutdown DTSS$CLERK. You may then change the system time as usual. To restart the DTSS software, type
You will need a number of privileges to ussue 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:
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:
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:
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.
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:
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.
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:
|