Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z - Internet FAQ Archives

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

( Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 - Part8 - Part9 - Part10 - Part11 )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Forum ]

See reader questions & answers on this topic! - Help others by sharing your knowledge
Archive-name: dec-faq/vms/part3
Posting-Frequency: quarterly
Last-modified: 02 Sep 2005
Version: VMSFAQ_20050902-03.TXT



          Table 3-2 (Cont.)  OpenVMS Tutorial and Documentation Websites


                             An OpenVMS Quiz


                             CCSS Interactive Learning has OpenVMS
                             training materials


                             AcerSoft Training information, and Shannon
                             Knows Punditry


                             MindIQ training information


                             Quadratrix; OpenVMS training, products and
                             services; affiliated with Global Knowledge

          3.6.2  Books and Tutorials?

                   Some of the OpenVMS books that are or have been
                   available from the Digital Press imprint


                   are listed in Table 3-3:

          Table 3-3  DP Books


          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
          Lesley Ogilvie Rice



          Table 3-3 (Cont.)  DP Books


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

                   For various featured OpenVMS books, also please see the
                   books link at the OpenVMS website:


                   For a bibliography of various OpenVMS books, please




          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


          OpenVMS Freeware archive
          announcement list     [1]

          Two-way echo of       
          vmsnet.internals                VMSnet-Internals-

          OpenVMS Alpha Internals
          discussions           [1]

          BLISS discussions     

          Process Software MultiNet
          mailing list (news gateway)     Info-MultiNet-

          Process Software TCPware
          mailing list (news gateway)     Info-TCPware-

          Process Software PMDF mailing
          list (news gateway)   [1]

          The Software Resources
          International (SRI) CHARON-VAX  CHARON-VAX-Users-
          VAX emulator package  [1]

          Info-Zip's Zip & UnZip
          discussion list       [1]

          RADIUS-VMS, a RADIUS server
          for OpenVMS discussion forum[1]

          Internet Service Providers
          (ISPs) running OpenVMS[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.



          Table 3-4 (Cont.)  OpenVMS Mailing Lists


          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.

          VMS Forum             

          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.


                   For additional information on the OpenVMS Ask The
                   Wizard (ATW) area and for a pointer to the available
                   ATW 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:


                   A zip archive (named containing all of
                   the available topics and questions can be downloaded
                   from the above URL. The zip archive is
                   completely regenerated when/if existing topics posted
                   out to the ATW website are updated. Copies of this
          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:


          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.




          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.


                   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:







                   are all good time-related resources, some general and
                   some specific to OpenVMS.

          4.1.1  Details of the OpenVMS system time-keeping?


                   Time and Timekeeping


  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.


                   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.


                   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.


                   Time and Timekeeping


                   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

                     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.


                   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.)


  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


                   Time and Timekeeping

                   are causing the processing of the clock interrupts to
                   be blocked.


                   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.


                   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

                   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.)


                   Time and Timekeeping

                   IA-64 (Itanium) hardware time-keeping details to be

  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

                   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").


                   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

                   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.


                   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

                   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

                   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


                   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:






                   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.




                   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.)


                   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


                   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

                   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.


                   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

                   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.


                   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

                   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

                   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.


                   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:

                   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:



                   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

                   For current TCP/IP Services and related OpenVMS
                   documentation, please see:


          4.4  Managing Timezones, Timekeeping, UTC, and Daylight Saving

                   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

                   o  SYS$MANAGER:UTC$TIMEZONE_SETUP.COM ! do not directly

                   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.


                   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.)


                   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


                      NTP (alone) does NOT provide automatic switch-


                      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.)


                   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


                   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:


                   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,


                   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.)


                      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:


                   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

                   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.


                   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-

                   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

                   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


                   Time and Timekeeping

                   can be used to modify the settings of the SYS$TIMEZONE_
                   SYS$TIMEZONE_NAME system logical names based on the

                   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.

                   $ DEFINE/SYSTEM/EXECUTIVE LISP$TIME_ZONE 05   ! Constant
                   $ DEFINE/SYSTEM/EXECUTIVE LISP$TIME_ZONE 05   ! Constant
                       '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:


                   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


                   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



                   These two files are in an erroneous location and must
                   be recreated in the correct directory:


                   If the DCL command:


                   shows these files in SYS$SPECIFIC:[SYSEXE], then delete
                   them and use SYS$MANAGER:UTC$TIME_SETUP.COM to recreate

                   On OpenVMS versions prior to V7.3, if the file:


                   is present on your system, then you may need to invoke:


                   to recreate the timezone files correctly. Invoke
                   this command immediately after [re]executing

                   present on your system, then you may need to execute
                   the following commands:


                   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.


                   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,

                   $ @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.


                   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

                   $ 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


                   Time and Timekeeping

                   or alternatively, you can set the local timezone to
                   one that does not include the automatic daylight time

                   OpenVMS V7.3 and later simplify time and timezone

          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


                   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

                   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.


                   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

          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.


                   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:




          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.


                   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.



          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


                   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


                   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.


 ---------------------------- #include <rtfaq.h> -----------------------------
    For additional, please see the OpenVMS FAQ --
 --------------------------- pure personal opinion ---------------------------
        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 - Part8 - Part9 - Part10 - Part11

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:

Last Update March 27 2014 @ 02:11 PM