(Excerpts from a message dated 11-23-99, Ian Moote to Murray Lesser:
original topic: BASIC PDS Y2K OK)

Hi Ian--

IM>Perhaps I should clarify my question here. [:) I'm far less concerned
  > with RTC roll-over as I am with whether the O/S will be able to
  >accurately report dates beyond 31 December 1999. [:) Do you know of
  >_any_ versions of OS/2 which will have trouble doing that?

    AFAIK, if all you are interested in is whether or not OS/2 will
"accurately report dates beyond 31 December 1999" from the system clock
(not necessarily file dates), you will have no trouble with Warp
versions 3 or 4 through December 31, 2079.  I cannot speak for OS/2 2.x
because I never tried it when running those versions.  (There was a bug
in the early OS/2 2.0 CLOCK1$ driver that was fixed in the first CSD.)
The same trouble-free situation will not necessarily be true when you
ask REXX in some OS/2 versions to report file dates past 1999.  That is
where the OS/2 Y2K bugs I know of were.  As I said, there may have been
others.

ML> Without an add-on software fix for the machine's BIOS, the century
ML> value for the RTC will not turn over on 1/1/2000. [...] It is only
ML> when you shut down and reboot that you will find out whether or not
ML> you have the BIOS bug.

IM>I've no wish to begin a thread/discussion or to argue with you, but
  >just for the sake of expressing a point of view, I disagree with the
  >point of view of there being a "bug" in so-called "older hardware".
  >My point of view here is that since the limitations of the RTC were
  >well-known at the time it was implemented into the AT, and that
  >since this limitation was well-known to those who implemented the
  >BIOS, and that since both the RTC and the BIOS are both performing
  >exactly the way that they are intended and expected to, that there
  >is no "bug".

    You don't need to "begin a thread/discussion" because most of us
have been there, done that, on the OS2 echo about two years ago.  This
post will be my last word on the subject.

    Why (when booted from a DOS 5 floppy) does my vintage-1993 IBM PS/VP
show the "rollover" date bug, while my vintage-1997 IBM ThinkPad
doesn't?  Obviously, something was changed in IBM's BIOS design between
1993 and 1997 (and, from previous Fido discussions, in the clone BIOS
designs at about the same time).  If you had an "old" machine (which,
apparently, you don't), you could try (under real DOS) to reset the RTC
to a date after 12-31-1999, reboot, and see what date you get back :-(.
The advertising for the current-version IBM PC-DOS 2000 claims: "It will
automatically correct the date returned by BIOS on many machines that
have 'century rollover' exposure."  If this isn't an easily-fixed design
error dating from AT days (a typical Y2K bug) that wasn't noticed until
comparatively recently, what is it?

ML> The basic OS/2 operating system (at least since Warp 3) takes care
ML> of "buggy BIOS" machines, and the OS/2 system clock (which is the
ML> RTC, not a separate set of counters) will not die until the end of
ML> 2079 ("end of time" for OS/2 as presently written).

IM>Is this true of _all_ versions of OS/2, that they all use the RTC for
  > for their TOD clock? (Is the 2079 a C thing?)

    No, the 2079 "end of time" is not a "C thing" and all versions of
OS/2 (at least since v 2.0) use the RTC for a system clock (see the
description of the CLOCK$ driver in the IBM OS/2 2.0 Technical Library
manual "Physical Device Drivers").  The 2079 limitation is a consequence
of handling the shortcomings of the RTC chip by using a "windowing"
technique, and doesn't have anything to do with what language that
portion of OS/2 might have been written in, although it probably was
written in assembly language for performance reasons.  (Programmers with
any sense do not write device drivers in C, although it can be done!)

    OS/2 doesn't use the hardware BIOS once booting is well under way,
thereby avoiding any BIOS CLOCK$ errors.  I surmise (JdeBP probably
knows) that the OS/2 CLOCK$ drivers read only the two low-order digits
of the RTC clock year, and effectively put the two upper digits into the
CMOS "century byte" by using windowing:  Any year shown as greater than
79 gets 19 in that byte; any year less than 80 gets 20.  If, under OS2,
you attempt to set your system date from the command line to 1-1-2080
(or later) you will get a reply that "the system cannot accept the date
entered."  This comes from an error 327 (Date or time invalid) response
to the OS/2 API call DosSetDateTime().

    It would appear that the BIOS "fix" in my ThinkPad also works by
windowing (I can't conceive of how it would work any other way, other
than to substitute an entirely different non-compatible RTC chip).  If I
boot DOS 5.0 from a floppy, reset the date to 1-1-2000, and reboot, I
get back 1-1-2000 for the date.  If I set the date to 1-1-2080 and then
reboot, I get back 1-1-1980!  Unfortunately, at least for DOS 5, it
doesn't bother to warn me that 1-1-2080 is an unacceptable date :-(. You
might try this experiment on your "Y2K error free" later versions of
DOS/Windows and see what you get.

    Regards,

        --Murray

___
 * MR/2 2.25 #120 * Nothing is so uncommon as common sense

--- Maximus/2 2.02