The OpenVMS Frequently Asked Questions (FAQ)

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.

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:

SYS$MANAGER:UTC$TIME_SETUP.COM

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.

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]:

SYS$SPECIFIC:[SYSEXE]SYS$TIMEZONE.DAT

SYS$SPECIFIC:[SYSEXE]SYS$TIMEZONE_SRC.DAT

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:

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:

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.

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:

Show the system configuration and provide the basic debugging
capability

Initiate the firmware update or load the test firmware version

Power on or off, halt, or reset the system or partition

The system partitioning and cabling functions

Displays of the health of hardware environment, including such
constructs as fans, power supplies and environmental and temperature
values.

Remote server management tasks

The connection to the virtual SRM console

Set and show the base system time.

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.

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.

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.