I have a randomly ocuuring problem - it happens on various processors, motherboards etc. On occassions a system which accesses DATE() and TIME() stops at midnight. My software determines midnight and caters for the change but when the lock up occurs the date has not changed at midnight if you check the DOS date it has not changed but the BIOS date and time is still correct. Has anyone come across this problem ???

What versions of Windows and Dos are you using ..

dsig

David Tod Sigafoos ~ SigSolutions

dsig@teleport.com

Yes. Different implementation though - REVG, in a logon program that checks the system date is not before the release date of the software.

A loop which (a) tests date (b) shells out to the DOS date command to reset it and © returns to test new date only to discover it unchanged, (b) © (b) ©……….

On a non-Y2K compliant 486-50 PC. DOS 6.22, running under Windows for Workgroups 3.11.

Steve

Program runs under DOS 6.22 only not windows

PC's keep time in two separate ways. Some type of timer is incorporated into the non-volatile BIOS setup memory to keep the time when the computer is turned OFF. When it's running, time is maintained by a programmable timer that is hooked to generate an interrupt 1800B0 hex counts in 24 hours (about 18.2 times a second). The current timer tick count can be seen at memory location 0040:006C. This is what DOS reads when you call one of its time services (Int 21H, services 2AH and 2CH). At midnight, the interrupt service sets a "crossed midnight" flag (at 0040:0070) and resets the count to 0.

The only way DOS knows the date is by incrementing its initial boot date when it detects the crossed midnight flag. It doesn't go back to read the BIOS date and it doesn't actually increment its internal date until one of its time related services is called (or something that indirectly needs the date like closing a file). So a classic problem with any DOS machine is that the date will get behind if left to idle for more than 1 day without a DOS call. For example, boot a PC into DOS on Friday, check that the date is correct, then leave it turned on continuously over the weekend at the C:\ prompt. On Monday morning, type DATE and surprize, DOS reports "Current date is Sat MM-DD-YYYY" because DOS knows that midnight has passed, but not how many times it has passed.

Unfortunately, this doesn't sound like your problem, since you say your system accesses DATE() and TIME() which I assume just call the DOS services and which should therefore increment the date (at least the DATE() call should).

How does your software "determine midnight and cater for the change"?

Are you sure you have no constructs like:

T0=Time()

loop

until Time() - T0 < DelayTime

If you happen to call something like this within DelayTime of midnight, you wind up in an infinite loop.

Hope this gives some food for thought.

horvath_jim@keithley.com

Oops, I meant,

T0=Time()

loop

until Time() - T0 ] DelayTime

Jim

Jim,

Thank you for your information. Since I posted this problem I have been doing some more investigation. We have two types of system using common code, one system is not effected by the problem and the other is. I have since found out that the graphics package DGT is what is causing the problem. I use postindexing routines to activate certain proceses and one system calls DGT to display and advertising graphic after it has done other processing. If I disble the call to DGT I do not have a problem. It appears that DGT is causing DOS a problem at midnight.

Regards

Trevor McDonald

View this thread on the forum...