Announcement

**Mike Luther** · 10 Dec 2003, 07:10 AM

Phil ..

How long does this effect last until the date returned is correct?
Or does the effect continue and never 'solve' itself. In that the
boxes here are all on GMT time and 'midnight' rolls at six in the
evening here, I can easily and think I will test this with a snip
for PB 3.5 in an OS/2 DOS-VDM. If what you have found is true here
I really do need to know it! If I'm where I can do this today I'll
post the answer back this evening 'local' time.

------------------
Mike Luther
[email protected]

**Phil Porter** · 10 Dec 2003, 07:43 AM

Mike,

There is a slight correction to my problem statement. When the
application is shutdown and the date checked by typing date to
the MSDOS prompt, the bad date is still shown so the application
appears to be displaying just what the MSDOS system variable is
carrying.

The date was set to 12-08-2003 two days ago and the application
started executing. Two midnights later, the display is still
reading 12-08-2003. We shut the application down this morning
and date reads ... 12-08-2003. The application has no obvious
errors now including logic flow and using grep, I've been unable
to find anywhere that we are writing to Date$. Hence, I'm
sitting here scratching my head trying to figure out why date is
not updating properly.

Phil ...

------------------
php

**Mel Bishop** · 10 Dec 2003, 07:48 AM

Originally posted by Phil Porter:
...displaying just what the MSDOS system variable is carrying.

Sounds to me like you have a problem with the system board or
the BIOS (probably the latter). Check with the mfgr of the BIOS
and see if they have an update.

------------------

**Mike Luther** · 10 Dec 2003, 10:55 AM

The thought about the system BIOS sure leaps out at one.. Looking at
the docs for PB 3.5 yields the following snip:

DATE$ cannot be used to read or set the battery-operated clock/calendar
found on many PC expansion cards.

That's obviously part of the PB docs for a good reason. Since the
reserved word DATE$ is used for both recovery and setting purposes,
seems thoughtful to me that there may already be known issues where
some form of assembler code the PB has to be using is incompatible
with some forms of hardware and the underlayment code which serves it.

The thought that comes to mind is that some curious form of mis-function
is involved where the read form of the code also, in this case, for
hardware incompatibility, also resets the system date while the
application reads it as well. Could this be an unwanted 'loop' of
some kind?

Additionally..

Phil mentions, "While the application is in shutdown.." What does
that really mean here? Unless the application is a 'TSR' of some
kind, and shutdown means this TSR is 'shut down', leaving the 'normal'
access to the operating system still running, how does one test for
MS-DOS system date, unless this is a true multi-tasker operating
system, WIN-95 upwards, DesqView, DoubleDOS, OS/2, DOS-EMU from LINUX.
That isn't on the table yet. If this application is a TSR in DOS ...
anything might be 'true' in 'shutdown'! I think in what little I
know about them, that the DOS operating system doesn't know anything
about what that TSR is doing, or how it has affected certain system
functions so that normal interrupt driven processes can do what is
really needed with them. When one writes and uses TSR's one has to
carefully provide of the TSR to pass and receive critical data in
and out of it such that the host DOS system doesn't get lost in the
normal functions.

Some of the hardest to trace and strangest errors can be produced in
the TSR disk operations in re ghost multiple same name files for
multiple un-closed file handles and corrupted FAT tables in DOS you
have ever seen where the TSR doesn't properly handle file I/O and
the host DOS operating system doesn't know about any of this. If
this application is accessing the 'DOS' date in such a way, somehow,
so that the foundation BIOS/hardware support for this is 'locked' and
waiting for a reset byte pattern .. and the 'real' DOS can't update
this data in the BIOS, presto .. what Phil sees will happen.

In a complex sort of way, a multi-tasking operating system is like
a huge glorious TSR. I like to think of them as one with at least
a reasonably well documented form of interfaces on how all the little
'TSR-kids' have to behave in talking to Mom or Pop, as you might look
at this in humor. Is this, for example, in humor here, just a bad
kid, grin?

