Peter's Experiences (Draft: 27.06.1998)
The Situation: You have a PS/2 and heard rumors that you cannot use
it after Year 2000.
Read here about potential problems and the "How To" check and solve them.
Some Historical Facts
Back in the 'Good Old Days' of very exclusive, specialized and mainly small
series computers every single bit of storage was pretty expensive. The first
computers used mechanical relays, tubes and later transistor memory cells or
ferrite rings to store the Ones and Zeros for the programs and data.
The computers of the early years had main memory capacities of some hundred
to some 10.000 Bytes; the 'Mass Storage' of these days was mainly
paper-tape, punch-cards or a bit later magnetic tape, magnetic drums and
-finally- magnetic platters. The so-called 'Winchester Drives' are inventions
of the past 30 years and the evolution of these devices was pretty slow
(though: the average capacity per unit doubled almost any 2 years).
Consequently the programmers had a problem with the storage available for
the data. The most programs these days were business or scientific problems and
the amount of data on business programs is quite huge. Calculations take a lot
room due to the storage of floating point numbers in several bytes. These
numbers and the formulas behind could not be reduced without loosing accuracy -
so the programmers fought hard to reduce the room required for "the other"
data, which was not that important.
The most common data which could easily be reduced was the date: instead
using the common DD-MM-YYYY scheme with 8 digits (or 64 bits) they stored the
date in DD-MM-YY format (= 6 Bytes or 48 bits), which reduced the required room
by 25 percent. On business programs, where it was important to store dates
-like in date of birth, date of purchase, date of signing contracts- this
worked quite nice and saved a lot memory capacity. In case the programmers were
clever enough they added automated routines, that added a -19- probably or
could handle even 19th century dates (in date of birth) to come out with the
real age of a person maybe. Or the programs could even handle dates after 1999
(e.g. for insurance contracts) if the assumed basis was a year between 1900 and
1999 ... !
Up to now this works quite nice. And -believe it or not- some parts of these
oldtimer software are still in use.
Okay - it does not run on the original machines logically - but some later
programs 'inherited' the old programs structure after re-compiling it for a
later generation of computers. This method is very common. Large companies
spent a hell of money and the manpower of some 1000 years into software
developement. All of that were lost if they would decide to drop an old machine
and its software - without the ability to at least use the data and / or the
software written for the previous system.
So a big number of companies does nothing else than writing cross-compilers
to compile Software written for Machine A to run on Machine B ... and take over
the old data and store it in the actual method.
This again caused two facts:
- some programs are still unaware of the century roll-over in year 2000
- a huge amount of data exists without the "century" stored in dates
Does that have any impact for today?
It sure has. The impact on todays practise is obvious: a software might be
unable to differ if there is a date in 1980 or in 1880 - or in 2080. For
example an insurance software is unable to recognize that the actual date is
2001 - it will assume the -01- in the date-code stands for 1901 and caculate an
insurance contract with a runtime of 35 years to end in 1936 instead of 2036.
Since we are far over 1936 this will surely cause some confusion.
Also a birthdate of 02.11.2002 would be falsely interpreted as 02.11.1902 -
which is also not very funny. At least not for the companies running
What are the practical consequences?
For us PS/2 enthusiasts ? Luckily only minor.
To clear out one misunderstandment at first: there are two different
Y2K-problems. The first one is the Software running on the system. The
second problem is the Hardware.
Assumed the software is clever enough to get the actual date from the
computer hardware and if it can handle dates after 1999 there is no problem -
if the hardware returns a proper date in 8-byte format including the
Here's the turning point to check your system. If you jump into the
operating system and type i.e. DATE under DOS you will get a date-string
26.06.1998 for example. Even the old GWBASIC returns 06-26-1998 after ? DATE$.
So there should be no problem at all, right ?
Mainly not - at least not on IBM PS/2 machines. With the introduction of the
PC-AT machines IBM has the CMOS to store configuration information and parts of
the date and a Real Time Clock (RTC). Both are battery-backed to continuously
track the actual date and time - even with the computer switched off. At CMOS
memory position 37h we can find the so-called "Century Byte", which is the
BCD-value "19" actually.
The PC and XT missed the CMOS - and the entire Real Time Clock (RTC) at all.
They use a "Timing Counter" instead, which has to be set manually at each
startup or from an external RTC on a Multi-Function card for example.
Let's examine the Century Byte a bit closer. To prove that this is no "dummy
variable" do the following:
- Start DEBUG at the DOS-prompt
- type o 70 37 (addresses byte 37h of the CMOS via I/O-port 70h)
- type i 71 (reads the byte from 37h via I/O-port 71h)
- (Output Value appears...)
- type q to Quit DEBUG
and you will get "19" as output value. Now change the machine date using
DATE at the DOS-prompt into anything after 2000 and repeat the above procedure.
Surprise, surprise: the output value is "20" now. Don't forget to reset the
date to the actual values ...
So what's the fuss about Y2K then anyway? Could it be ignored?
Well - one might ignore it. If you are not in a business and use your PS/2
for home purposes only - the problems won't touch you much anyways. But it is
always good to know what's going on there.
I did a lot experimenting with various old PS/2-machines. None of them is
"Y2K-Ready" - as largely announced by various manufacturers of
computer-equipment (even Printers, CD-ROMs and Monitors are claimed as
"Y2K-Ready" in the ads ...).
You can try that at home: just for fun set the date to December 31st, 1999 and
set the time to 23:59 maybe. Then go off to have a coffee or just sit around
and wait. After some minutes type DATE again. (If you have Win95 and try this
in a DOS-box it might happen that the system comes up with a message to check
the clock - since it has been reset from "summertime zone values" ...)
Check the DATE again: it is 01.01.2000 then ... funny, eh ? Yes - *but* - if
you power the machine down and power it up after some minutes the date is
Why? Because the BIOS-developers forgot to write the updated Century-Byte
into the CMOS when the Year-2000 rollover occurs. The RTC is just a counter -
after 1999 it counts one up and gets 2000. But the CMOS doesn't know - and the
BIOS doesn't tell. But as we have learned further above: the system *can*
handle the date. So now we enter the correct date again (01.01.2000 maybe) and
switch the machine off again ... And after powering it up again the date is
This behavior is called "Level 2 compliance". It can handle the Y2K rollover
in the software, the dates after 2000 can be stored and retrieved properly -
but the BIOS doesn't do the century update in the CMOS automatically. It still
requires *One* User interaction.
What must we do? Any recommendations?
Assumed you run your PS/2 under any Windows or OS/2 and it is January 1st
2000. Just open a DOS-box and type DATE. If you had just switched on your
machine you will find a date of 04-01-1980 since the "Timing Counter" in the
RTC had rolled over in a new year - but the Century Byte in the CMOS is still
You might ask: "Why isn't it 01.01.1900 then ?" It isn't since the BIOS
assumes that an RTC-counter value of all zeros is January 4th 1980 - the
earliest date an IBM PC BIOS knows - maybe it was the date an IBM PC was
running with a pre-release DOS 1.0 Version ... belongs in the chapter "Odd and
funny history" as well. That's the default date you see after your CMOS battery
had died and all RTC- and DOS timer counters are reset to zero.
Okay - since the date is 01-04-1980 after the first power up in year 2000
just type in the actual date 01-01-2000 and press Enter.
If you had your system running, because it is a server or you worked the
whole night over from December 31st to January 1st - the displayed DATE is
01-01-2000 already. Retype it and press enter ... and the Century Byte in the
CMOS is updated to 20 - and your machine is ready to work with the proper date
after the Year 2000.
That's all to solve the Hardware Part of the Y2K-problem on your
There is still a slight Software-Problem left: some older Versions of
Windows, DOS or OS/2 might be not Y2K-aware. This might result in some odd
entries for the date in e.g. File Manager under Windows. Especially the Win 3.1
versions are known to have some problems with that. As far as I know Win95 is
Y2K-aware mainly. I set the date to 01.01.2000 and saved an existing file under
a different name again. The File Manager showed the date as 01.01.00 - but on
"Properties" it came out correctly as Saturday, 1. January 2000. Some Win
3.1-versions show 01. January A?00 or such nonsense instead - however I think
that depends on the basic-DOS version mainly. I ran Windows 3.1 and Windows for
Workgroups 3.11 under PC-DOS 7.0 only and hadn't experienced any such problems
so far. It *might* be a problem if you use any older DOS-Version before 7.0 -
It is a good idea to get the PC-DOS 7.0-Fix for Y2K. This fixes problems
with the Virus Scanner, Backup and Restore (which are also date-depended).
There is one major limitation which is worth to be mentioned: the RTC-chip
is limited to dates between 01.01.1980 and 31.12.2099. It cannot handle dates
before 1980 and after 2099 - but I guess there will be only a few left-over
PS/2 in working condition in the year 2100...