Thanks for all who replied. Some of you gave me good advice that lead me to
the solution.
The problem was related to the use of the ECU utility which changes the
hardware clock setting in some way. In fact, after running ECU, the ARC asks
you to reset the time and you don't have the opportunity to save the changes
(But ECU already misadjusted the clock)
My Advice: If you ever have to play with ECU and run a DATABASE. Reboot in
Single User mode and reset the date/time on your system before restarting
your database and entering multi-user mode.
-------------------------------------------------------------------------------
ALSO:
Someone mentionned to remenmber that genvmunix DOES NOT incorporate the
clock patch... But rebooting with genvmunix is not an issue as the bug only
0occured in the month of march.
I still have a couple of questions. If anyone bother to answer:
1) I noticed that when I change the date at the OS level, the hardware clock
setting changes. The reverse is also true. I presume that the software clock
iws based on the hardware clock setting (as a reference). Can someone
explain why setting the OS clock change the Harware clock ?
2) On my alpha server 400, there is a 'date' command at the >>> prompt that
I can use to set the hardware clock. That command does not exist on my 2100
firmware. What is the way to set the clock ? I tried the ARM software, but
there is no way to SAVE the setting...
3) How can I synchronize the OS clock with the Harware clock (Have the same
value in both)
4) I tried to rebuild the GENVMUNIX kernel with doconfig -c GENERIC (afetr
reading the manual...) and I got a 11Mb kernel ! I compared it against the
original genvmunix from DEC which is 7.5Mb. While rebuilding the kernel,
got a message similar to <NOTE: Building the kernel for multiple cpu defined>.
Why is that kernel so BIG ? I decided NOT to use it...
Thanks
Thank you
Received on Thu Jul 11 1996 - 17:06:22 NZST