The important thing is that PB already documents that in some cases
hardware and underlaying BIOS code can't handle DATE$ functions.
It will be interesting to see how this solves out.

Just thinking on the keyboard here.

------------------
Mike Luther
[email protected]

**Gary Stout** · 10 Dec 2003, 01:30 PM

Phil,

I ran into something very similar to what you are describing. What I
did to solve the problem was to use the TIMER keyword.
Something like

IF TIMER => 0 AND TIMER =<60 THEN
Refresh Date$ in App
END IF

In my case, I had a screensaver that displayed the date and without
this routine, the date would not change automatically.

HTH,

------------------
Gary Stout
[email protected]

**Frank Ferrell** · 10 Dec 2003, 03:19 PM

Greetings --

When I want to refresh the Date Display, I use this

Code:

ChangeDate$=Time$
Select Case ChangeDate$
  Case "23:59:59","00:00:00", "00:00:01","00:00:02"
' code to update display of date
End Select

------------------
Thanx-A-Lot and Enjoy, Frank -- My PB

[This message has been edited by Frank Ferrell (edited December 10, 2003).]

**Matthew Berg** · 11 Dec 2003, 11:00 AM

The thought about the system BIOS sure leaps out at one.. Looking at the docs for PB 3.5 yields the following snip:

"DATE$ cannot be used to read or set the battery-operated clock/calendar found on many PC expansion cards."

That's obviously part of the PB docs for a good reason.

I believe, at least originally, that was intended to refer to ancient XT/AT PCs where a RTC capability was not a native part of the system and usually had to be added by plugging a third-party ISA card into one of the PCs expansion slots, much the same way as how expanded memory was originally implemented. Being a separate (and proprietary) piece of hardware, the OS functions for maintaining the system clock (date/time) usually knew nothing of this hardware and were thus unable to update it.

This, of course, doesn't discount the possibility that there may be a similar issue affecting some more modern computers.

------------------
If you try to make something idiot-proof, someone will invent a better idiot.

**Jerry Mason** · 16 Dec 2003, 09:26 AM

The hardware clock is not read with DATE$. I would suggest bypassing the DOS system date and time (which have been thick with problems since DOS v1) and reading the real time clock directly using BIOS INT 1A, functions 04 and 02

From "DOS Programmer's Reference" by Terry Dettman and Allen L. Wyatt, Sr. sum things up:

During system startup, the date and time are initialized ... from values in the internal clock. From this point, the time is kept in the BIOS data area and the date is kept in COMMAND.COM.
In some versionsof DOS v3, a bug prevents the date from changing when midnight rolls around...
Even with the correcion, however, a design flaw in the date routines can cause entire days to be skipped. For example, if a computer is left running over the weekend and no one uses it for more than 24 hours, including two midnight passages, only one of the passages is recognized. The passing of midnight sets a flag rather than a counter, DOS does not know, therefore, when more than one midnight has gone by since the last time it asked...
The most direct cure is to reboot the computer every Monday morning to reset the system date.

------------------

[This message has been edited by Jerry Mason (edited December 16, 2003).]

**Lance Edmonds** · 17 Dec 2003, 06:29 AM

phil, under what operating system(s) has this problem occurred? is it repeatable? how old is the hardware? (bios date?)

while you say that using date at the command-line shows the correct date, does the app continue to show the wrong date if the app is restarted from the command-line?

ps: if you are running a dos app under an nt-based version of windows, then please be aware that the dos time/date can vary/drift from the time/date shown by windows because the dos emulation is set to match the windows time/date at startup, and the dos emulation maintains its own time/date from that point... see http://www.powerbasic.com/support/pb...read.php?t=920

------------------
lance
powerbasic support
mailto:[email protected][email protected]</a>

Announcement

Date$ System Variable Update

Date$ System Variable Update

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment