Newsgroups: comp.os.vms
Subject: Re: Date incorrect after reboot
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 8 Jan 93 15:53:20 GMT
Distribution: world
Organization: The Wolery

tp@mccall.com (Terry Poot) writes:
> In article <1993Jan7.090347.14794@fys.ruu.nl>, hooft@fys.ruu.nl (Rob Hooft)
> writes:
> >Just make sure you have a cluster: good LAVC practice is to
> >synchronize the clocks every once in a while: I think SET TIME/CLUSTER
> >will also take care of the problem?
> 
> I don't think so. SET TIME with no arguments copies the system time into the TOY
> clock. SET TIME/CLUSTER synchronizes the cluster, but does NOT copy it into the
> TOY clock on any system. 

Other way around.  SET TIME without parameters gets the time from the TOY.

The SET TIME sequence goes (roughly):

	If time specified:
		$SETTIME parameter
	else
		$SETTIME
	if /CLUSTER:
		For all cluster members who will talk to us:
			time = current time
			Instruct CSP (aka CLUSTER_SERVER) to do a
					$SETTIME time for us.

$SETTIME goes like this:
	if time specified:
		t = new TODR value
	else
		t = current TODR
		if t > 1 year
			t = t - 1 year
	set TODR = t
	Write 01-JAN-<year> to SYS.EXE
	Set system time


It's a good idea to do a SET TIME periodically, since the TOY tends to be
far more accurate the system time; the former usually being based on a
crystal oscillator, the latter on the who-knows-what in the CPU that bumps
the interval timer.  There are exceptions -- see below.

If in a cluster, a SET TIME/CLUSTER (or its SYSMAN equivalent) should be
done periodically to synchronise times across cluster members.  Do it from
whichever node you think has the most accurate TOY (aka TODR above) clock.
Remember that the queue mangler (at least prior to V5.5) schedules on
any node; what tends to happen is that the node with the fastest clock
schedules jobs, regardless of which processor it runs on.  The effect of
this is that if you have self-resubmitting batch jobs that go:

	$ this = f$environment("PROCEDURE")
	$ SUBMIT/AFTER=TOMORROW 'this'
	$ [rest of job]

your job ends up running slighty before tomorrow (because another node
let it go), and you get two copies running TODAY.  

You should always kick such things off /AFTER="TOMORROW+0:05" to avoid
clock skew, and periodically synchronise the clocks to keep the skew under
five minutes.  

Tip to the wise: if you have Nautilus processors (85xx, 8700, 8800 88x0?),
*don't* recalibrate from those.  They're dreadfully inaccurate.  I can 
personally vouch for 82x0/83x0s and MicroVAX IIs.  (The former by experience,
the latter by taking a squiz at the hardware....)

> it by doing SET TIME/CLUSTER from a node that was right. A few days later we
> lost power, and when the cluster came back up, that same node was again off by
> an hour. I always try to remember now to use sysman to do a SET TIME on each
> system after synchonizing the cluster time. One of these days, I'll even look up
> the SYSMAN command to do that so I can do all from within SYSMAN. :-)

In theory at least, the $SETTIMEs done by CSP on the remote nodes should
be no different to the $SETTIME done on the local node.

Was the offending node a Nautilus?  I've seen lots of bugs on the damn
things.  The physical TODR is derived from the system time on the Pro
consoles, and the support has often been flakey.  It's a good idea to
exit the console program and do a SHOW TIME on the console processor
itself (and a SET TIME if necessary).  I think the worst of the bugs have
been fixed, but I've had to set the time manually on them before,
regardless of where the VMS SET TIME was done from.  Horrible things.  I
think the console software begins to work at version 10 or 11.....


As to my earlier comment about SHUTDOWN.COM -- the implication (as I read
it) was that the ever-lovin CSC were suggesting that a SET TIME be done
before *intentional* shutdowns....

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
Newsgroups: comp.os.vms