| Previous | Contents | Index |
Some of the OpenVMS books that are now or that have been available from the Elsevier Digital Press imprint
are listed in Table 3-3:
| Title and Author | ISBN |
|---|---|
|
Getting Started with OpenVMS
Michael D. Duffy |
1-55558-279-6 |
|
Getting Started with OpenVMS System Management, 2nd Edition
David Donald Miller, et al |
1-55558-243-5 |
|
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 |
Within the above table, no attempt is made to track which books are currently in print, or are currently out of print.
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-4, as are the various discussion forums 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 Software Resources International (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 |
Various OpenVMS discussion forums are available, with some of the available lists detailed in Table 3-5.
| Description | Forum Location |
|---|---|
| The comp.os.vms newsgroup | |
| news:comp.os.vms | |
| HP ITRC Forums | |
| http://forums.itrc.hp.com/service/forums/familyhome.do?familyId=288 | |
| Hunter Goatley: The HG OpenVMS Message Board | |
| http://www.goatley.com/scripts/vmsboard/view.com | |
| Computing.Net: OpenVMS Message Area | |
| http://www.computing.net/openvms/wwwboard/wwwboard.html | |
| Tek-Tips: DEC (HP/Compaq): OpenVMS Forum | |
| http://www.tek-tips.com/gthreadminder.cfm/lev2/3/lev3/19/pid/951 | |
| OpenVMS.Org forums | |
| http://www.openvms.org/ | |
| OpenVMSHobbyist.Org forums | |
| http://www.openvmshobbyist.org/ | |
| Encompasserve (DECUSserve) Notes Conferences | |
| telnet://www.encompasserve.org/ | |
The HP OpenVMS Ask The Wizard (ATW) website was an informal area discussing OpenVMS, 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.8. ATW has been superceded (for new questions) by the ITRC discussion forums; the area remains available for reference.
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:
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.
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:
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, with 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.
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.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.
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 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.
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).
| Previous | Next | Contents | Index |