[an error occurred while processing this directive]

HP OpenVMS Systems

ask the wizard
Content starts here

Standalone BACKUP and Upgrades: VAX Timekeeping?

» close window

The Question is:

 
During a previous attempt to upgrade to VMS 7.2, my log indicates that at
the Phase 2
boot to OpenVMS (TM) VAX Version BC72-72T Major version id = 1 Minor version
id = 0
i was prompted thus:
System time is:  28-SEP-1998 17:17:22.12
 
 Enter Yes to the next question to leave the system time unchanged
        (the system clock continues to run unaffected)
 
...which happened after:
 
            984 files deleted from system disk
 
        File cleanup complete - 28-SEP-1999 17:07:33.89
 
Was this a check to see if I was awake?  I just checked the time against my
watch, not
thinking to check the year.  Is this an SPR, or just a mechanism to startup
all waiting
software when I logged in and corrected the year? :)  Hundreds of files
issued
%ANALDISK-W-MULTALLOC from analyze/disk because a product that needed to be
reinstalled took off in the 1-year advance to 1999.  Should I recommend that
its
startup be commented in systartup_vms - as I will be doing?
thanks,
~aj
----------------------------------------------------------------------------
Disclaimer: Do you trust Washington, Paleface?
.-  .---  . .-- . .-.. .-.. If we were meant to vote, there'd be candidates.
- 2012.12.21 Federation, not Federal Reserve. New Age, not New World Order -
 
 


The Answer is :

 
  The OpenVMS Wizard will assume you saw a one-year jump in the system
  time, and a jump that occured after a reboot during the OpenVMS VAX
  system upgrade process.  The OpenVMS Wizard will also assume that the
  incorrect year was displayed in the prompt, and that the confirmation
  check for the date was erroneously answered.  If so, the behaviour
  you saw is normal and expected.
 
  Some background on OpenVMS VAX, and specifically on VAX timekeeping
  follows...
 
  All VAX systems have a Time Of Day Register (TODR) clock resolution of
  497 days, and the value is aggregated with the year value that is stored
  in the SYS.EXE system image.  Both the time and day of the year values
  in the TODR and the year value in SYS.EXE must be in synchronization in
  order to correctly maintain the system time.
 
  The OpenVMS upgrade takes pains to ask that the system time be validated
  whenever there may be a discepency introduced.  As part of an OpenVMS
  upgrade, a new SYS.EXE system image (with an in-built saved year value)
  is normally introduced into the system environment.
 
  Standalone BACKUP also prompts for the system time, and for the same
  reason -- standalone can and often does use a different SYS.EXE system
  image, and this saved value may or may not be correct for the value
  stored in the TODR clock.
 
  Because of the resolution of the TODR, the OpenVMS Wizard recommends
  a SET TIME command be performed within the first 497-366 (or 497-365)
  days of the year.  An orderly system SHUTDOWN performed within the
  first (circa) three months of the calendar year will also automatically
  perform the necessary SET TIME operation, as well.
 
  Additional details are available at:
 
http://www.openvms.digital.com/doc/72final/6017/6017pro_087.html#index_x_4977
 
  and:
 
http://www.openvms.digital.com/doc/72final/6521/6521pro_009.html#date_time
http://www.openvms.digital.com/doc/72final/6521/6521pro_010.html#ver_sys_time
 

answer written or last revised on ( 6-OCT-1999 )

» close window