|
See reader questions & answers on this topic! - Help others by sharing your knowledge
Archive-name: dec-faq/vms/part3
Posting-Frequency: quarterly
Last-modified: 02 Sep 2005
Version: VMSFAQ_20050902-03.TXT
Documentation
________________________________________________________________
Table 3-2 (Cont.) OpenVMS Tutorial and Documentation Websites
_______________________________________________________
URL_______Sponsor______________________________________
An OpenVMS Quiz
http://www.CCSScorp.com/
CCSS Interactive Learning has OpenVMS
training materials
http://www.acersoft.com/
AcerSoft Training information, and Shannon
Knows Punditry
http://www.mindiq.com/
MindIQ training information
http://www.quadratrix.be/
Quadratrix; OpenVMS training, products and
services; affiliated with Global Knowledge
___________________and_KeyJob___________________________________
_____________________________
3.6.2 Books and Tutorials?
Some of the OpenVMS books that are or have been
available from the Digital Press imprint
o http://www.bh.com/
are listed in Table 3-3:
________________________________________________________________
Table 3-3 DP Books
________________________________________________________________
Title_and_Author_____________________ISBN_______________________
Getting Started with OpenVMS System 1-55558-243-5
Management, 2nd Edition
David Donald Miller, et al
Introduction to OpenVMS, 5th 1-55558-194-3
Edition
Lesley Ogilvie Rice
3-8
Documentation
________________________________________________________________
Table 3-3 (Cont.) DP Books
________________________________________________________________
Title_and_Author_____________________ISBN_______________________
Introduction to OpenVMS 1-878956-61-2
David W Bynon
OpenVMS Alpha Internals: Scheduling 1-55558-156-0
and Process Control
OpenVMS AXP Internals and Data 1-55558-120-X
Structures: Version 1.5
OpenVMS System Management Guide 1-55558-143-9
Baldwin, et al
The OpenVMS User's Guide, Second 1-55558-203-6
Edition
Patrick Holmay
Using DECwindows Motif for OpenVMS 1-55558-114-5
Margie Sherlock
VAX/VMS Internals and Data 1-55558-059-9
Structures: Version 5.2
Writing Real Programs in DCL, 1-55558-191-9
Second Edition
Hoffman and Anagnostopoulos
Writing OpenVMS Alpha Device 1-55558-133-1
Drivers in C
Sherlock_and_Szubowicz__________________________________________
For various featured OpenVMS books, also please see the
books link at the OpenVMS website:
o http://www.hp.com/go/openvms
For a bibliography of various OpenVMS books, please
see:
o http://www.levitte.org/~ava/vms_book.htmlx
3-9
Documentation
__________________________________________________________
3.7 What OpenVMS mailing lists are available?
Various OpenVMS mailing lists are available, with some
of the available lists detailed in Table 3-4.
________________________________________________________________
Table 3-4 OpenVMS Mailing Lists
________________________________________________________________
Subscription____________________Interest_Area___________________
OpenVMS Freeware archive FSupdate@goatley.com
announcement list FSupdate-request@goatley.com[1]
Two-way echo of VMSnet-Internals@goatley.com
vmsnet.internals VMSnet-Internals-
request@goatley.com[1]
OpenVMS Alpha Internals Alpha-IDS@goatley.com
discussions Alpha-IDS-request@goatley.com[1]
BLISS discussions BLISSters@goatley.com
BLISSters-request@goatley.com[1]
Process Software MultiNet Info-MultiNet@process.com
mailing list (news gateway) Info-MultiNet-
request@process.com[1]
Process Software TCPware Info-TCPware@process.com
mailing list (news gateway) Info-TCPware-
request@process.com[1]
Process Software PMDF mailing Info-PMDF@process.com
list (news gateway) Info-PMDF-request@process.com[1]
The Software Resources CHARON-VAX-Users@process.com
International (SRI) CHARON-VAX CHARON-VAX-Users-
VAX emulator package request@process.com[1]
Info-Zip's Zip & UnZip Info-Zip@wku.edu
discussion list Info-Zip-Request@wku.edu[1]
RADIUS-VMS, a RADIUS server radius-vms@dls.net
for OpenVMS discussion forum radius-vms-request@dls.net[1]
Internet Service Providers vms-isps@dls.net
(ISPs) running OpenVMS vms-isps-request@dls.net[1]
________________________________________________________________
[1]This is the subscription address. Usually, you will want to
send a mail message with no subject line, and a SUBSCRIBE or
HELP command in the body of the mail message.
3-10
Documentation
________________________________________________________________
Table 3-4 (Cont.) OpenVMS Mailing Lists
________________________________________________________________
Subscription____________________Interest_Area___________________
Users of Mark Daniel's WASD http://wasd.vsm.com.au/
web server for OpenVMS VAX
and Alpha exists. Information
about this list server and
details on how to subscribe to
the list are available at the
referenced website.
VMS Forum http://www.neurophys.wisc.edu/comp/ava/vms_
________________________________forum.htmlx_____________________
__________________________________________________________
3.8 What is this Ask The Wizard website I've heard about?
The HP OpenVMS Ask The Wizard (ATW) website was an
informal area discussing OpenVMS, containing questions
and answers on a wide variety of topics.
o http://www.hp.com/go/openvms/wizard/
For additional information on the OpenVMS Ask The
Wizard (ATW) area and for a pointer to the available
ATW Wizard.zip archive, please see Section 3.8.
To access a cited topic directly, use the URL filename
WIZ_topic-number.HTML, or use the topic search engine.
Cited topics are shown in parentheses, and act as
unique topic addresses. These should not be confused
with the relative topic numbers shown at the site.
For example, the topic (1020) can be accessed directly
using the URL filename wiz_1020.html, at the web site
that the following URL resolves into:
o http://www.hp.com/go/openvms/wizard/
A zip archive (named wizard.zip) containing all of
the available topics and questions can be downloaded
from the above URL. The wizard.zip zip archive is
completely regenerated when/if existing topics posted
out to the ATW website are updated. Copies of this
wizard.zip archive also generally ship out on the
OpenVMS Freeware, as well.
3-11
Documentation
New (informal) questions and discussions are now being
directed away from the ATW area to the ITRC area, and
specifically to the ITRC discussion forums:
o http://www.itrc.hp.com/
__________________________________________________________
3.9 Where can I find the latest C run-time library manuals?
The C run-time library (RTL) reference documentation
has been moved from the C language documentation set
to the OpenVMS documentation set. For the most recent
version of the C RTL documentation and the OpenVMS
standard C library, please see the OpenVMS manuals.
In addition to the user-mode C RTL, there is a second
kernel-mode RTL accessable to drivers on OpenVMS Alpha
and OpenVMS I64. For details on this second library and
on the duplicate symbol errors that can be triggered
when this library is referenced during an incorrectly-
specified LINK command, please see Section 10.22.1.
For general information on this kernel RTL, see the
Digital Press book Writing OpenVMS Device Drivers in C.
For details, please see the associated OpenVMS source
listings distribution.
o http://www.hp.com/go/openvms/doc/
3-12
_______________________________________________________
4 Time and Timekeeping
This chapter discusses time, timekeeping, system
time synchronization, clock skew and clock drift,
implications of using SUBMIT/AFTER=TOMORROW, and other
time-related topics.
__________________________________________________________
4.1 A brief history of OpenVMS Timekeeping, please?
Why does OpenVMS regards November 17, 1858 as the
beginning of time...
The modified Julian date adopted by the Smithsonian
Astrophysical Observatory (SAO) for satellite tracking
is Julian Day 2400000.5, which turns out to be midnight
on November 17, 1858.
SAO started tracking satellites with an 8K (nonvirtual)
36-bit IBM 704 in 1957 when Sputnik went into orbit.
The Julian day was 2435839 on January 1, 1957. This is
11225377 octal, which was too big to fit into an 18-bit
field. With only 8K of memory, the 14 bits left over by
keeping the Julian date in its own 36-bit word would
have been wasted. SAO also needed the fraction of the
current day (for which 18 bits gave enough accuracy),
so it was decided to keep the number of days in the
left 18 bits and the fraction of a day in the right 18
bits of one word.
Eighteen bits allows the truncated Julian Day (the SAO
day) to grow as large as 262143, which from November
17, 1858, allowed for 7 centuries. Possibly, the date
could only grow as large as 131071 (using 17 bits),
but this still covers 3 centuries and leaves the
possibility of representing negative time. The 1858
date preceded the oldest star catalogue in use at SAO,
which also avoided having to use negative time in any
of the satellite tracking calculations.
4-1
Time and Timekeeping
The original Julian Day (JD) is used by astronomers and
expressed in days since noon January 1, 4713 B.C. This
measure of time was introduced by Joseph Scaliger in
the 16th century. It is named in honor of his father,
Julius Caesar Scaliger (note that this Julian Day is
different from the Julian calendar that is named for
the Roman Emperor Julius Caesar!).
Why 4713 BC? Scaliger traced three time cycles and
found that they were all in the first year of their
cyle in 4713 B.C. The three cycles are 15, 19, and 28
years long. By multiplying these three numbers (15 * 19
* 28 = 7980), he was able to represent any date from
4713 B.C. through 3267 A.D.
The starting year was before any historical event known
to him. In fact, the Jewish calendar marks the start
of the world as 3761 B.C. Today his numbering scheme
is still used by astronomers to avoid the difficulties
of converting the months of different calendars in use
during different eras.
The following web sites:
o http://www.openvms.compaq.com/openvms/products/year-
2000/leap.html
o http://www.eecis.udel.edu/~ntp/
o http://www.nist.gov/
o http://www.boulder.nist.gov/timefreq/
o http://www.tondering.dk/claus/calendar.html
o http://es.rice.edu/ES/humsoc/Galileo/Things/gregorian_
calendar.html
are all good time-related resources, some general and
some specific to OpenVMS.
_____________________________
4.1.1 Details of the OpenVMS system time-keeping?
4-2
Time and Timekeeping
_____________________________
4.1.1.1__VAX_hardware_time-keeping details...
4.1.1.1.1 TOY clock
This is battery backed up hardware timing circuitry
used to keep the correct time of year during rebooting,
power failures, and system shutdown. This clock only
keeps track of months, days, and time. The time is kept
relative to January 1st, at 00:00:00.00 of the year the
clock was initiailized.
The VAX Time-Of-Year (TOY) clock (used to save the time
over a reboot or power failure) is specified as having
an accuracy of 0.0025%. This is a drift of roughly 65
seconds per month.
The VAX Interval Time is used to keep the running time,
and this has a specified accuracy of .01%. This is a
drift of approximately 8.64 seconds per day.
Any high-IPL activity can interfere with the IPL 22
or IPL 24 (this depends on the VAX implementation)
clock interrupts-activities such as extensive device
driver interrupts or memory errors are known to slow
the clock.
_____________________________
4.1.1.1.2 EXE$GQ_SYSTIME
This is the OpenVMS VAX system time cell. This cell
contains the number of 100ns intervals since a known
reference. This cell is incremented by 100000 every
_________10ms_by_an_hardware_interval timer.
4.1.1.1.3 EXE$GQ_TODCBASE
This cell contains the time and date the system time
was last adjusted by EXE$SETTIME. It uses the same
format as EXE$GQ_SYSTIME. On adjustment of the system
time a copy of EXE$GQ_SYSTIME is stored in this cell in
both memory and on disk. This cell is used to get the
year for the system time.
4-3
Time and Timekeeping
_____________________________
4.1.1.1.4 EXE$GL_TODR
This cell contains the time and date the system time
was last adjusted by EXE$SETTIME. It uses the same
format as the time of year clock. On adjustment of the
system time this cell gets saved back to both memory
and disk. The contents of this cell are used to test
the validity of the TOY clock.
The system parameters SETTIME and TIMEPROMPTWAIT
determine how the system time will be set.
o IF SETTIME = 0 and the TOY clock is valid
THEN the contents of the TOY clock are compared to
those of EXE$GL_TODR. IF the TOY clock is more than
a day behind EXE$GL_TODR
THEN the TOY clock is presumed invalid.
o IF the TOY clock is within a day of EXE$GL_TODR
THEN the system time is calculated as follows:
o EXE$GQ_SYSTIME = EXE$GQ_TODCBASE + ((TOY_CLOCK -
EXE$GL_TODR) * 100000)
o IF SETTIME = 1 or the TOY clock is invalid
THEN the value of TIMEPROMPTWAIT determines how to
reset the time of year. IF TIMEPROMPTWAIT > 0
THEN the user is prompted for the time and date,
for a length of time equal to TIMEPROMPTWAIT
microfortnights.
o IF TIMEPROMPTWAIT = 0
THEN the time of year is the value of EXE$GL_TODR
+ 10ms.
o IF TIMEPROMPTWAIT < 0
to proceed until they do so.
o THEN the user is prompted for the time and date
and unable
When booting a CD-ROM containing an OpenVMS VAX system,
the system will typically be deliberately configured
prompt the user to input the time - this is necessary
in order to boot with the correct time.
4-4
Time and Timekeeping
If either TIMEPROMPTWAIT or SETTIME are set to zero,
OpenVMS VAX will use the TOY clock to get the time
of year, and the year will be fetched from the
distribution medium. The value of the year on the
distribution medium (saved within the SYS.EXE image)
will most likely be that of when the kit was mastered,
and cannot be changed. Unless the current year happens
to be the same year as that on the distribution, most
likely the year will be incorrect. (Further, with the
calculation of Leap Year also being dependent on the
current year, there is a possibility that the date
could be incorrect, as well.)
_____________________________
4.1.1.2__Alpha_hardware_time-keeping details...
4.1.1.2.1 Battery-Backed Watch (BB_WATCH) Chip
This is battery backed up hardware timing circuitry
used to keep the correct time of year during rebooting,
power failures, and system shutdown. This clock keeps
track of date and time in 24 hour binary format.
The BB_WATCH time is used to initialize the running
system time during bootstrap, and the BB_WATCH time
is read when the SET TIME command is issued with no
parameters; when the running system time is reset to
the value stored in the BB_WATCH. The running system
time is written into the BB_WATCH when the SET TIME
command is issued with a parameter.
The specification for maximum clock drift in the Alpha
hardware clock is 50 parts per million (ppm), that
is less than ±0.000050 seconds of drift per second,
less than ±0.000050 days of drift per day, or less
than ±0.000050 years of drift per year, etc. (eg: An
error of one second over a day-long interval is roughly
11ppm, or 1000000/(24*60*60).) Put another way, this
is .005%, which is around 130 seconds per month or 26
minutes per year.
The software-maintained system time can drift more than
this, primarily due to other system activity. Typical
causes of drift include extensive high-IPL code (soft
memory errors, heavy activity at device IPLs, etc) that
4-5
Time and Timekeeping
are causing the processing of the clock interrupts to
be blocked.
_____________________________
4.1.1.2.2 EXE$GQ_SYSTIME
This is the OpenVMS Alpha system time cell. This cell
contains the number of 100ns intervals since November
17, 1858 00:00:00.00. This cell is incremented by
_________100000_every_10ms_by an hardware interval timer.
4.1.1.2.3 EXE$GQ_SAVED_HWCLOCK
This cell is used by OpenVMS Alpha to keep track of the
last time and date that EXE$GQ_SYSTIME was adjusted. It
keeps the same time format as EXE$GQ_SYSTIME. The value
in this cell gets updated in memory and on disk, every
time EXE$GQ_SYSTIME gets adjusted.
o The system parameters SETTIME and TIMEPROMPTWAIT
determine how the system time will be set.
o If SETTIME = 0
then EXE$INIT_HWCLOCK reads the hardware clock to
set the system time.
o IF TIMEPROMPTWAIT > 0
THEN the value of TIMEPROMPTWAIT determines how
long the user is prompted to enter the time
and date. If time expires and no time has been
entered the system acts as if TIMEPROMPTWAIT = 0.
o IF TIMEPROMPTWAIT = 0
THEN the system time is calculated from the
contents of EXE$GQ_SAVED_HWCLOCK + 1.
o IF TIMEPROMPTWAIT < 0
THEN the user is prompted for the time and date
and unable to continue until the information is
entered.
Unlike the VAX, the Alpha hardware clock tracks the
full date and time, not just the time of year. This
means it is possible to boot from the CD-ROM media
without entering the time at the CD-ROM bootstrap.
(This provided that the time and date have been
initialized, of course.)
4-6
Time and Timekeeping
IA-64 (Itanium) hardware time-keeping details to be
added...
_____________________________
4.1.1.3 Why does VAX need a SET TIME at least once a year?
Because the VAX Time Of Year (TOY) has a resolution of
497 days, the VAX system time is stored using both the
TOY and the OpenVMS VAX system image SYS.EXE. Because
of the use of the combination of the TOY and SYS.EXE,
you need to issue a SET TIME command (with the time
parameter specified) at least once between January 1st
and about April 11th of each year, and whenever you
change system images (due to booting another OpenVMS
VAX system, booting the standalone BACKUP image, an ECO
that replaces SYS.EXE, etc).
The SET TIME command (with the current time as a
parameter) is automatically issued during various
standard OpenVMS procedures such as SHUTDOWN, and it
can also obviously be issued directly by a suitably
privileged user. Issuing the SET TIME command (with a
parameter) resets the value stored in the TOY, and (if
necessary) also updates the portion of the time (the
current year) saved in the SYS.EXE system image.
This VAX TOY limit is the reason why OpenVMS VAX
installation kits and standalone BACKUP explicitly
prompt for the time during bootstrap, and why the time
value can "get weird" if the system crashes outside the
497 day window (if no SET TIME was issued to update the
saved values), and why the time value can "get weird"
if a different SYS$SYSTEM:SYS.EXE is used (alternate
system disk, standalone BACKUP, etc).
_____________________________
4.1.2 How does OpenVMS VAX maintain system time?
VAX systems maintain an interval clock, and a hardware
clock.
The VAX hardware clock is called the TOY ("Time Of
Year") clock. The register associated with the clock is
called the TODR ("Time Of Day Register").
4-7
Time and Timekeeping
The 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-bit counter, incremented every 10ms,
and thus has a capacity of circa 497 days.
OpenVMS (on the VAX platform) stores system date
information-and in particular, the current year-in
the system image, SYS$SYSTEM:SYS.EXE.
The TOY is used, in conjunction with the base date
that is stored and retrieved from the system image, to
initialize the interval clock value that is stored in
EXE$GQ_SYSTIME.
Once the interval clock is loaded into the running
system as part of the system bootstrap, the system
does not typically reference the TOY again, unless a
SET TIME (with no parameters) is issued. The interval
clock value is updated by a periodic IPL22 or IPL24
(depending on the specific implementation) interrupt.
(When these interrupts are blocked as a result of the
activity of higher-IPL code-such as extensive driver
interrupt activity or a hardware error or a correctable
(soft) memory error-the clock will "loose" time, and
the time value reported to the user with appear to have
slowed down.)
When SET TIME is issued with no parameters, the TOY
clock is loaded into the system clock; the running
system clock is set to the time stored in the TOY
clock. This assumes the TOY clock is more accurate
than the system clock, as is normally the case.
On most (all?) VAX systems, the battery that is
associated with the TOY clock can be disconnected and
replaced if (when) it fails-TOY clock failures are
quite commonly caused by a failed nickel-cadmium (NiCd)
or lithium battery, or by a failed Dallas chip.
4-8
Time and Timekeeping
__________________________________________________________
4.2 Keeping the OpenVMS system time synchronized?
To help keep more accurate system time or to keep
your system clocks synchronized, TCP/IP Services NTP,
DECnet-Plus DTSS (sometimes known as DECdtss), DCE
DTS, and other techniques are commonly used. If you do
not or cannot have IP access to one of the available
time-base servers on the Internet, then you could use
dial-up access to NIST or other authoritative site, or
you can use a direct connection to a local authorative
clock.
There 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 code that grabs
the time off a GPS receiver digital link, or a receiver
(effectively a radio and a codec) that processes the
time signals from radio stations WWV, WWVH, WWVB, or
similar.
Processing the serial or hardware time protocols
often involves little more than reading from an EIA232
(RS232) serial line from the receiver, something that
is possible from most any language. Information on
correctly drifting the OpenVMS system clock to match
the time-base time is available within the logic of at
least one OpenVMS Freeware package. (See Section 4.3
for a few potential hardware options.)
One example of acquring a time-base through local
integrated hardware involves the IRIG time format
(IRIG-A, -B, -G), a binary signal containing the
current time in hours, minutes, seconds and days
since the start of the current year. IRIG can also
contain the time of day as the number of seconds since
midnight. HP Custom Systems and third-party vendors
have variously offered IRIG-based reader/generator
modules for OpenVMS systems.
One of the easiest approaches is a network-based
GPS or other similar receiver. Basically, this is a
network server box that provides an NTP server with
the necessary hardware for external synchronization.
In addition to the antenna and the receiver and
4-9
Time and Timekeeping
processing components, these devices provide a network
interface (NIC) and support for an NTP time server,
and applications including the NTP support within
TCP/IP Services 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 host configuration
steps and no host software beyond NTP are required.
(See Section 4.3 for a few potential hardware options.)
Differing time servers (DECnet-Plus DTSS, DCE DTS, NTP,
etc) do not coexist particularly well, particularly if
you try to use all these together on the same node.
Please pick and use just one. (If needed, you can
sometimes configure one package to acquire its timebase
from another protocol, but one and only one time server
package should have direct control over the management
of and drifting of the local OpenVMS system time. In
the specific case of DECnet-Plus DTSS, older product
versions and versions V7.3 and later provide a provider
module, a module which permits DTSS to acquire its time
from NTP. For details on this, please see the comments
in the module DTSS$NTP_PROVIDER.C.)
Unlike DECnet-Plus, TCP/IP Services NTP is not capable
of connecting to a time-base other than the network
time base or the local system clock. Third-party and
open source NTP implementations are available for
OpenVMS, as well.
Useful URLs:
o http://www.boulder.nist.gov/timefreq/service/nts.htm
o http://www.boulder.nist.gov/timefreq/service/acts.htm
o http://www.boulder.nist.gov/timefreq/
o http://www.time.gov/
4-10
Time and Timekeeping
__________________________________________________________
4.3 External time-base hardware?
Here are a few possibilities for providers of a GPS-
based receiver with an embedded NTP server, strictly
culled from the first few pages of a Google search.
Availability, pricing, OpenVMS compatibility and other
factors are not known.
o http://www.galleon.eu.com/
o http://www.meinberg.de/english/
o http://www.ntp-servers.com/
For a direct-connected (local, non-IP, non-NTP) link,
there are serial options available. Google finds
Spectracom Corporation has a NetClock that could be
used here, based on a quick look-I do not know if there
is OpenVMS host software, but that would be possible
to write for the ASCII data stream that the device
supports. (Such coding requires knowledge of serial
I/O, character processing, and knowledge of the clock
drift API mechanisms in OpenVMS-there exists Freeware
tools that could be used to learn how to tie into the
clock drifting mechanisms of OpenVMS.)
o http://www.spectracomcorp.com/
http://www.spectracomcorp.com/
Information on, and experiences or recommendations for
or against these or other similar devices is welcome.
_____________________________
4.3.1 Why do my cluster batch jobs start early?
Your system time is skewed across your cluster members,
and the cluster member performing the queue management
tasks has a system time set later than the system time
of the member running the batch job.
This behaviour is most noticable when using
SUBMIT/AFTER=TOMORROW and similar constructs, and
use of /AFTER="TOMMOROW+00:01:00" or such is often
recommended as a way to avoid this. The combination
time value specified should be larger than the maximum
4-11
Time and Timekeeping
expected time skew. In the example shown, the maximum
cluster clock skew is assumed less than 1:00.
You can also maintain your system times in better
synchronization, with available tools described in
Section 4.2 and elsewhere.
_____________________________
4.3.2 Why does my OpenVMS system time drift?
Memory errors, hardware problems, or most anything
operating at or above IPL 22 or IPL 24 (clock IPL is
system family dependent; code executing at or above
the clock IPL will block the processing of clock
interrupts), can cause the loss of system time. Clock
drift can also be caused by normal (thermal) clock
variations and even by the expected level of clock
drift.
When clock interrupts are blocked as a result of the
activity of high-IPL code-such as extensive driver
interrupt activity or a hardware error or a correctable
(soft) memory error-the clock will "loose" time, and
the time value reported to the user with appear to have
slowed down. Correctable memory errors can be a common
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 controllers including the ELSA GLoria Synergy
PBXGK-BB; the PowerStorm 3D10T effectively stalling
the PCI bus. See Section 5.16 for details on the ELSA
GLoria Synergy controller, and make certain you have
the current GRAPHICS ECO kit installed.
Clock drift can also be (deliberately) caused by the
activity of the DTSS or NTP packages.
Also see Section 4.1.1.2.1, Section 4.1.1, and
Section 4.3.4.
4-12
Time and Timekeeping
_____________________________
4.3.3 Resetting the system time into the past?
You can resynchronize system time using DCL commands
such as SET TIME and SET TIME/CLUSTER, but these
commands can and obviously will cause the current
system time to be set backwards when the specified time
predates the current system time. This time-resetting
operation can cause application problems, and can
adversely effect applications using absolute timers,
applications that assume time values will always be
unique and ascending values, and applications.
Setting the time backwards by values of even an hour
has caused various run-time problems for applications
and layered products. For this reason, this technique
was not considered supported during the Year 2000 (Y2K)
testing; a system or cluster reboot was strongly
recommended as the correct means to avoid these
problems.
Application programmers are encouraged to use the time-
related and TDF-related events that are available with
the $set_system_event system service, and/or to use
UTC or similar time, as these techniques can permit
the application to better survive retrograde clock
events. (There is an ECO to repair problems seen in
the DECnet-Plus support for generating TDF events from
DTSS, and this applies to V7.3 (expected to be in ECO4
and later) V7.3-1 (expected to be in ECO3 and later)
and V7.3-2 (expected to be in ECO1 and later). Apply
the most current DECnet-Plus ECO kits for these OpenVMS
releases, for best TDF event support from DECnet-Plus.)
See Section 4.3.4 and Section 4.3.1.
_____________________________
4.3.4 How can I drift the OpenVMS system time?
With DECdts and TCP/IP Services NTP, the system time
value is "drifted" (rather than changed), to avoid the
obvious problems that would arise with "negative time
changes". The same basic clock drifting technique is
used by most (all?) time servers operating on OpenVMS,
typically using the support for this provided directly
within OpenVMS.
4-13
Time and Timekeeping
An example of the technique used (on OpenVMS VAX)
to drift the system time is the SETCLOCK tool on the
OpenVMS Freeware.
For information on the use of the EXE$GL_TIMEADJUST and
EXE$GL_TICKLENGTH cells on OpenVMS Alpha, see OpenVMS
AXP Internal and Data Structures, located on page 348.
For those areas which switch between daylight saving
time (DST) and standard time, the time value is not
drifted. The time is adjusted by the entire interval.
This procedure is inherent in the definition of the
switch between DST and standard time. (Do look at
either not switching to daylight time, or (better)
using UTC as your time-base, if this change-over is not
feasible for your environment.)
See Section 4.3.4 and Section 4.3.3.
_____________________________
4.3.5 How can I configure TCP/IP Services NTP as a time
provider?
An NTP time provider provides its idea of the current
time to NTP clients via the NTP protocol. Most systems
are NTP clients, but...
NTP has a heirarchy of layers, called strata. The
further away from the actual NTP time source (Internet
time servers are at stratum 1), the lower the strata
(and the larger the number assigned the statum).
NTP explicity configured at stratum one provides time
to NTP operating at lower strata, and the provided time
is acquired based on the local system time or via some
locally-accessible external time source.
NTP at other (lower) strata both receive time from
higher strata and can provide time to lower strata,
and automatically adjust the local stratum. The highest
stratum is one, and the lowest available stratum is
fifteen.
The TCP/IP Services NTP package can operate at any
stratum, and can be configured as a peer, as a client,
or as a broadcast server. NTP can also provide time to
a DECnet-Plus DTSS network, see Section 4.2.
4-14
Time and Timekeeping
With TCP/IP Services V5.0 and later, the only supported
reference clock is the LCL (local system clock). If
your system has an excellent clock or if the system
time is being controlled by some other time service
or peripheral (such as DTSS services, GPS services,
a cesium clock, a GPIB controller or other similar
time-related peripheral), you can configure NTP to use
the system clock as its reference source. This will
mimic the master-clock functionality, and will configre
NTP as a stratum 1 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
For local-master functionality, the commands are very
similiar. Use:
server 127.127.1.0
fudge 127.127.1.0 stratum 8
The difference between these two is the stratum, and
the omission of the prefer keyword. Specifying a higher
stratum allows the node to act as a backup NTP server,
or potentially as the sole time server on an isolated
network. The server will become active only when all
other normal synchronization sources are unavailable.
The use of "prefer" causes NTP to always use the
specified clock as the time synchronization source.
With the TCP/IP Services versions prior to V5.0,
the NTP management is rather more primitive. To
configure the local OpenVMS system from an NTP
client to an NTP server (on TCP/IP Services versions
prior to V5.0), add the following line to the
sys$specific:[ucx$ntp]ucx$ntp.conf file:
master-clock 1
Also, for TCP/IP Services prior to V5.0, see the NTP
template file:
SYS$SPECIFIC:[UCX$NTP]UCX$NTP.TEMPLATE
4-15
Time and Timekeeping
Note that NTP does not provide for a Daylight Saving
Time (DST) switch-over, that switch must arise from
the timezone rules on the local system and/or from the
SYS$EXAMPLES:DAYLIGHT_SAVINGS procedure. (Further,
there is a known bug in SYS$EXAMPLES:DAYLIGHT_
SAVINGS.COM in V7.3, please obtain the available ECO
kit.)
For current TCP/IP Services and related OpenVMS
documentation, please see:
o http://www.hp.com/go/openvms/doc/
__________________________________________________________
4.4 Managing Timezones, Timekeeping, UTC, and Daylight Saving
Time?
You will want to use the command procedure:
o SYS$MANAGER:UTC$TIME_SETUP.COM
to configure the OpenVMS Timezone Differential Factor
(TDF) on OpenVMS V6.0 and later. Select the BOTH
option. This configures the OpenVMS TDF settings,
though it may or may not configure the TDF and the
timezone rules needed or used by other software
packages. Please do NOT directly invoke the following
command procedures:
o SYS$MANAGER:UTC$CONFIGURE_TDF.COM ! do not directly
use
o SYS$MANAGER:UTC$TIMEZONE_SETUP.COM ! do not directly
use
TCP/IP Services V5.0 and later use the OpenVMS TDF,
UTC, and timezone support. Earlier versions use a TDF
mechanism and timezone database that is internal to the
TCP/IP Services package. Also on the earlier versions,
the TDF must be manually configured within TCP/IP
Services, in addition to the OpenVMS configuration
of the TDF.
4-16
Time and Timekeeping
DECnet-Plus in V7.3 and later uses the OpenVMS TDF,
UTC, and timezone support, and displays its timezone
prompts using UTC$TIME_SETUP.COM. Earlier versions use
a TDF TDF mechanism, timezone database, and automatic
switch-over that is internal to the DECnet-Plus
package. Also on earlier versions, the TDF must be
configured within the DECnet-Plus DECdtss package, in
addition to the OpenVMS configuration of the TDF.
Application code using HP C (formerly Compaq C,
formerly DEC C) will use the OpenVMS UTC and TDF
mechanisms when the C code is compiled on OpenVMS V7.0
and later (and when the macro _VMS_V6_SOURCE is NOT
defined). HP C does NOT use the OpenVMS UTC and TDF
mechanisms when the C code is compiled on OpenVMS
releases prior to V7.0, or when the preprocessor
declaration _VMS_V6_SOURCE is declared.
DCE DTS TDF management details to be determined.
In OpenVMS Alpha V6 releases (V6.1, V6.2, V6.2-1Hx,
etc), the TDF value is written to SYS$BASE_IMAGE.EXE.
With OpenVMS Alpha V7.0 and later and with OpenVMS VAX
V6.0 and later, SYS$SYSTEM:SYS$TIMEZONE.DAT contains
the TDF. This means that OpenVMS Alpha systems will
need to have the TDF value reset manually-usually
within SYSTARTUP_VMS.COM-on reboots prior to V7.0.
During OpenVMS Bootstrap, the SYSINIT module reads
SYS$TIMEZONE.DAT to acquire the TDF for use in the
system global cell EXE$GQ_TDF. This is done to ensure
that the system boots with a valid TDF (a value which
may be zero). The UTC system services get the TDF
from this cell. These 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
configured and run, the image DTSS$SET_TIMEZONE.EXE
is invoked and can override the TDF and timezone rule
settings from SYSINIT or from UTC$TIME_SETUP.COM-
this image runs even if DTSS is disabled. If the
settings do not match (due to inconsistencies in
timezone specification in UTC$TIME_SETUP.COM and
NET$CONFIGURE.COM), DTSS will reset the values to match
its definitions.)
4-17
Time and Timekeeping
Prior to OpenVMS V7.3, daylight saving time (DST)
switchover is handled automatically only when DCE DTS
or DECnet-Plus DTSS is in use. In V7.3, OpenVMS can be
configured to automatically switch over to daylight
time, and also generates an event that interested
applications can use to detect the switch-over between
standard time and daylight time.
The manual switchover between daylight time and
standard time is correctly accomplished via the
SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM command procedure
procedure.
Note
NTP (alone) does NOT provide automatic switch-
over.
Note
The DST switch-over does NOT drift the time
value; the switch-over applies the entire
difference as a unit, as is standard and expected
practice. (Do look at either not switching
to daylight time, or (better) using UTC as
your time-base, if this one-hour change is
not feasible within your environment.) (For
information associated with drifting the systen
time, please see Section 4.3.4.)
If you switch the TDF or DST setting, you will also
want to restart or reconfigure any time-sensitive
applications (those not using the time differential
factor (TDF) change event available in V7.3 and
later). Examples of these applications can include
the need to restart the NFS client and NTP. (In the
case of NTP, will want to try to "drift" the time (see
Section 4.2 and see Section 4.3.4), and will find that
the DST switch-over will exceed the NTP-defined maximum
threshold allowed for drifting. Hence the NTP restart
is presently required.)
4-18
Time and Timekeeping
_____________________________
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.
4-19
Time and Timekeeping
_____________________________
4.4.1.1 Customizing or Updating your TDF (Timezone) Setting?
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:
# Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL]
Zone WhereEver 2:00 - WhereEver
The OpenVMS source files for the timezone rules are
stored here:
SYS$COMMON:[SYS$ZONEINFO.SYSTEM.SOURCES]
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,
4-20
Time and Timekeeping
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.)
Note
As mentioned in Section 4.4.2, please don't
modify or redefine the TZ logical name (found on
older configurations), or the SYS$TIMEZONE_NAME
logical name, or any other time- or timezone-
related logical names directly yourself. Rather,
please use the zic compiler and/or the UTC$TIME_
SETUP.COM procedure.
For various published timezone rules or updated to
same, see the tar.gz files (these are gzipped tar
archives) available at:
o ftp://elsie.nci.nih.gov/pub/
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.
4-21
Time and Timekeeping
_____________________________
4.4.1.2 US Daylight Time Changes Starting 1-Mar-2007?
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.
_____________________________
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:
o 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
4-22
Time and Timekeeping
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
4-23
Time and Timekeeping
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]:
o SYS$SPECIFIC:[SYSEXE]SYS$TIMEZONE.DAT
o 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:
$ 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-24
Time and Timekeeping
__________________________________________________________
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 ussue this
command, and you must also be granted the NET$MANAGE
identifer to shutdown and to restart DTSS.
4-25
Time and Timekeeping
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
4-26
Time and Timekeeping
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:
o Show the system configuration and provide the basic
debugging capability
4-27
Time and Timekeeping
o Initiate the firmware update or load the test
firmware version
o Power on or off, halt, or reset the system or
partition
o The system partitioning and cabling functions
o Displays of the health of hardware environment,
including such constructs as fans, power supplies
and environmental and temperature values.
o Remote server management tasks
o The connection to the virtual SRM console
o 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.
4-28
Time and Timekeeping
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.
4-29
Time and Timekeeping
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:
o ftp://elsie.nci.nih.gov/pub/
o http://physics.nist.gov/GenInt/Time/time.html
o http://nist.time.gov/
__________________________________________________________
4.8 Using w32time or an SNTP as a time provider?
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.
4-30
Time and Timekeeping
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.
4-31
_______________________________________________________
5 System Management Information
__________________________________________________________
5.1 What is an installed image?
The term "install" has two distinct meanings in
OpenVMS. The first relates to "installing a product",
which is done with either the SYS$UPDATE:VMSINSTAL.COM
command procedure or the POLYCENTER Software
Installation (PCSI) utility (PRODUCT command). The
second meaning relates to the use of the INSTALL
utility, which is what concerns us here.
The INSTALL utility is used to identify to OpenVMS
a specific copy of an image, either executable or
shareable, which is to be given some set of enhanced
properties. For example, when you issue the SET
PASSWORD command, the image SYS$SYSTEM:SETP0.EXE is
run. That image needs to have elevated privileges to
perform its function.
The other important attribute is /SHARED. This means
that shareable parts of the image (typically read-only
code and data) are loaded into memory only once and are
shared among all users on a system. Executable images
can be installed /SHARED as well as shareable library
images. (The term "shareable" has dual meanings here,
too. See the OpenVMS Programming Concepts Manual for
further details.)
It's important to note that there is no such thing as
"installing a shareable image with privileges". The
INSTALL utility will let you do it, but the privileges
you specify will be ignored. To have a callable routine
run with enhanced privileges that are not available
to its caller, you must construct your routines as
"user-written system services" (UWSS) and install
the shareable image with the /PROTECT qualifier.
See the OpenVMS Programming Concepts Manual for more
information on user-written system services. Note also
that in many cases the need to grant privileges to an
5-1
System Management Information
image can be replaced with the use of the "Protected
Subsystems" feature that grants a rights identifier to
an image. See the OpenVMS Guide to System Security for
information on Protected Subsystems.
__________________________________________________________
5.2 Are there any known viruses for OpenVMS?
Viruses and worms are common on personal computers
because the operating systems involved, such as
the Microsoft MS-DOS, Windows 95, Windows 98 and
Windows ME variants, do not particularly protect
the operating system or the file system against
hostile action by programs. Microsoft Windows NT,
Windows 2000 and Windows XP do implement protections
for specific configurations and do implement memory
protection models, but many users of these systems
choose to operate with full adminstrator access and
thus the available protections are entirely defeated
and entirely not relevent, and any program that can
activate itself or can cause the user to activate the
code can subvert the operating system and take over the
hardware, at which point the malicious code can do most
anything it wishes, including hiding copies of itself
in other programs or in the file system, redistributing
itself via mail, IM, or network connections, or can be
used as a zombie in staging attacks on other systems.
This is less likely with multi-user systems such as
OpenVMS, Unix, Linux, MVS and other platforms for
various reasons. First, the operating system runs in a
privileged mode in memory that is protected against
modification by normal user programs. Any program
cannot simply take over the hardware as it can on
operating systems without security and particularly
without memory page protections. Secondly, multi-
user systems can be set up so that non-privileged
programs cannot modify system programs and files on
disk, and this is normal for most installations. Both
of these protection schemes mean that traditional viral
infections don't work on these OSes. Third, typical
applications and configurations tend to prevent the
uncontrolled execution of untrusted code as part
of received mail messages or web access; one of the
5-2
System Management Information
central vulnerabilities of the Microsoft Windows
platform involves its intentionally easy ability to
dynamically (and transparently) activate code and
macros that are embedded within mail messages and
within data files.
It is possible for OpenVMS and other multi-user systems
to become infected by viruses or worms, but to do so,
the program containing the virus must be run from a
user account that has amplified privileges. So long as
the system administrator is careful that only trusted
applications are run from such accounts (and this
is generally the case) and so long as there are no
OpenVMS system security breaches (due to malicious
operator activity, OpenVMS errors, or errors within
trusted and privileged product packages) there is
no of modifications to the operating system or other
protected files from the virus or the worm.
The FAQ maintainer is aware of a few (and very old)
DECnet worms that have affected OpenVMS systems on
DECnet networks ("WANK" was one), but is aware of no
OpenVMS viruses that are loose in the field.
To protect against viruses and other attempts at
system interference or misuse, please follow the
security recommendations in the OpenVMS Guide to System
Security. Additionally, you will want to keep your
OpenVMS ECOs current and you will want to apply all
mandatory ECO kits and any security MUPs for OpenVMS
and OpenVMS products, and you will want to keep to
OpenVMS releases with Prior Version Support (PVS) or
with Current Version Support. (This is obviously a
general system maintenance recommendation, in addition
to being a good system security recommendation-new
security features and capabilities are implemented in
more recent OpenVMS releases, for instance. Details on
PVS releases are available over in Section 5.10.6.)
You may also want to consider optional software
products which can monitor your system for intrusion
or infection attempts. Computer Associates (CA) offers
various products in this area, as to other vendors.
5-3
---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com
User Contributions: |
Comment about this article, ask questions, or add new information about this topic: