| Previous | Contents | Index |
Some of the OpenVMS books that are or have been available from the Digital Press imprint
are listed in Table 3-4:
| Title and Author | ISBN |
|---|---|
|
Getting Started with OpenVMS System Management
David Donald Miller |
1-55558-281-8 |
|
Introduction to OpenVMS, 5th Edition
Lesley Ogilvie Rice |
1-55558-194-3 |
|
Introduction to OpenVMS
David W Bynon |
1-878956-61-2 |
| OpenVMS Alpha Internals: Scheduling and Process Control | 1-55558-156-0 |
| OpenVMS AXP Internals and Data Structures: Version 1.5 | 1-55558-120-X |
|
OpenVMS System Management Guide
Baldwin, et al |
1-55558-143-9 |
|
The OpenVMS User's Guide, Second Edition
Patrick Holmay |
1-55558-203-6 |
|
Using DECwindows Motif for OpenVMS
Margie Sherlock |
1-55558-114-5 |
| VAX/VMS Internals and Data Structures: Version 5.2 | 1-55558-059-9 |
|
Writing Real Programs in DCL, Second Edition
Hoffman and Anagnostopoulos |
1-55558-191-9 |
|
Writing OpenVMS Alpha Device Drivers in C
Sherlock and Szubowicz |
1-55558-133-1 |
For various featured OpenVMS books, also please see the books link at the OpenVMS website:
For a bibliography of various OpenVMS books, please see:
Various OpenVMS mailing lists are available, with some of the available lists detailed in Table 3-5.
| Subscription | Interest Area |
|---|---|
| OpenVMS Freeware archive announcement list |
FSupdate@goatley.com
FSupdate-request@goatley.com 1 |
| Two-way echo of vmsnet.internals |
VMSnet-Internals@goatley.com
VMSnet-Internals-request@goatley.com 1 |
| OpenVMS Alpha Internals discussions |
Alpha-IDS@goatley.com
Alpha-IDS-request@goatley.com 1 |
| BLISS discussions |
BLISSters@goatley.com
BLISSters-request@goatley.com 1 |
| Process Software MultiNet mailing list (news gateway) |
Info-MultiNet@process.com
Info-MultiNet-request@process.com 1 |
| Process Software TCPware mailing list (news gateway) |
Info-TCPware@process.com
Info-TCPware-request@process.com 1 |
| Process Software PMDF mailing list (news gateway) |
Info-PMDF@process.com
Info-PMDF-request@process.com 1 |
| The SRI CHARON-VAX VAX emulator package |
CHARON-VAX-Users@process.com
CHARON-VAX-Users-request@process.com 1 |
| Info-Zip's Zip & UnZip discussion list |
Info-Zip@wku.edu
Info-Zip-Request@wku.edu 1 |
| RADIUS-VMS, a RADIUS server for OpenVMS discussion forum |
radius-vms@dls.net
radius-vms-request@dls.net 1 |
| Internet Service Providers (ISPs) running OpenVMS |
vms-isps@dls.net
vms-isps-request@dls.net 1 |
| Users of Mark Daniel's WASD 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. | http://wasd.vsm.com.au/ |
| VMS Forum | http://www.neurophys.wisc.edu/comp/ava/vms_forum.htmlx |
The HP OpenVMS Ask The Wizard (ATW) website is an informal area containing questions and answers on a wide variety of topics.
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.9.
To access a cited topic directly, use the URL filename WIZ_topic-number.HTML. For example, topic (1020) can be accessed directly using the URL filename wiz_1020.html at the following URL:
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 new batches of topics are posted out to the ATW website.
Before posting a question to the Ask The Wizard area, please read and
please heed the posting rules---and please remember to search this
document, the OpenVMS FAQ. And if you have a question that requires an
answer, or if your question has time-critical constraints or business
constraints, please contact the HP customer support center directly.
3.10 Access to the OpenVMS Netscape Navigator documentation?
The documentation URLs embedded into the browser itself may not operate correctly in all cases, and (for reasons not worthy of repeating here) redirects may not be available.
You can manually access the documentation via:
For information on the Mozilla web browser, please see Section 13.4.
3.11 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.
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.
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:
are all good time-related resources, some general and some specific to
OpenVMS.
4.1.1 Details of the OpenVMS system time-keeping?
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.
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.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.
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.
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.
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.
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.)
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").
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.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.
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 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.
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:
| Previous | Next | Contents | Index |