A Modest White Paper
By : Charles P.Reuben BS.MA.(SUNY @ Stony Brook 1980,1986)
SUMMARY: The three problems stemming from the date change on January 1,2000 are discussed. Specific examples of personal computer software problems are identified. In particular, the X-BASE exposure of over 20 Million Business Users is explained. A "battle plan" for analyzing and fixing potential problems is proposed. The lack of user sophistication caused by the use of Graphical User Interfaces (GUIs) is discussed.
The Biggest Myth in the World: there are No Y2K PC Problems
Few owners of Personal Computers have the slightest concern about the reliability of the machines. Most have more problems learning to operate or configure them and so users assume they need not be concerned with the Year 2000 Date change problem. That belongs to the really BIG companies. "We don't have any problems and besides, someone will fix it before 2000.There is plenty of time.The Year 2000 Date Change "Problem" has been well chronicled in the rarified atmosphere of the Information System(IS)/Information Technology (IT) circles. The problem is easy enough to understand. IS/IT people joke that "They give you the problem for nothing and sell you the solutions." In and effort to conserve expensive memory storage resources, programmers truncated the first two of the four digits in the year part of the date field. Applicatons built in the 1965-1980 time frame perpetuated the habit because it was either too expensive to rewrite the former programs or there was a tacit assumption that all the systems would be replaced long before a need would arise to rewrite the antique code. Because the problem is so pervasive most major vendors to the Global 2000 have ramped up major efforts to address the problem. Meanwhile little effort has been devoted to samll or even Medium sized Companies (save for IBM's massive work in the AS/400 world). Even less press has been expended on non-business uses of personal computers. It should be noted that many so-called "home" computers serve double duty in business and family uses.
With the emergence of the MicroComputer (the PC) some efforts to prevent a backlog of future Year 2000 error was made but again programmers seeking to preserve space on hard drives or maximize processing truncated the year field.
Currently there has been very little effort made to inform the hordes of PC users of potential problems they will have as the next century begins. Vendors of both hard and software have assured their users that "..our products are safe and Year 2000 "Compliant"..but of course, if any developer or in-house programmers modified any thing ..users should check to make sure everything will be fine..'
Users are unaware of a series of land mines ready to go off on their desks. They think that because they have purchased new machines and /or new software that they have nothing to worry about.
I have isolated several potential problems in THREE different areas that exposes this mythology once and for all.
The three areas of concern for users of personal computers are as follows:
1. The machines own time setting chips (the BIOS),
2. The truncated fields in the Software,and
3. The Leap Year Day of Year 2000.
Manufacturers of Personal Computers buy the basic in/out system(BIOS) regulator chips from many sources. Each must carefully avoid infringing on other manufacturer's proprietary systems methods of operation. That is, it would not be very wise to copy IBM's BIOS merely to claim complete "IBM compatibility". IBM's lawyers tend to frown on that. Thus, over time, several manufacturers of the chips carved out a niche supplying "almost IBM BIOS" to competitors. Suffice it to say, that an early mistake in design in BIOS has been passed down almost to this day. IF for any reason, the machine looses track of the time, it will automatically revert to either the year 1980 or 1984.
When the century turns, MANY PCs will loose track of the time and revert. Users unaware of this may simply work along for weeks entering data and information all of which will be "time stamped' by the machine . That is a minor result compared to the fact that some machines might cause user Software to get very sick indeed.
Which brings us to Problem Number 2: the Software Problem. In the design of much user software, the typical field used to describe the date type was : MM/DD/YY (month/date/year). The 2 YYs are the root cause of the future ROOT CANAL for the PCs. Consider a minor application of a short term loan.
The simple interest function is Principal(Start) X Rate X deltaTime equals Principal(Finish)..(((PRdT= Pf))).. where deltaTime is defined as date finished minus date started. If one takes out a three year loan in 1996 the result for the deltaTime can be computed with the 2 YY date field because 99-96 gives PLUS Three. Should one try to take a four year loan out the result is rather unhappy for the BANK since 00-96 equals -96 which might imply that the Bank owes the borrower a lot of bread!!!
Banks,accountants and the ever money lusting Wall Street types were made aware of this result even 35 years ago. Car dealers found out about unpleasantness by 1994 when it was clear that a six year loan in was not going to work out well for them. And so on.
What has not been clear to users of smaller and medium sized computers is the extent to which TIME coupled with COMPUTERS now rule our lives. Software has been written for almost every business application that exists. One is hard pressed to find one which is not implicitly or explicitly a FUNCTION of TIME!!! The following short list of applications should make one pause:
1. Spreadsheets
2. Data bases modified to the business functions,
3. Contact managers,
4. Project managers,
5. Accounting programs
6. Legal software: timed and dated records,faxes and now emails.
7. Personnel records written in proprietary programs
The list could go on and on. What is evident is that many of these programs and not going to become a problem until 1998 or 1999 and a few will not cause concern until Year 2000 itself.
There is one single case that should illustrate exactly how much the Year 2000 has the potential to seriously wreck a business application. As we have shown with the trivial interest example above, the central problem of how a Computer sees information can cause grief. The high level languages such as Foxbase and dBASE,Clipper and Paradox are THEORETICALLY built to be immune to the Y 2 K problem. Their central working parts (the "Engine") are designed to handle many centuries BC through AD. However, there is a command that alters the display of most user software and the subsequent use of that command can cause a serious problem. Since the X-BASE programs were widely used and modified by Value Added Dealers(VARs) and builders of Custom Software Applications (almost all of them proprietary), it is difficult to measure the extent of the problem which is quite possible to fix if treated with the attention it deserves.
The SET CENTURY ON/OFF COMMAND has the effect of altering the year display on a personal computer. To wit: when ON, the display will be 11/14/1996 and when off 11/14/96. That is simple enough. However, as the X Base programs were built and put in the field (fielded), in most cases, the modular procedures were invariably built with set Cent OFF for three reasons, to conserve resources in operation and storage AND/ OR to prevent users from entering the wrong century or spend the extra time for the keystrokes vis a vis "19". It is clear that is is possible to enter 1896 so why let the users have the chance. The 2 YYs were thus enshrined to this day.
DISCLAIMER: First, let me say, that I am a loyal to the death Borland dBASE user. (I never could bring myself to purchase a product that was fast but ..."foxy" .) It is not Borland's fault that HUMANs used and misused their dBASE product. (I am clearly a misuser and always have been, so I blame myself).
Borland's dBASE "Engine" reads the YYs as 19(96) when the set century command is OFF and saves it as such. THAT is not the problem. In fact, you can enter 96 set the century ON and all the date fields will display 1996. All is well or so it would seem. BUT, when one enters 00 with century off a little problem arises. For it seems that date goes down into the bowels of the "engine" as 1900 and when you call it back up and "do something" with it serious PC "agita" arises.
Rather than write this in "pseudo-code" lets try English. Let us order a Boeing 777 today with say, a scheduled date of delivery of March 1,2000 as: 03/01/00 and then ask the computer to subtract from the date of delivery the date of ordering in a nice little procedure, the results are not so clear. Because with century OFF it seems the Engine sees 1900. Try it, you'll like it.
If you set the century ON and write another similar procedure, the results come out as a human would expect. So, it is rather a straight forward matter to fix....maybe..or maybe,as the saying goes NOT!! Since each VAR or programmer had his/her own "style" on can not even begin to imagine the various ways DATES and DATE Procedures where implemented in Vertical Markets.
I am willing to wager that if you call any Vertical Market and find ten companies using personal computers in any job function, you will find X BASE applications with the Set Century OFF problem embedded deeply in the programs. Not once or twice but in EVERY single one of the procedures. I mentioned this to a C++ developer whose tools address the data base market and he said flat out, "There is only migration.".
So, here we have maybe 20,000,000 custom built programs sitting in small and medium "enterprises" all needing a "FIX".
YEAR 2000 is COMING!!! Are YOUR Computers READY????
Return to D/FW Y 2 K Prep HOMEPAGE
Please send your
comments or New Links on YEAR 2000 !!
Note: IBM(R) is a TRADE MARK of the WORLD'S Greatest Company:IBM
Copyright: Charles P. Reuben, 11/19/1996,revised 02/20/1997..... DALLAS,TEXAS
....America's SUPER CITY !!!!!