(Excerpts from a message dated 11-20-99, Ian Moote to All)

Hi Ian--

    You should note that my tests of BASIC PDS compilled for DOS were
made in a Warp 4 VDM.  The "system clock" in a VDM is not the same as
the DOS system clock when the system is booted from real DOS.

IM>All the versions of DOS and Windows that I've tested are safe for
  >Y2K, and all of my documentation implicitely indicates that _all_
  >versions of DOS are safe for Y2K.

    You must have tested on new hardware.  DOS and the DOS-based
versions of Windows use the BIOS driver for the real-time clock, and old
hardware has a bug in its RTC BIOS.  Without an add-on software fix for
the machine's BIOS, the century value for the RTC will not turn over on
1/1/2000.  PC's built after about 1996 (depending on maker) have a
corrected BIOS.  When DOS boots, it sets its own clock from what the
BIOS reads from the RTC.  If you have the buggy BIOS, the DOS clock
comes out wrong after 12/31/1999.  If you just let the system dribble
past 12/31/1999, the DOS system clock will not show an error until next
time you reboot DOS.  It is only when you shut down and reboot that you
will find out whether or not you have the BIOS bug.  AFAIK, the only
version of DOS that contains this software BIOS fix within it is IBM's
PC DOS 2000.  I don't know which, if any, Windows updates fixed this
hardware bug, but if I wanted to guess, I'd guess only the recent Win98
"2nd release."

IM>But this reminds me of a question that I've been meaning to ask. I
  >was under the impression that all versions of OS/2 were safe for
  >Y2K, but recently I read an off-hand post elsewhere which indicated
  >that Warp 3 and 4 were only Y2K "ready" after certain fixpack
  >levels.

    The basic OS/2 operating system (at least since Warp 3) takes care
of "buggy BIOS" machines, and the OS/2 system clock (which is the RTC,
not a separate set of counters) will not die until the end of 2079 ("end
of time" for OS/2 as presently written).  However, some of the add-ons
that are furnished with OS/2 had Y2K errors; most likely those
applications presenting dates with two-digit years.  For example: the
bug in the REXX STREAM() function was "fixed" in Warp 4 FixPak 5
(thereby adding new problems), and further repairs (workarounds for the
problems introduced in FixPak 5) were made in Warp 4 FixPak 6.  I backed
off from FixPak 6 for other reasons, and am happily running under Warp 4
FixPak 5.  I haven't found any further Y2K bugs, but that is not to say
that there aren't any.

IM>Note that I shy away from the word "compliant". "Compliant" implies a
  > standard of some kind. What I want to know is, are there any
  >versions of OS/2 which are going to bomb or report incorrect dates
  >beginning 01 January 2000?

    IBM has announced that OS/2 2.x will never be updated to be "Y2K
compliant" (whatever that means).  I have never tested the system clock
under 2.x, so can not answer that question.  However, there is an IBM
Web site that might answer your questions:
          http://www.ibm.com/software/year2000/alert/ 

    Regards,

        --Murray

___
 * MR/2 2.25 #120 * If you are not confused, you don't understand the
situation

--- Maximus/2 2.02