From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 26-OCT-1989 01:50
To:	MRGATE::"ARISIA::EVERHART"
Subj:	Daylight to standard time conversion w/o SET TIME

Received: From UCBVAX.BERKELEY.EDU by GIZMO.SRI.COM with TCP; Wed, 25 OCT 89 22:17:16 PDT
Received: by ucbvax.Berkeley.EDU (5.61/1.39)
	id AA24712; Wed, 25 Oct 89 22:15:21 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for info-vax@kl.sri.com (info-vax@kl.sri.com)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 25 Oct 89 21:35:34 GMT
From: crash!simpact!jeh@nosc.mil
Organization: Simpact Associates, San Diego CA
Subject: Daylight to standard time conversion w/o SET TIME
Message-Id: <715.2545c4b6@simpact.com>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com

Most parts of the U.S. return to standard time this coming Saturday night/
Sunday morning (Oct. 28/29).  Since most of us feel that simply setting the
system time back by an hour is ugly, I offer the following alternative.  It
won't solve everybody's problems with time correction (see the warnings that
follow), but it's better in many ways than just setting the clock back. 

Extract the following into a file, called, perhaps, FALLBACK.MAR :

	.entry	start, ^m<>
	$cmkrnl_s fixit
	movl	#1, r0
	ret

	.entry	fixit, ^m<>
	movl	#1440000, g^exe$gl_timeadjust
	movl	#75000, g^exe$gl_ticklength
	movl	#1, r0
	ret
	.end	start

Then

$ macro fallback
$ link fallback+sys$system:sys.stb/selective

(Note that this won't work under V4.x, and in fact you'll get undefined
symbols from the linker if you try it there.) 

Arrange for a time-scheduled batch job, running under an account with CMKRNL
privilege, to execute the resulting image file sometime during the dreaded
Saturday evening/Sunday morning period.  

What this does is to change the length of a 'tick' (the value that's added 
to the system binary quadword time upon every hardware clock interrupt, which
occurs every 0.01 seconds) from 0.01 seconds to 0.0075 seconds (three-fourths 
of its normal value) for a period of four hours.  Thus, after four hours
have elapsed, the system time of day will have advanced only three hours.
At that time, system normal timekeeping will resume.  

CPU time accounting will not be affected, as this is done by counting 
hardware clock interrupts, and these will still be coming at 10-millisecond
intervals.  On the other hand, the recorded start and stop times for processes
WILL be affected.  So will creation and etc. dates on files.  But the time
will always be increasing, so you'll have no cases where, for example, an
object file is apparently created before its corresponding source, or a user
apparently logs out before logging in.  

Problems:  

Device timeouts will be "stretched", as device timeouts are driven
by a timer queue element which comes due once each second, *as determined by
the quadword binary time*.  So if you have a device whose driver specifies,
say, a three-second timeout, the driver will behave as if the value had been
changed to four seconds.  These timeouts have an accuracy (if you can call it
that) of -1/+0 seconds anyway, so I wouldn't fuss about this.  

More critically, $SETIMR and related requests will be affected.  Regardless of
whether requested via delta or absolute times, processing of timer queue
elements depends on the system absolute time, and we're slowing down the
progression of this without fixing up the timer requests that were based on
delta time (as is done when you do a SET TIME).  

One area where this could be a real problem is in DECnet, where timed requests
are used to trigger "hello/test" messages and to report link failures if such
messages aren't received.  (Many of you will remember the DECnet circuit
exceptions that occurred in early V4 releases when the system time was set
ahead by any appreciable amount.)  The timers on the receipt of these messages
are, by default, three times the length of the ones that cause the messages to
be sent, and so slowing the clock by only 25% should be safe. 

(This is one reason for choosing these particular parameters for the
adjustment.  The adjustment could be made over a much shorter period, all the
way down to an hour, but the faster you shift the clock, the more of these
types of problems.)

HOW IT WORKS:

When the hardware clock interrupt occurs, the value of EXE$GL_TICKLENGTH is
added to the system quadword binary time.  Then, if EXE$GL_TIMEADJUST is
nonzero, it is decremented; if the result is zero, EXE$GL_TICKLENGTH is
set to its standard value, obtained from EXE$GL_SYSTICK.  

Under normal operation, EXE$GL_SYSTICK and _TICKLENGTH both contain 100,000 
(the number of 100-nanosecond intervals in 10 milliseconds -- the hardware 
clock interrupt occurs every 10 mils, and the quadword binary time is kept in
100-nanosecond units), and EXE$GL_TIMEADJUST is 0.  (See routine EXE$HWCLKINT, 
at and after the label 20$, in module TIMESCHDL, facility SYS.)

What we are doing here is setting _TIMEADJUST to the number of hardware
clock ticks we expect to get in four hours (4 * 3600 * 100), and _TICKLENGTH
to three-fourths of its normal value.  So over a period of four hours we
add just three hours' worth of 100-nanosecond units to the system quadword
time.  At the end of the four hours, _TIMEADJUST has been decremented to 0,
so _TICKLENGTH is restored to its normal value.  

Of course, these fields can be exploited for other purposes.  For example, if
the clocks on the various nodes in your cluster tend to drift, you could
declare one machine the master timekeeper and come up with some software to
automatically trim the others' clocks to match (something like the way the
power companies are supposed to provide an average of 60 cycles per second over
the long term, though not necessarily in the short term).  If you have a VAX
that's used in astronomy (pointing telescopes?), it would be fairly trivial to
set it up to keep sidereal time. And, of course, you have more than enough
information to write a SPRING_FORWARD program... 

	--- Jamie Hanrahan, Simpact Associates, San Diego CA
Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG 
Internet:  jeh@simpact.com, or if that fails, jeh@crash.cts.com
Uucp:  ...{crash,scubed,decwrl}!simpact!jeh

