[Comp.Sci.Dept, Utrecht] Note from archiver<at>cs.uu.nl: This page is part of a big collection of Usenet postings, archived here for your convenience. For matters concerning the content of this page, please contact its author(s); use the source, if all else fails. For matters concerning the archive as a whole, please refer to the archive description or contact the archiver.

Subject: OpenVMS Frequently Asked Questions (FAQ), Part 3/11

This article was archived around: Sun, 04 Sep 2005 19:55:43 GMT

All FAQs in Directory: dec-faq/vms
All FAQs posted in: comp.os.vms, comp.sys.dec
Source: Usenet Version

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 _____________________________ details... 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. _____________________________ 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. 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 _____________________________ 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.) _____________________________ details... 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. _____________________________ 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. 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... _____________________________ 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, 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 prefer fudge stratum 0 For local-master functionality, the commands are very similiar. Use: server fudge 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-19 Time and Timekeeping _____________________________ 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 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 _____________________________ 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.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