nathan@mit-eddie.UUCP (11/21/87)
This is a question about the standard bug that many people know
about regarding the date maintained in memory on standard
pc's and many clones. If your computer is on when midnight comes
around, the date will not be changed. I don't know whether this
always happens or only sometimes.
I've got a program which could be left running for many days
for which the date is important.
Does anybody have any simple solution that they've been using?
E.g. replacing the interrupt handler with one of your own
which does the right thing when midnight comes around. The only
problem with this is that the memory locations used by different
models for storing the date and time are bound to change.
In addition does anybody know under exactly what circumstances
this bug will or will not show up?
Thanks,
--
Nathan Glasser
fnord nathan@{mit-eddie.uucp, xx.lcs.mit.edu}
"A tribble is the only love that money can buy."
Presently there is insufficient evidence to conclude that tribbles spread AIDS.berger@clio.las.uiuc.edu (11/22/87)
I thought that bug was fixed after PC-DOS 2.0. Are you running a
later version, and have you confirmed that the bug is still present?
Mike Berger
Center for Advanced Study
University of Illinois
berger@clio.las.uiuc.edu
{ihnp4 | convex | pur-ee}!uiucuxc!clio!bergercuddy@convex.UUCP (11/23/87)
nathan@mit-eddie.UUCP writes: > This is a question about the standard bug that many people know > about regarding the date maintained in memory on standard > pc's and many clones. If your computer is on when midnight comes > around, the date will not be changed. I don't know whether this > always happens or only sometimes. As a former clone salesman/service tech, I have seen this bug. fortunately, there are three ways to fix this. 1: write an interrupt driver (yech!) 2: make your program re-set the date/time from the multi-function board's clock 3: get a copy of a good BIOS-- like PHOENIX. We always used it in the clones we sold. It's one of the best if not the best. I'ts even faster than IBM's (not saying much). this BIOS does not have the data bug. My first clone had this very bug-- it was a "Super Bios" and then a "MEGA" bios. both standard bad Taiwan BIOS's. when I got my PHOENIX BIOS machine, It solved my problem. you should be able to pick one up for ~$30us. Mike Cuddy CONVEX Computer Corp. 701 N. Plano Rd. Richardson, TX 75081
manes@dasys1.UUCP (Steve Manes) (11/23/87)
In article <7457@eddie.MIT.EDU>, nathan@eddie.MIT.EDU (Nathan Glasser) writes: > > This is a question about the standard bug that many people know > about regarding the date maintained in memory on standard > pc's and many clones. If your computer is on when midnight comes > around, the date will not be changed. I don't know whether this > always happens or only sometimes. > Does anybody have any simple solution that they've been using? Yes, although I believe that DOS 3.2 fixed this problem (I could be wrong; I still use 3.1). The problem lies in a "sticky flag" maintained by the BIOS timer in the ROM_BIOS_DATA segment. The structure of this segment is: ROM_BIOS_DATA SEGMENT @40h org 6Ch timer_low dw ? ; count up to 65535...(18.2x/sec) timer_hi dw ? ; then increment this (every hour) until... timer_ofl db ? ; we hit midnight and we inc' this. ROM_BIOS_DATA ENDS Whenever DOS calls BIOS to read the current real-time clock, it runs Interrupt 1Ah (see Tech Ref) and a single line of code that is executed during any TIME_OF-DAY "read time" call: mov timer_ofl,0 ; get overflow and reset flag In other words, every time Int 1Ah is called to read the time, whether from the DOS TIME/DATE routines or from your own homebrew to count the number of timer ticks, 'timer_ofl' is reset to zero and its previous contents returned in AL by Int 1Ah. The sticky widget: DOS needs this flag so it knows that the date has rolled over. If your application calls Int 1Ah before DOS gets it (and remember that this flag is set only ONCE every 24 hours and read only ONCE and then reset) DOS will simply roll the clock over but not the day. There are a few fixes that come to mind but the easiest by far is to write your own Int 1Ah replacement that DOESN'T reset 'timer_ofl'. Fortunately, this is an easy task since Int 1Ah doesn't do very much. What I do is use this routine whenever I need to read the timer block: push es mov ax,40h mov es,ax mov ax,word ptr es:[6Ch] mov my_timerlo,ax mov ax,word ptr es:[6Eh] mov my_timerhi,ax pop es That eliminates the problem. -- +----------------------------------------------------------------------- + Steve Manes Roxy Recorders, Inc. NYC + decvax!philabs!cmcl2!hombre!magpie!manes Magpie BBS: 212-420-0527 + uunet!iuvax!bsu-cs!zoo-hq!magpie!manes 300/1200/2400
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (11/24/87)
In article <7457@eddie.MIT.EDU> nathan@eddie.MIT.EDU (Nathan Glasser) writes: ... |I've got a program which could be left running for many days |for which the date is important. As far as I can tell, if you interrogate the date via DOS call once every 24 hours, the date will stay correct. Therefore if you use a DOS call to get the time in one of the outer loops of your program the date should stay correct. Perhaps once every few hours to be sure you don't do over 24. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
leonard@bucket.UUCP (Leonard Erickson) (11/25/87)
The bug *always* occurs. There's a discussion of it in Norton's Programmers Guide to the PC. My solution on PCs and XTs is to update the date & time from the clock card before any critical points. "shell" out and run GETCLOCK (or your clockcard's equivalent). On ATs, I've got a Turbo Pascal program that does the same thing with the AT onboard clock. Source code (Turbo release 3.1a or release 4.0) is available if you send me a bang path to mail it over. I'm planning to extanded my AT program to work on PCs with AST compatible clock cards (most of the ones I've seen!). When I get that working, I'll post source and executable. -- Leonard Erickson ...!tektronix!reed!percival!bucket!leonard CIS: [70465,203] "I used to be a hacker. Now I'm a 'microcomputer specialist'. You know... I'd rather be a hacker."
creps@silver.bacs.indiana.edu (Steve Creps) (11/27/87)
In article <598@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes: >The bug *always* occurs. There's a discussion of it in Norton's Programmers >Guide to the PC. I saw Norton's comment, and it says DOS 2.00 didn't consistently update the date on the midnight signal, but that 2.10 and all other versions do. I could still swear that it still happens in 3.2, but I haven't done any scientific checks on this. - - - - - - - - - Steve Creps on the VAX 8650 running Ultrix 2.0-1 at Indiana University. creps@silver.bacs.indiana.edu "F-14 Tomcat! There IS no substitute."
leonard@bucket.UUCP (11/30/87)
In article <436@silver.bacs.indiana.edu> creps@silver.UUCP (Steve Creps) writes: <In article <598@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes: <>The bug *always* occurs. There's a discussion of it in Norton's Programmers <>Guide to the PC. < < I saw Norton's comment, and it says DOS 2.00 didn't consistently update <the date on the midnight signal, but that 2.10 and all other versions do. <I could still swear that it still happens in 3.2, but I haven't done any <scientific checks on this. Read farther. There are _two_ date bugs. The first is the one you are thinking of. The second exists in _all_ versions of DOS and is more subtle. At midnight the time count rolls over AND SETS A *FLAG* to indicate that the next time DOS reads the date or time the date should be incremented. The problem appears if you leave your machine running over the weekeend (as an example). Friday night at midnight the flag gets set. Saturday at midnight it gets "set" again. Ditto for Sunday. Now you come in on Monday morning and write a file (or check the time or date). Dos checks the flag and sees that it is set. So it reads the stored date (which is still set to FRIDAY!) and increments it by *ONE*. Thus the machine cheerfully reports that it is Saturday..... Only "fix" is to frequently read the clock while the machine is "idle", or run a program to set the DOS date/time from a hardware clock. -- Leonard Erickson ...!tektronix!reed!percival!bucket!leonard CIS: [70465,203] "I used to be a hacker. Now I'm a 'microcomputer specialist'. You know... I'd rather be a hacker."
dons@killer.UUCP (12/01/87)
In article <436@silver.bacs.indiana.edu>, creps@silver.bacs.indiana.edu (Steve Creps) writes: > In article <598@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes: > >The bug *always* occurs. There's a discussion of it in Norton's Programmers > >Guide to the PC. > > I saw Norton's comment, and it says DOS 2.00 didn't consistently update > the date on the midnight signal, but that 2.10 and all other versions do. > I could still swear that it still happens in 3.2, but I haven't done any > scientific checks on this. I ran MS-DOS 2.11 on my PC compatible for two years without seeing this problem. When I upgraded to 3.2 about a year ago to make better use of my new 30 MB hard disk, it appeared. I had seen this a long time ago on a Wang PC, probably running 2.0. From what I have read, MS fixed this in going from 2.0 to 2.1 but it mysteriously reappeared in later versions. They probably fixed it again in 3.21 (I hope). I have seen a technical explanation which I am unable to repeat, but I found the following file on a bulletin board earlier this year. Put this file (CLOCKFIX.SYS) in the root directory and put the line "DEVICE = CLOCKFIX.SYS" in your CONFIG.SYS file. I believe this patches the timer tick interrupt vector to properly handle the midnight flag. I have been using this since early this year and have had no problems. UUENCODED file follows: begin 644 clockfix.sys M_____PB ,@ ] $-,3T-+)" @ ^ 6L :P!K . 9@!P ' A "$ M ' < NB1X2 "Z,!A0 R_Q04U%25E=5'@8NQ1X2 (I' CP+=QB+3Q+$?PX. M'[X: +0 _ #\/\DN #ZPBX X'K [@ <4>$@")1P,''UU?7EI96UC+)HL% MHQ8 )HM- B:+502P//;EM0 #P;EP%XO:]^&+R+!D]N<#R(/2 +< \N#T@"2 MD;L+Z??CA]&2]^,#P8/2 )*[!0#V\XK(M0"*Q)B2]_.+T(D.& "T <T:ZY S MP,T:.PX8 ',$_P86 (D.& "+P8O:T>+1T='BT=$#TQ/!DKD+Z??QB]@SP/?Q MB].YR #W\8+Z9'(#@NID]8K:T="R -'2N3P ]_&*^O;QAN!0H18 JUBKB\.K MZ3+_Q!X2 ";'1PX^ 2:,3Q#I(?\ 8 end -- Don Simoneaux Phone: (214) 964-1859 3605 Interlaken Dr. Plano, TX 75075 USENET: ...ihnp4!killer!dons
awylie@pyr1.cs.ucl.ac.uk (12/04/87)
I have a Taiwanese XT clone with some strange BIOS and MSDOS 3.2 and the bug has annoyed me some time. This is NOT the 'subtle' bug mentioned in another reply, but a simple non-increment of the date at midnight. This wreaks havoc with MAKE! I shall try CLOCKFIX.SYS tonight. Thanks very much to the poster, his was the only really useful solution proposed. Andrew Wylie University of London Computer Centre awylie@uk.ac.ucl.cs