The Latest Trumors |
 |
by Beverly Rosenbaum |
Most people have by now come to the realization that there is a humongous (that's REALLY big) problem a-comin' regarding the year 2000 and extant software. And most people by now also realize that it can and will affect them personally, that it is not simply some ethereal conundrum useful for late night coffeeshop banter.
What exactly is this Year 2000 Problem or "Millennium Bug"? Canadian consultant Peter de Jager is widely credited with first exposing the Year 2000 dilemma in his September, 1993 article in ComputerWorld.
He explained that the Year 2000 problem arose because most business application software programs (mainframe, client/server and personal computer) written over the past twenty or thirty years used only two digits to specify the year, rather than four, to save (then-expensive) memory during processing. So, on January 1, 2000, unless the software is corrected, most computers with time-sensitive software programs will recognize the year as "00" and may assume that the year is "1900". This could either forc e the computer to shut down or lead to incorrect calculations.
Here's an example of the type of incorrect calculation which can be produced due to this problem: when a computer sorts dates by year, "00" (for the year 2000) could be identified as an earlier date than "99" (for the year 1999). A financial spreadsheet or projection could then show the financial trend for the 1999-2000 period running backwards rather than forwards. Insurance company computers might report a policy running through the year 2001 as having instead expired in 1901. A non-compliant bank com puter calculating interest for a financial instrument for the six year period of 1995 through the year 2000 might instead calculate the interest for the period of 1900 through 1995, for a ninety-six year period instead.
Since the year 1970 is written as "70", with the 19 taken as understood by the system, the age of someone born in 1940 (represented as "40"), would be calculated by the computer subtracting the birthdate from that day's date: "70" minus "40" correctly gi ving an age of "30". However, when midnight on December 31, 1999 passes and the date "00" comes up not as the expected "2000", but rather falling back to "1900", then on January 1st in the year 2000, someone born in 1940 would be "00" minus "40", or -40 years old. This negative age would equal "unborn", or "not here" - no pay, benefits, money or anything.
Dates are very important because they are used extensively to determine if someone should receive, or not receive, Social Security pensions, Medicare, retirement benefits, driving license, alcohol privileges, school grades, salary increases, tax codes, t ax payments, tax refunds, seniority, or overtime. In industry they are used to control manufacturing processes and maintenance schedules and keep track of machine operations. In banking dates are used to calculate interest, due dates, delinquent accounts , bonuses, commissions, mortgages, bills, loans, and stocks. The date change affects every aspect of electronic operations, from computers, to security systems, to voter registration, to financial transactions, to operation of production machinery, copie rs, satellites, television, elevators and more. Global money transfer could be threatened — you would not be able to transfer money, if your bank adopted YYYYMMDD and another bank used CCYYMMDD because they wouldn't talk the same language anymore.
Hardware or Software?
The "Millennium Bug" is both a hardware and software problem, on virtually every machine and program. Computers (hardware) have an internal clock, which may or may not work after midnight on Dec. 31, 1999. Some will go back to 1900, some to 1980, some to 1984. But it will affect the mainframe community most because mainframes are still the workhorses of commerce, government and finance. A simple "patch" can be put on a PC within minutes, but mainframes may have hundreds of millions of lines of code, all interconnected, and already patched many times.
The standard PC computer system maintains two system dates: one in the CMOS Real Time Clock chip - a hardware component that is battery backed-up on the machine's motherboard - and the other in the operating system software. These two dates are represent ed differently. Due to storage limitations, the standard RTC can only store the last two digits of the year. To overcome this limitation, a CMOS byte is allocated to track the century information. The DOS date is kept as days-since-1980/01/01 which is co nverted to four-digit-year/month/day when any program asks for it. When DOS boots, it normally initializes its current date by reading the date in the CMOS RTC and converting it to days-since-1980/01/01. DOS maintains its date as long as the system is running; the CMOS RTC hardware maintains its date whether the system is running or not, but it does not maintain the century. In the CMOS RTC, year 99 overflows to 00 and the century remains unchanged so the effective year becomes 1900; in DOS, year 199 9 overflows to 2000. So until the system is rebooted, there will appear to be no problem with the transition from year 1999 to 2000; but trouble lurks in the CMOS RTC date, which has become year 1900.
So you see, in AT compatible PCs the Year 2000 problem will manifest itself by the failure to update the CMOS century information when the RTC rolls over from 11:59PM 12/31/99 to 12:00AM 1/1/2000. When the RTC rolls over to the year 2000, the decade info rmation, 99, will correctly increment to 00, but the CMOS century information will remain at 19. This will result in an incorrect interpretation of the year, reported as 1900 instead of 2000. Since all operating systems use the system timer as the time r eference, any date/time based calculations or stampings will be incorrect.
Some BIOSes will supply 2000 to the operating system, even though the hardware date is really 1900. But any application that uses the CMOS RTC date (rather than the operating system date) will still fail at the moment of the century change, even on mach ines that claim to have a 'year 2000 compliant' BIOS. Many time-and-attendance packages, machine automation, data acquisition, and instrumentation and process control applications are susceptible since their developers long ago learned to distrust the o perating system clock/calendar, and chose instead to get time from the more stable hardware clock.
The majority of the PCs in use today will fail to advance the date to year 2000 correctly. Several major PC manufacturers claim that any future PCs sold will be Year 2000 compliant, and offer Award, AMI, and Phoenix BIOS updates for their earlier models.
Microsoft proposes several ways to address this issue:
Beginning with the original Macintosh computer released in 1984, all Apple computers running the MacOS correctly handle dates between January l, 1904 and February 6, 2040. The current implementation of the "Date & Time" control panel constrains the year to the range 1920 to 2019, for compatibility with the 2-digit year display in the System 6 General control panel.
In addition, all Apple computers running the MacOS will correctly handle leap years.
Next month, find out if your computer will survive the "Millennium Bug", and exactly how to test it. If you're feeling poetic, you can even enter the Great Year 2000 Limerick Contest. You might just win a Year 2000 countdown watch or other prizes! Send entries to pdejager@year2000.com. Peter de Jager will personally judge them, and here's his example:
There once was a coder named Grace
Who, in dropping two digits, saved space.
"It's not really a crime!
We'll fix it in time!"
She's now working late, to save face.
Beverly Rosenbaum is a HAL-PC member.
E-mail me at webmaster@hal-pc.org with any comments you have and tell me what you want to see here.
Back to the Magazine Home Page