Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!bellcore!faline!ulysses!gatech!mcnc!seismo!ll-xn!ames!ucla-cs!wales
From: wales@ucla-cs.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: More on date not advancing at midnight
Message-ID: <4817@shemp.ucla-cs.UCLA.EDU>
Date: Wed, 4-Mar-87 20:06:03 EST
Article-I.D.: shemp.4817
Posted: Wed Mar  4 20:06:03 1987
Date-Received: Fri, 6-Mar-87 23:40:10 EST
Sender: root@ucla-cs.UCLA.EDU
Reply-To: wales@LOCUS.UCLA.EDU (Rich Wales)
Organization: UCLA Computer Science Department
Lines: 29

I found that the date *does* advance at midnight on a Leading Edge Model
D with MS-DOS 3.10.

Further, the date advances at midnight on my system when I boot it with
an MS-DOS 3.10 from Leading Edge (whereas it doesn't advance when I run
the MS-DOS 3.2 that came with my system).  Hence, the problem wouldn't
appear to be in my system's BIOS.

I'm forced to the conclusion that either MS-DOS 3.10 (does this mean the
same thing as "MS-DOS 3.1"?) doesn't have the "midnight" bug and MS-DOS
3.2 does -- or that Leading Edge fixed the "midnight" bug in the version
of MS-DOS 3.10 that they distribute.

The Phoenix BIOS in the Leading Edge Model D *increments* the "midnight"
flag at 00470H (unlike the Award BIOS in my PC, which simply sets this
flag to 1).  However, when I wrote a larger value into 00470H via DEBUG,
the Leading Edge MS-DOS 3.10 still only advanced the date by one day.
Hence -- as someone pointed out -- an idle Leading Edge system that
didn't do at least *one* "get the date" operation per day could lose
track of the date.

I haven't tried "stress-testing" the Leading Edge to see if it misses a
day if there's lots of disk activity going on at the moment the clock
flips over.

-- Rich Wales // UCLA Computer Science Department // +1 213-825-5683
	3531 Boelter Hall // Los Angeles, California 90024-1600 // USA
	wales@LOCUS.UCLA.EDU   ...!(ucbvax,sdcrdcf,ihnp4)!ucla-cs!wales
"Sir, there is a multilegged creature crawling on your shoulder."