iisakkil@xaloc.tky.hut.fi (Mika R Iisakkila) (12/28/90)
silver@xrtll.uucp (Hi Ho Silver) writes: > The problem you're experiencing is caused by the fact that most (all?) > versions of DOS are too dumb to increment the date when the clock turns over > midnight. Actually, it isn't quite this stupid - there's usually a one bit 'date changed' -flag, which is set at midnight. If it's set, the bios calls add one day to the date. So you'll have to have the system up without rebooting for two successive midnights to lose a day. -- "Kyll{." - Del Monte -mies
greg@turbo.atl.ga.us (Greg Montgomery) (01/04/91)
I'm having a problem with my system's clock. Sometimes when I'm running
a program overnight, the date is not updated. I'm using a routine from
BetterBasic that gets the DOS date, so I think the problem is the DOS
clock is not being updated. I need to know when and how the DOS clock is
updated. Shouldn't it be updated everytime I call it?? Or is the BIOS
clock the one not being updated? However, if I reboot the computer, the
date is correct and I don't have to change it manually. I'm thinking
about writing an asm routine that the Basic program will call and the
routine will set a global variable to the date returned by the BIOS
clock (int 1ah, function 04h). Is this my only alternative?? It's been
awhile since I've written asm code, so I'm hoping to avoid this! <grin>
Thanks in advance for the help... Oh yeah, the computer is a Acer 286
running MS-DOS v3.30 or v3.31.
Greg
----
Greg Montgomery | Montgomery Consultants, Inc. | Atlanta, Georgia, U.S.A
Internet: greg@turbo.atl.ga.us | Home of the '96
UUCP: {rutgers,ogcise,gatech}!emory!turbo!greg | Olympics!madams@ecst.csuchico.edu (Michael E. Adams) (01/04/91)
I'm no pro on this but I do remember a few things that might help.
When DOS is booted, it gets the time and date from the CMOS clock.
Or, if "time" is in the autoexec.bat file, then it prompts the user
to input the time.
In either case, DOS keeps a copy of the time/date in it's own working
area & updates it by itself. When the DOS clock hits midnight
a flag is set & the DOS date is advanced. The problem for machines
that are left running is that, DOS can only "see" one midnight!
So if you boot your machine on Friday morning, DOS will roll the date
that night, but DOS will be two days short on Monday morning!
The other problem is that some OEM DOS versions, like the one that
came with my Epson, failed to check the midnight flag. Thus,
the DOS date is not advanced at all. Remember, the CMOS clock is
still running correctly, so when you reboot your machine DOS resets
with the right time & date.
When I bought my Epson I thought it was defective because of this date
roll over problem. I found that a new DOS cleared up the symptoms.
I first noticed this bug in 1986 when I started using the Make
utility from MS 'C'. "Make" checks the date stamp on source files
to see if they need to be re-compiled. I work late nights at home
and so I frequently compile a program at around 11:30 pm, make
changes to the source files, and then recompile sometime after midnight.
Without a correct date roll over, the "Make" utility
can not determine whether or not the source file is newer than the
compiled version, and I end up spending hours looking for fixed bugs!
Note: All of Borlands IDE Makes use file date stamps also.
(___) | Michael E. Adams
(o o) | Custom Computer Programming
/-------\ / | P.O. Box 5027
/ | ||O | Chico, California 95927-5025 U.S.A.
* ||,---|| |
~~ ~~ | internet: madams@cscihp.ecst.csuchico.edu
No BULL bandwidth |RMC@psuvm.psu.edu (Ron Crandall) (01/04/91)
Dug this out of the SIMTEL20 <MSDOS.INFO> archive. Haven't tried any of it. Maybe you can glean something out of it. ********** begin forwarded notes ************** Path: rutgers!ucla-cs!wales From: wales@valeria.cs.ucla.edu (Rich Wales) Newsgroups: comp.sys.ibm.pc Subject: Re: Looking for TSR to fix date (LONG) Date: 15 Sep 88 19:59:03 GMT Reply-To: wales@CS.UCLA.EDU (Rich Wales) In article <350@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) asks about the "date rollover" problem on a PC running DOS 3.3 (i.e., the date doesn't get advanced at midnight). I believe this problem is due to a combination of DOS and the system's ROM BIOS. My system, for instance -- an XT clone with the Award BIOS (Version "XT 2.03") -- exhibited this particular problem with MS-DOS 3.2 -- but *not* with MS-DOS 3.1 or 3.3. I'm enclosing below a few messages which were sent out a while back about this problem. Use this material at your own risk, of course. Actually, there are *TWO* related problems known with regard to the proper advancing of the date. One is the problem you mentioned (i.e., the date doesn't change at midnight). The other problem (obviously seen only by people who don't have the first problem, or have it only intermittently) is that if the system is left continuously idle over two or more consecutive midnights, the date gets advanced by only one day. This latter problem has to do with the fact that DOS records the passage of a new day by *setting* (*not* incrementing) a flag that is supposed to get noticed the next time the system does something. ======================================================================== From: rde@ukc.ac.uk (R.D.Eager) Subject: Re: Date not advancing at midnight on my clone Message-ID: <2666@eagle.ukc.ac.uk> Date: 8 Mar 87 17:43:17 GMT Organization: U of Kent at Canterbury, Canterbury, UK I had this problem on MS-DOS 2.11 on a British PC clone. I also managed to fix it, but the nature of the fix means that it works ONLY for one version (and OEM implementation) of DOS. The BIOS time of day call (INT 1AH) is what DOS uses to get the time. This is used by the DOS kernel only to get the time of day. The call returns the time in CX/DX, and a flag (indicating date rollover) in AX. This flag is nonzero if the day has rolled over since the last call, and by definition is returned ONCE ONLY after a given midnight. Now, the real problem is that the OEM portion of DOS may also call the INT 1AH function, and many implementations do this to provide a timeout on disk access in order to make up for the lack of door latch status on IBM style floppy drives. The details don't matter, but a call from one of these just after midnight clears the rollover flag so that the DOS kernel never sees it. My solution was messy (and doesn't handle the case of an idle machine being left for a weekend), but it does work. First, scan thru the DOS file IO.SYS or IBMBIO.COM, looking to INT 1AH calls. Find the one that seems to do something with AX on return. Figure out from this code (easier than it sounds) the word where DOS obviously keeps the day number. Second, write a little intercept (TSR) routine for INT 1AH. Do nothing on the way in, but on the way out check AX. If it is nonzero, clear it and increment the DOS day number yourself. This WORKS. But, you need a different version for different versions and flavours of DOS (because the day number isn't always in the same place). It's a good idea to put some checks in to stop it being used on the wrong version and zapping some other word. -- Bob Eager rde@ukc.UUCP rde@ukc ...!mcvax!ukc!rde Phone: +44 227 66822 ext 7589 ======================================================================== From: jsa@kolvi.UUCP (Jari Salminen) Subject: DOS 3.20 bug Message-ID: <1139@kolvi.UUCP> Date: 25 Mar 87 15:36:21 GMT Organization: Helsinki University of Technology, Finland I noticed a really silly bug in MS-DOS 3.20 (maybe in PC-DOS 3.2 too). DOS doesn't change date after midnight !!!!!!!! ----------------------------------------------- And this is why: Code to read time (in DOS CLOCK$ device driver in IO.SYS) XOR AH,AH ; read Time-of-day from BIOS INT 1Ah MOV BX,DX ; Note! Timer-overflow-flag in AL is LOST ! MOV AX,CX ... some code to calculate time MOV AX,CS:[0E53] ; read OLD DATE ! STOSW ; and store date to buffer However, few bytes later in drive device driver in the same IO.SYS is the correct version to handle the same interrupt: XOR AH,AH INT 1Ah OR AL,AL ; check if timer overflow has occurred JZ over ; if not, skip date updating INC WORD PTR CS:[0E53] ; Update date over: ... So, if the first command you're giving just after midnight has something to do with time ('dir', file saving etc.), the date update is lost. BUT, if you change drive or give command like 'dir a:' when A: is empty, the date is updated correctly !!!!! That bug was NOT in DOS 3.1, so it seems that Microsoft has done a good job bugging DOS 3.2 (remember all those other bugs in 3.2 :-). While waiting update, we should a) never work "Round Midnight" :-) b) reboot our systems at midnight (cause this bug in DOS does not affect to real time clocks) c) write a new clock device driver for DOS 3.2 I think I'll choose c) ! Jari -- Jari Salminen ! UUCP: jsa@kolvi.UUCP Helsinki University of Technology ! Otakaari 5 A ! SF-02150 Espoo, Finland ! tel: +358 0 4512918 ======================================================================== From: manes@dasys1.UUCP (Steve Manes) Subject: Re: Standard date bug Summary: The BIOS Timer Bug Message-ID: <2049@dasys1.UUCP> Date: 23 Nov 87 08:04:06 GMT Organization: The Big Electric Cat, NYC, NY 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 ======================================================================== From: dons@killer.UUCP (Don Simoneaux) Subject: Re: Standard date bug Summary: fix for date bug Message-ID: <2269@killer.UUCP> Date: 1 Dec 87 04:49:50 GMT Organization: The Unix(R) Connection, Dallas, Texas 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 ======================================================================== -- Rich Wales // UCLA Computer Science Department // +1 (213) 825-5683 3531 Boelter Hall // Los Angeles, California 90024-1596 // USA wales@CS.UCLA.EDU ...!(uunet,ucbvax,rutgers)!cs.ucla.edu!wales "No, the name of my ship is the _Lollipop_. It's a good ship." ******* end of forwarded notes ****************** ------------------------------------------------------------------------- Just Because I'm Paranoid Ron Crandall Doesn't Mean the World's PSU Office of Telecommunications Really Not Against Me... RMC@PSUVM.PSU.EDU (Internet) RMC@PSUVM.bitnet (Bitnet)
quimby@madoka.its.rpi.edu (Tom Stewart) (01/04/91)
madams@ecst.csuchico.edu (Michael E. Adams) writes: > >In either case, DOS keeps a copy of the time/date in it's own working >area & updates it by itself. When the DOS clock hits midnight >a flag is set & the DOS date is advanced. The problem for machines >that are left running is that, DOS can only "see" one midnight! >So if you boot your machine on Friday morning, DOS will roll the date >that night, but DOS will be two days short on Monday morning! > Well, MS-DOS 3.30 doesn't do that, nor does any standard 3.x/4.x MS-DOS that I've heard of. We've kept all of our machines up all the time for years, and have never had a date slipage problem. Quimby (mailer disfunctional, replies to: quimby@mts.rpi.edu, quimby@rpitsmts.bitnet)
silver@xrtll.uucp (Hi Ho Silver) (01/06/91)
In article <c748u1w163w@turbo.atl.ga.us> greg@turbo.atl.ga.us writes:
$I'm having a problem with my system's clock. Sometimes when I'm running
$a program overnight, the date is not updated. I'm using a routine from
$BetterBasic that gets the DOS date, so I think the problem is the DOS
$clock is not being updated. I need to know when and how the DOS clock is
$updated. Shouldn't it be updated everytime I call it?? Or is the BIOS
$clock the one not being updated? However, if I reboot the computer, the
You have two clocks in your machine. One is a clock that runs whether
it's turned on or not; this is the one you've called the "BIOS clock".
This is maintained in hardware; it's run by the same battery that keeps
your CMOS configuration information. The second one is a software clock
maintained by DOS. It's updated approximately 18.2 times a second; that's
the clock tick interrupt rate.
When you boot your computer, DOS reads the time and date from the hardware
clock. Under some versions of DOS, using the TIME command updates the
hardware clock. Other than that, the hardware clock is not used.
The problem you're experiencing is caused by the fact that most (all?)
versions of DOS are too dumb to increment the date when the clock turns over
midnight. I guess Microsoft assumed that nobody uses their computers at
night and figured they could forget it and nobody would notice. Thanks,
guys. I'm not sure if this was fixed in DOS 4.
--
__ __ _ | ...!nexus.yorku.edu!xrtll!silver | always
(__ | | | | |_ |_) >----------------------------------< searching
__) | |_ \/ |__ | \ | if you don't like my posts, type | for
_____________________/ find / -print|xargs cat|compress | SNTFkoziarz@halibut.nosc.mil (Walter A. Koziarz) (01/07/91)
In article <1991Jan5.181959.10764@xrtll.uucp> silver@xrtll.UUCP (Hi Ho Silver) writes: > > The problem you're experiencing is caused by the fact that most (all?) >versions of DOS are too dumb to increment the date when the clock turns over >midnight. I guess Microsoft assumed that nobody uses their computers at >night and figured they could forget it and nobody would notice. Thanks, >guys. I'm not sure if this was fixed in DOS 4. Don't think so.... I just tried MS-DOS versions 1.10, 2.24, 3.1 and ALL increment the date at midnight. Of course these are Zenith-prepared MS-DOSes; not I(nferior) B(ut) M(arketable)-prepared. MS-DOS *HAS* the capability and it's (apparently) the reponsibility of the system integrator to activate it. Walt K.
silver@xrtll.uucp (Hi Ho Silver) (01/08/91)
In comp.sys.ibm.pc.hardware, iisakkil@xaloc.tky.hut.fi (Mika R Iisakkila) typed: $ Actually, it isn't quite this stupid - there's usually a one $bit 'date changed' -flag, which is set at midnight. If it's set, the $bios calls add one day to the date. So you'll have to have the system $up without rebooting for two successive midnights to lose a day. BIOS calls? They're used to access the hardware-maintained clock, which has no problem with date changes. The software-maintained clock (at least in most DOS versions) may well set a flag to say the date has changed, but it doesn't actually change it even if you run your machine from 11:58 p.m. until 12:02 a.m. Specifically, I know MS-DOS 3.20 is broken; I've run that from evening until early morning dozens of times and it doesn't change the clock. I'm pretty sure PC-DOS 3.30 is also broken. -- __ __ _ | ...!nexus.yorku.edu!xrtll!silver | always (__ | | | | |_ |_) >----------------------------------< searching __) | |_ \/ |__ | \ | if you don't like my posts, type | for _____________________/ find / -print|xargs cat|compress | SNTF
trier@cwlim.INS.CWRU.Edu (Stephen C. Trier) (01/15/91)
In article <c748u1w163w@turbo.atl.ga.us> greg@turbo.atl.ga.us writes: >I'm having a problem with my system's clock. Sometimes when I'm running >a program overnight, the date is not updated. Early versions of MS-DOS (2.x, x being something I've forgotten) had a bug that did exactly that. Norton's Programmer's Guide to the IBM PC and PS/2 insists that the bug is gone, but I've had it happen to me on AT&T MS-DOS 3.3 and on the generic MS-DOS 3.3 my parents run on thier Packard- Bell. (Methinks the bug is *not* gone!) It doesn't always happen; I've never found a condition that causes it. In most cases, rebooting the computer is sufficient, since that will restore the time from the hardware clock. This doesn't always work on the Packard- Bell. I don't know why. The basic message is, "Yes, it happens. No, I don't think it means much." Sure confuses make, though! :-) -- Stephen Trier Case Western Reserve University Work: trier@cwlim.ins.cwru.edu Information Network Services Home: sct@seldon.clv.oh.us %% Any opinions above are my own. %%