keith@sscsu.Stanford.EDU (Keith Rich) (01/04/91)
I find that the date/time is wrong whenever I reboot. I didn't have this problem until after New Year's. The first reboot after New Year's seemed to lose a day. This happened on the second, but it said the first. Now I have reset the date (using smit), but when I reboot, the clock is about five hours slow (I tried several times). I am running AIX 3.1 rev 1.3, and I have also seen the problem on AIX 3.1 rev 1.2 (is there a standard way to say this?). When I set the date (using either smit or just date), it replies with: date: The time service is not available on your system. So, does anyone know how I can fix this? Keith Rich (keith@sscsu.stanford.edu)
mcguire@math.uiowa.edu (Charlie McGuire) (01/04/91)
In article <1991Jan3.200740.16131@portia.Stanford.EDU>, keith@sscsu.Stanford.EDU (Keith Rich) writes: |> |> I find that the date/time is wrong whenever I reboot. I didn't have this |> problem until after New Year's. The first reboot after New Year's seemed |> to lose a day. This happened on the second, but it said the first. Now |> I have reset the date (using smit), but when I reboot, the clock is about |> five hours slow (I tried several times). I am running AIX 3.1 rev 1.3, |> and I have also seen the problem on AIX 3.1 rev 1.2 (is there a standard |> way to say this?). I had the same problem on 3003. The date was 24hrs behind when I came in to work on 1/3. I reset it using the date command, but haven't rebooted yet. If your are 5 hrs slow, check your timezone. *************************************************************************** * Charlie McGuire | INTERNET: mcguire@math.uiowa.edu * * Systems Programmer | mcguire@cs.uiowa.edu * * Computer Science Dept. | * * The University of Iowa | PHONE: (319) 335-2730 * ***************************************************************************
lerman@stpstn.UUCP (Ken Lerman) (01/05/91)
In article <1991Jan3.200740.16131@portia.Stanford.EDU> keith@sscsu.Stanford.EDU (Keith Rich) writes:
.
.I find that the date/time is wrong whenever I reboot. I didn't have this
.problem until after New Year's. The first reboot after New Year's seemed
.to lose a day. This happened on the second, but it said the first. Now
.I have reset the date (using smit), but when I reboot, the clock is about
.five hours slow (I tried several times). I am running AIX 3.1 rev 1.3,
.and I have also seen the problem on AIX 3.1 rev 1.2 (is there a standard
.way to say this?).
.
.When I set the date (using either smit or just date), it replies with:
.
.date: The time service is not available on your system.
.
.So, does anyone know how I can fix this?
.
.Keith Rich (keith@sscsu.stanford.edu)
I had a similar problem. After the start of the new year, I found
that my machine's time was off by one second. I (mistakingly, I
guess) attibuted to the leap second which was added by the time gods
this year. :-)
KenCCVJ@lure.latrobe.edu.au (01/09/91)
In article <1991Jan3.200740.16131@portia.Stanford.EDU>, keith@sscsu.Stanford.EDU (Keith Rich) writes: > I find that the date/time is wrong whenever I reboot. I didn't have this > problem until after New Year's. The first reboot after New Year's seemed > to lose a day. This happened on the second, but it said the first. Now > I have reset the date (using smit), but when I reboot, the clock is about > five hours slow (I tried several times). I am running AIX 3.1 rev 1.3, > and I have also seen the problem on AIX 3.1 rev 1.2 (is there a standard > way to say this?). > > When I set the date (using either smit or just date), it replies with: > > date: The time service is not available on your system. > > So, does anyone know how I can fix this? > > Keith Rich (keith@sscsu.stanford.edu) We have had problems too - no error messages, just the date going 5 hours behind on reboot, since New Year. We have been told that it will be fixed "properly" in update 2003 (I too am confused about the level numbering - currently its 01.01.0001.0003, I think 2003 referrs to 01.01.0002.0003?!). This revision is expected in Australia in about two weeks Vicki Jordan Computing Services, La Trobe University Bundoora, Vic. 3083, Australia AARNet: ccvj@lure.latrobe.edu.au
jfh@greenber.austin.ibm.com (John F. Haugh II) (01/10/91)
In article <4941@lure.latrobe.edu.au> CCVJ@lure.latrobe.edu.au writes: >We have had problems too - no error messages, just the date going 5 >hours behind on reboot, since New Year. We have been told that it >will be fixed "properly" in update 2003 (I too am confused about the >level numbering - currently its 01.01.0001.0003, I think 2003 referrs >to 01.01.0002.0003?!). The numbering scam (er, "scheme") is that 1xxx level PTFs are weekly (bi-weekly, semi-moon-phase, whatever) updates. The 2xxx level PTFs are periodic relative updates. You must have the previous level in order to apply that PTF. So, for 2003 to be used on your system you must have applied either 2002 (recursively) or 3002. Notice the way that last digit increments. The 3xxx level PTF is cummulative since the beginning of time. You can apply 3003 to GOLD, 3001, or 3002. Thus, 3003 and 2003 will get you to the same place iff you are running 3002 already. As for the date and time problem - did you ever check your timezone as someone else had suggested? >This revision is expected in Australia in about two weeks Say "G'day" to Peter Mays at NSD/Australia if you have the good fortune to run in to him. -- John F. Haugh II | This space intentionally | MaBellNet: (512) 838-4330 SneakerNet: 809/1C079 | left blank ... | VNET: LCCB386 at AUSVMQ BangNet: ...!cs.utexas.edu!ibmchs!auschs!snowball.austin.ibm.com!jfh (e-i-e-i-o)
robin@batcomp.austin.ibm.com (Robin D. Wilson) (01/10/91)
In article <4941@lure.latrobe.edu.au> CCVJ@lure.latrobe.edu.au writes: >will be fixed "properly" in update 2003 (I too am confused about the >level numbering - currently its 01.01.0001.0003, I think 2003 referrs >to 01.01.0002.0003?!). 2003 will list as 03.01.0003.00xx. This is how it works: A) 2xxx (2 thousand) level updates indicate an update that only include those products that have been updated since the last update. (ie. they require a "prerequisite" of the immediately preceeding update level - in this case 3002.) B) 3xxx (3 thousand) level updates indicate an update that encompasses all updates from GA (golden/ship/general availability) and requires no prerequisites. C) x### (###=some 3 digit number like 001, 002, 003, etc.) is used to indicate the update number (ie. update #1, update #2, update #3, etc.). from the release level: 03.01.xxxx.xxxx ^ ^ ^ ^ | | | | | | | -- Indicates build level of the current update | | | (and is usually worthless to a customer). | | | | | -- Indicates the update number which correspondes to | | "C)" above. (ie. 2003 update, will list as 0003 | | here.) | | ----- Indicates the OS version (ie. 3.01). This will not change until the next release of the OS, (ie. 3.02). I hope this clears things up a bit... -- +-----------------------------------------------------------------------------+ |The views expressed herein, are the sole responsibility of the typist at hand| +-----------------------------------------------------------------------------+ |UUCP: robin%aixserv@uunet.uu.net | |USNail: 701 Canyon Bend Dr. | | Pflugerville, TX 78660 | | Home: (512)251-6889 Work: (512)823-3015 | +-----------------------------------------------------------------------------+
CCVJ@lure.latrobe.edu.au (01/11/91)
In article <4941@lure.latrobe.edu.au>, CCVJ@lure.latrobe.edu.au writes: > level numbering - currently its 01.01.0001.0003, I think 2003 referrs .oops, did anyone notice my typo - sb 03.01. Thanks for the explanatory postings (and, yes I did check the TIMEZONE). Vicki Jordan Computing Services, La Trobe University Bundoora, Vic. 3083, Australia AARNet: ccvj@lure.latrobe.edu.au