|
The Situation: You have a PS/2 and heared rumours 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 ferro-oyxd rings to store the Ones and Zeros for the programs and datas.
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:
1. some programs are still unaware of the century roll-over in year 2000
2. 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 Y2K-incompatible software.
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 century.
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 continously 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 proove that this is no "dummy variable" do the following:
- Start DEBUG at the DOS-prompt
- type o 70 37 (adresses 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 04.01.1980 !!
Why ? Because the BIOS-developers forgot to write the updated Century-Byte into the CMOS when the Year-2000 rollover occures. 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 still 01.01.2000.
This behaviour 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 19 ...!
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 PS/2.
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 - cannot say.
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 ...
Feel free to report experiences.
|
