Dear All,
Thanks for all your replies......too many people to list so I have included some of the responses - the majority went along the following lines....
Cheers
AndyT
From: "Lavelle, Bryan" <Bryan.Lavelle_at_COMPAQ.com>
To: 'Andrew Tolmie' <Andrew.Tolmie_at_carltontv.co.uk>
Date: 03/01/00 16:09:52
Subject: RE: DATE ??
You are setting the date at the console level, YOU CAN NOT DO THIS for a
Compaq system running the Unix operating system, the time formats between
the console time and Unix time have been and always will be incompatible.
You can only set the time at single user mode.
Bryan
From: "Macfarlane, Fraser" <Fraser.Macfarlane_at_compaq.com>
To: 'Andrew Tolmie' <Andrew.Tolmie_at_carltontv.co.uk>
Date: 03/01/00 15:22:20
Subject: RE: DATE ??
Basically, its a feature!!!!!
See below for a full description
Any further issues - please log a call with us.
Regards
FRASER MacFARLANE
EMEA TCSC, Tru64 UNIX Support Group
COMPAQ Computer Limited
Tel: +44 (0)1189 160223
E-MAIL: Fraser.MacFarlane_at_compaq.com
Reason Digital UNIX year is offset 48 years from console time:
>
> One of the requirements for the TOY was the ability to detect whether
> another operating environment had changed the date set by UNIX. The
> reason this
> is a requirement is because UNIX time is all GMT in the kernel where VMS
and
> console time are implemented and stored as local time in the TOY chip. If
> UNIX simply used the TOY chip date, the offset between local time and GMT
could be
> present and not detected by UNIX upon boot.
>
> The offset UNIX uses was chosen to be as far away as possible from any
> other offsets while still being evenly divisible by 4.
>
It's not a problem, it's a feature. The console firmware has no reason to
need to know the date and time, but some bright firmware engineer got the idea
that the console should "tweak" the hardware time of year clock to try to make
it compatible between Windows NT and OpenVMS (yes, I know that there will not
be future support for Windows NT on Alpha), and in the process, they messed up
the representation for Tru64 UNIX. So, UNIX uses a range of values that are
offset sufficiently that the console firmware leaves them alone, but if you go
and set the date with the firmware, UNIX fixes it on reboot. Alas, as far as
I know, this isn't clearly documented anywhere (but of course, it should be,
so people who stumble on it can be told to read the fine manuals).
My advice is "don't mess with the date setting using the console firmware, it
has no idea how operating system software maintains the time of year clock."
Tom
Dr. Thomas P. Blinn + UNIX Software Group + Compaq Computer Corporation
110 Spit Brook Road, MS ZKO3-2/W17 Nashua, New Hampshire 03062-2698
Technology Partnership Engineering Phone: (603) 884-0646
Internet: tpb_at_zk3.dec.com Digital's Easynet: alpha::tpb
ACM Member: tpblinn_at_acm.org PC_at_Home: tom_at_felines.mv.net
From: "Wolfers, Ray" <wolfers_at_rlmsystems.com.au>
To: "'Andrew Tolmie'" <Andrew.Tolmie_at_carltontv.co.uk>
Date: 03/01/00 22:57:58
Subject: RE: DATE ??
This is not an error.
What you are seeing is the standard behaviour that has always existed on
Alpha architecture running OSF1/DECUnix/Tru64.
According to Compaq the Firmware Clock is interpreted by UNIX using an
offset. This results in the 48 year discrepancy that you have noticed.
Compaq's recommendation is to set date/time from within UNIX and never at
the firmware level. This is a design feature of UNIX and has something to do
with time offset from GMT (Compaq's explaination, not mine).
If you use VMS or NT then this is not a problem, as these O/S'es interprete
the firmware clock correctly.
Cheers,
Ray Wolfers
r.wolfers_at_rlmsystems.com.au
From: "A Stauber" <AStauber_at_ConwayCorp.NET>
To: "Andrew Tolmie" <Andrew.Tolmie_at_carltontv.co.uk>
Date: 03/01/00 20:33:15
Subject: Re: DATE ??
Hi Andrew - Here is a response from a guy at Compaq to a person on the
AlphaNT list with a similar problem.
Cheers,
Craig A. Stauber
ASTAUBER_at_CONWAYCORP.NET
Hello Charles,
This is not a Y2K problem. It is a result of the fact that different
operating systems store their dates in different formats, and this
difference was visible forever in Alpha systems -- long before this week.
One of the many variables that the SRM firmware maintains is OS_TYPE, which
determines whether the SRM thinks that the target OS is VMS, Unix, or
Windows NT. Changing this variable will cause SRM to change the value in
the hardware clock, and also change the algorithm by which it displays the
value in the clock, reflecting the algorithm favored by the new target OS.
If you set the OS_TYPE to NT, then the year will not get set to 2048 after
booting and shutting down NT. The year 2048 is the result of diplaying
current NT time in VMS or Unix (I forget which) format.
The only way you can get to where you got by being savvy enough to type
'arc' to start AlphaBIOS from within SRM. This will work, but it is not for
mainstream consumers.
Thanks,
_Scott
·······································································
Scott Bingham Compaq Computer Corporation
NTSSS DECwest Engineering 14475 NE 24th St, Bellevue, WA
"Espresso, Habaneros, Lapsang Souchong, Merlot, Semi-sweet,
and way too much garlic."
·······································································
ORIGINAL MESSAGE FOLLOWS......
From: Andrew Tolmie
To: tru64-unix-managers_at_ornl.gov
Date: 02/01/00 11:30:46
Subject: DATE ??
Dear All,
HAPPY NEW YEAR
Alphaserver 4100 running 4.0d firmware rev 5.1..........erm....PK4.
My problem (well it's doesn't appear to be a problem!?!) is this........
The system was shutdown over New Year (Halted with power left on) - bootup cycle is fine...everything works fine, correct date time and so on. However have noticed that when system is in the halted state it reads the correct Day, Month, Time BUT the year is 2048 ? Have reset the Year to the correct one and bootup is fine - again everything works as it should. If I then shut the system down again...it then reads Year of 2048 again !?#! until I reset it, reset the MC with the Halt switch on and then boot....it's OK!!
I have the same problem on a system that was left running over the whole period (The New Year) - again everything seems to be fine!
Has anybody else experienced this problem?
Cheers
AndyT
IT'S A SPANKING NEW YEAR, A NEW MILLENNIUM AND WHAT AM I DOING.....LOOKING AT A BUNCH OF UNIX BOXES - I HOPE IT GETS BETTER THAN THIS!
Received on Tue Jan 04 2000 - 10:27:55 NZDT