home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20592 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  4.2 KB
  1. Path: sparky!uunet!munnari.oz.au!comp.vuw.ac.nz!zl2tnm!toyunix!don
  2. Newsgroups: comp.os.vms
  3. Subject: Re: Date incorrect after reboot
  4. Message-ID: <3890007@zl2tnm.gen.nz>
  5. From: don@zl2tnm.gen.nz (Don Stokes)
  6. Date: 8 Jan 93 15:53:20 GMT
  7. Sender: news@zl2tnm.gen.nz (GNEWS Version 2.0 news poster.)
  8. References: <1993Jan7.090247@mccall.com>
  9. Distribution: world
  10. Organization: The Wolery
  11. Lines: 93
  12.  
  13. tp@mccall.com (Terry Poot) writes:
  14. > In article <1993Jan7.090347.14794@fys.ruu.nl>, hooft@fys.ruu.nl (Rob Hooft)
  15. > writes:
  16. > >Just make sure you have a cluster: good LAVC practice is to
  17. > >synchronize the clocks every once in a while: I think SET TIME/CLUSTER
  18. > >will also take care of the problem?
  19. > 
  20. > I don't think so. SET TIME with no arguments copies the system time into the TOY
  21. > clock. SET TIME/CLUSTER synchronizes the cluster, but does NOT copy it into the
  22. > TOY clock on any system. 
  23.  
  24. Other way around.  SET TIME without parameters gets the time from the TOY.
  25.  
  26. The SET TIME sequence goes (roughly):
  27.  
  28.     If time specified:
  29.         $SETTIME parameter
  30.     else
  31.         $SETTIME
  32.     if /CLUSTER:
  33.         For all cluster members who will talk to us:
  34.             time = current time
  35.             Instruct CSP (aka CLUSTER_SERVER) to do a
  36.                     $SETTIME time for us.
  37.  
  38. $SETTIME goes like this:
  39.     if time specified:
  40.         t = new TODR value
  41.     else
  42.         t = current TODR
  43.         if t > 1 year
  44.             t = t - 1 year
  45.     set TODR = t
  46.     Write 01-JAN-<year> to SYS.EXE
  47.     Set system time
  48.  
  49.  
  50. It's a good idea to do a SET TIME periodically, since the TOY tends to be
  51. far more accurate the system time; the former usually being based on a
  52. crystal oscillator, the latter on the who-knows-what in the CPU that bumps
  53. the interval timer.  There are exceptions -- see below.
  54.  
  55. If in a cluster, a SET TIME/CLUSTER (or its SYSMAN equivalent) should be
  56. done periodically to synchronise times across cluster members.  Do it from
  57. whichever node you think has the most accurate TOY (aka TODR above) clock.
  58. Remember that the queue mangler (at least prior to V5.5) schedules on
  59. any node; what tends to happen is that the node with the fastest clock
  60. schedules jobs, regardless of which processor it runs on.  The effect of
  61. this is that if you have self-resubmitting batch jobs that go:
  62.  
  63.     $ this = f$environment("PROCEDURE")
  64.     $ SUBMIT/AFTER=TOMORROW 'this'
  65.     $ [rest of job]
  66.  
  67. your job ends up running slighty before tomorrow (because another node
  68. let it go), and you get two copies running TODAY.  
  69.  
  70. You should always kick such things off /AFTER="TOMORROW+0:05" to avoid
  71. clock skew, and periodically synchronise the clocks to keep the skew under
  72. five minutes.  
  73.  
  74. Tip to the wise: if you have Nautilus processors (85xx, 8700, 8800 88x0?),
  75. *don't* recalibrate from those.  They're dreadfully inaccurate.  I can 
  76. personally vouch for 82x0/83x0s and MicroVAX IIs.  (The former by experience,
  77. the latter by taking a squiz at the hardware....)
  78.  
  79. > it by doing SET TIME/CLUSTER from a node that was right. A few days later we
  80. > lost power, and when the cluster came back up, that same node was again off by
  81. > an hour. I always try to remember now to use sysman to do a SET TIME on each
  82. > system after synchonizing the cluster time. One of these days, I'll even look up
  83. > the SYSMAN command to do that so I can do all from within SYSMAN. :-)
  84.  
  85. In theory at least, the $SETTIMEs done by CSP on the remote nodes should
  86. be no different to the $SETTIME done on the local node.
  87.  
  88. Was the offending node a Nautilus?  I've seen lots of bugs on the damn
  89. things.  The physical TODR is derived from the system time on the Pro
  90. consoles, and the support has often been flakey.  It's a good idea to
  91. exit the console program and do a SHOW TIME on the console processor
  92. itself (and a SET TIME if necessary).  I think the worst of the bugs have
  93. been fixed, but I've had to set the time manually on them before,
  94. regardless of where the VMS SET TIME was done from.  Horrible things.  I
  95. think the console software begins to work at version 10 or 11.....
  96.  
  97.  
  98. As to my earlier comment about SHUTDOWN.COM -- the implication (as I read
  99. it) was that the ever-lovin CSC were suggesting that a SET TIME be done
  100. before *intentional* shutdowns....
  101.  
  102. --
  103. Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
  104. Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
  105. Victoria University of Wellington, New Zealand              +64-4-495-5052
  106.