bobvan (10/29/82)
This is an appropriate time of year for me to confess to a rather
questionable hack that I put into our Berkeley UNIX kernel some time
ago. We must run VMS at least once per day, sometimes twice per day.
Those of you who've done this know that the time of day has to be reset
each time we change operating systems. It really is a pity too. Code
in machdep.c goes to great lengths to keep the hardware clock register in
the same form as VMS. However, UNIX uses GMT and VMS uses local time.
We had to set the clock ahead or back 6 hours every time we changed
operating systems.
This lead to operating screw ups on at least two occasions. The clock
would accidentally be set off by an hour or a day, and it was never
possible to keep the clock set accurately. Being much more adept at
changing UNIX than VMS, I slipped the appropriate +6 and -6 into the
code in machdep.c and all has been fine until now.
It is appropriate to tell you about this now because I have to change
the 6's to 5's this weekend when we go from CDT to CST. The
alternative is to put all of that ugly "is this the last Sunday of
October" code from ctime.c into the kernel. Neither solution is very
good (any better ideas?). Even if I get hit by a beer truck and the
kernel never gets changed again, we can go back to resetting the clock
twice per day if we have to.
I've included diff's for others in the "two OS" boat with us.
Only constructive flames, please.
(look! An oxymoron! ^^^^^^^^^^^^^^^^^^^)
Bob Van Valzah
(...!decvax!ittvax!tpdcvax!bobvan)
*** machdep.old.c Thu Sep 9 16:51:44 1982
--- machdep.c Thu Sep 9 17:08:27 1982
***************
*** 187,193
clkinit(base)
time_t base;
{
! register unsigned todr = mfpr(TODR);
long deltat;
int year = YRREF;
--- 187,198 -----
clkinit(base)
time_t base;
{
! /*
! * RAV todr is kept fudged so date doesn't have to be set
! * when going to VMS. Change "timezone-60" to "timezone"
! * (both here and below) when we go off daylight savings time.
! */
! register unsigned todr = mfpr(TODR)+(timezone-60)*60*100;
long deltat;
int year = YRREF;
***************
*** 268,274
yrtime -= secyr;
year++;
}
! mtpr(TODR, TODRZERO + yrtime*100);
}
#ifdef PGINPROF
--- 273,279 -----
yrtime -= secyr;
year++;
}
! mtpr(TODR, TODRZERO + yrtime*100 - (timezone-60)*60*100);
}
#ifdef PGINPROFswatt (10/30/82)
We used to have that same problem too. I got around it by having our own shutdown procedure that printed a reminder to the console. If I really got bothered by this, I think I would leave the kernel alone and change instead: /etc/shutdown: to take an argument to mean convert to VMS time before killing it. /etc/rc: to set the date back to UNIX time You could get slightly clever by having the program run from /etc/rc first check the modification dates on some active system files to make sure UNIX has been down for at least an hour, so it won't reset the time when rebooting from a crash. We do something like that now to maintain an automatic system downtime log. Since all this is done from user mode, you can make them as clever as you like about Daylight Savings Time. Or, you could finesse the problem by not running VMS so often ... - Alan S. Watt
bobvan (10/30/82)
Alan Watt's suggestions are good ones that I must admit I hadn't thought of. However, we would have a hard time making the program run by /etc/rc smart enough. It could easily get our regular weekday morning down time confused with VMS time and set the clock back when it shouldn't. We go down weekday mornings from 5:30 to 7:00 to avoid power line glitches. A power line monitor has shown 200+ volt spikes on our 115 volt lines. There must be some large industrial users near us that kick in their big machines about that time of day. Another theory is that the power company switches in big caps to compensate for the large inductive loads that are about to hit the lines. Our VAX 780 is pretty good about ignoring these spikes, but sometimes they cause mysterious disk write errors and that does who knows what to our filesystems. Nobody wants to use the machine in that time period, so we just halt it. I can't believe that these spikes are very good for the circuitry inside the VAX. We've yelled loudly at the local power company (Comical Edison) and they have yet to do anything about it. This site will be moving soon so we haven't bothered to buy a UPS or a filtering system. Have any other sites had problems with spikes at the same time every weekday? The gist of this is that the program would have to take into account the (possibly offset) time of day as well as the staleness of a filesystem to determine if VMS had run. Alan's scheme would have preserved the purity of the kernel, but would have involved changing more existing code and writing more new code. If Alan's scheme had occurred to me, I would have had a hard time choosing. Shortness of time probably would have lead me to sacrifice kernel purity, though. What would you have done? Bob Van Valzah (...!decvax!ittvax!tpdcvax!bobvan)