In-Depth

Personal Computers and the Year 2000

• 02/01/1999

As many are discovering the Year 2000 problem is not just limited to mainframecomputers. It exists on Personal Computers, and, in fact, is quite pervasive. In thisarticle, we will look at the difficulties of finding and fixing bugs that exist on PCsthroughout an enterprise. The approach we will take is a progression starting withacknowledging that the problem exists, proceeding through an evaluation of rudimentarysolutions and culminating with a serious discussion of correcting problems across anentire organization.

Is There Really a Problem?

The answer, most assuredly is "yes" – and for two very good reasons.First, technically, PC software is just as susceptible to Year 2000 vulnerabilities asmainframe software. This is primarily due to the fact that the habits that allowedmainframe software to become error-prone are essentially the same as the habits thatallowed PC software to become error-prone (e.g., misconceptions about leap-year rules,etc.). But, secondly, and more profoundly, the reason PC software is so vulnerable to theYear 2000 is that we naively assume that just because PC technology is newer thanmainframe technology, it is necessarily better prepared for the Year 2000. This is a verybad assumption.

Statistics. Even the statistics alone would suggest that there is likelihoodof PC failures. It has been reported that there are over 60 million PCs currently in useby corporate and government enterprises. It has also been reported that 5 percent of thesePC contain serious problems related to packaged software (which would mean that,uncorrected, 3 million PCs will fail at the turn of the century). It has also beenreported that 60 percent of these PCs contain serious problems related to custom software(which means that, uncorrected, 36 million PCs will fail at the end of the century).

End Users. One problem compounding the PC Year 2000 issue, is that many usersare not technically inclined. And, although they shouldn’t have to be, it still meansthat someone technical will have to help them fix their spreadsheets etc. This is onlyfair.

However, as individuals who are involved in data processing and who are affected by theYear 2000 problem, they do have somewhat of an obligation to educated themselves or allowthemselves to be educated on the basic issues so that they do not continually re-corrupttheir own applications.

BIOSes. There are several technical reasons why there may be Year 2000problems lurking in the PC. At the most fundamental level is the computer’s firmware(the melding of hardware and software). For many PCs the internal clock will not be ableto recognize the century rollover. Because higher level applications reference theinternal clock, it is easy to see the ramifications of a PC that does not internally knowthe correct date. There is a delicate interplay, which allows PCs to keep track of thedate. First, there is the Real Time Clock (RTC) which stores the date, then there is theBasic Input-Output System (BIOS) which builds the date, and finally there is the OperatingSystem (OS), which keeps track of its own version of the date.

The RTC (Real Time Clock) sits on the motherboard, and stores the date in ddmmyy format(even when the computer is turned off). Since the year in the RTC date only contains twodigits, then when the full four-digit year is requested by a higher level application, theBIOS is called upon to add the century value. Unfortunately, some BIOSes simplyconcatenate "19."

This means that when the century rolls over the BIOS will return a value of 1900 ratherthan 2000. Other BIOSes behave differently, resetting themselves to the"birthdate" of MS-DOS (January 4, 1980), when the date exceeds 12/31/99. Anotherway the Year 2000 problem can manifest itself is when the system boots up. The OperatingSystem compares the date it stores to the date returned from the RTC through the BIOS, andif there is a mismatch, the Operating System will reset itself to January 4, 1980.

One word of caution is that a new machine (even a Pentium) may have a non-compliantBIOS. This happens because, frequently, old chips are mixed with new chips in thewarehouse – so it’s possible for a newly delivered machine to contain a chipthat’s been sitting on the shelf for months. Another serious problem is that a lot ofold PCs were recycled rather than scrapped or given away.

Spreadsheet and Database Software. Exacerbating the hardware and firmwareproblems, are those related to faulty applications software. When spreadsheets anddatabases are involved, the risk may depend on the usage of the date.

In the first kind of field – text fields – a century value of "19"is usually just tacked on automatically by the product. These are at high risk, because,at the turn of the century, in many situations it would be more accurate to tack on avalue of "20." Whether "19" or "20" is the correct valuedepends on the application. For example, "19" might be appropriate forhistorical dates, such as birth date, account-open-date, hire-date etc. However,"20" might be more appropriate for contemporaneous dates, such as current-date,data-entry-date, order-date or posting date. Although some products attempt to use awindowing algorithm to deduce the value of the century from the value of the year, theproblem is compounded because, unfortunately, different products (and different productversions) use varying windowing algorithms.

De-pending on whether the user is aware of what a windowing algorithm is, how it hasbeen affecting them in the past and could affect them in the future, many applicationscould be in serious jeopardy.

In the second kind of field – calculation fields – a date is actuallyinvolved in a computation. These fields are less likely to be effected by the Year 2000,because the underlying dates are generally stored internally as the number of days fromJanuary 1, 1900 (or March 1, 1900 to avoid the leap-year confusion). Since these internaldates will simply be incremented by 1 on January 1, 2000, they will probably computecorrectly. However, even these dates are not infallible. When Lotus 1-2-3 was written, theauthors thought 1900 was a leap year, so its internal count is too high by one (itincludes February 29, 1900, which never actually existed). Later, Microsoft perpetuatedthe error in its spreadsheet product, Excel, for reasons of compatibility. However,Microsoft’s database product Access, stores the number of days correctly, so if, forexample, you import dates into Access from Excel, dates after February 28, 1900, will betoo high by one day. (e.g., January 17, 1998, in Excel would be January 18, 1998 inAccess). Some people might argue that one day difference does not matter much to certaincalculations, such as computing interest, where for example the answer would be 31 daysrather than 30 days. However, for some applications where the date must match exactly,then it makes all the difference in the world if the search date is not stored properly(i.e., looking for January 18, 1998, but not finding it because it is stored as January17, 1998.)

E-mail. It’s also critical for us to realize that in addition tospreadsheets and databases, PC e-mail software is Year 2000-vulnerable. Thousands of userscould be inconvenienced, when e-mail doesn’t sort properly. Or worse yet, e-mailreceived from outside sources may be rejected, archived or automatically deleted by"janitorial" programs that detect invalid incoming dates. What makes the problemso insidious, is that you will not know about the e-mail you never got, but the originatorwill want to know why you have not responded. Plus, remember that this principle appliesto all network routers in LANs and WANS, not just e-mail systems.

Custom Software. Besides all the risk from application software, there is also dangerfrom the preponderance of custom software – written in languages, such as VisualBasic, and C++. This is due to the defects that are likely to have been written into thelogic by programmers who (a) did not know the leap year rules (i.e., 1900 was not, 2000is), or (b) did not know the day of week offset resulting for the century rollover (i.e.,Jan 1, 1900, was a Monday; January 1, 2000, will be a Saturday), or (c) did not useconsistent windowing algorithms to assign century values to dates lacking a fullfour-digit year. Among these applications are those that were written a long time ago,those that were written recently and those that found their way to the PC through the useof re-engineering products. The last example represents an irony, because, in an effort tomove the Year 2000 problem from the "dangerous" mainframe environment to the"safe" PC environment, business rules were extracted from COBOL programs andused as the basis for C++ programs instead. However, because of the intricacies ofcustom-written date logic, vulnerabilities that existed on the mainframe were carriedright down to the PC anyway.

What to Do About the Problem

Passive Replacement. Some companies might try to get a BIOS fix or workaroundfrom the manufacturer, but discover that no fixes are currently available. If so, they maydecide not to fix the PCs, hoping instead that the computers will get replaced in the next18 months anyway. That’s at least an honest attempt. Other companies put forth nosuch initial effort, because they believe from the onset that the computers will getreplaced in due course as part of an ongoing turnover policy. Honest attempt or not, bothcompanies may be unpleasantly surprised to discover that the new computers they finally doprocure still have old chips with BIOS problems.

Networks. In some cases, the decision has already been made not to fix theexisting PC’s as part of a Year 2000 initiative, because they’re going to getreplaced, anyway, as part of a network upgrade. The risk is that if the upgrade is notcompleted on schedule, there will be network problems and Year 2000 problems. Furthermore,even if the network conversion goes as planned, there might still be Year 2000 problems ifthe new network has century conversion problems of its own. Due to the risk and thepotential for a "double-whammy" some businesses are delaying plans to installnew networks, altogether.

Software Upgrades. Some companies think they don’t need to fix their PCsat all because they either take the vendors word for compliance or, worse yet, theysubscribe to third-party lists that tell them which versions of hardware and software arecompliant. Among the companies who do at least know there is a problem, many figure thatthe most they have to do is just get the latest release of the software package. As wesaw, before, however, the danger with that approach is that new versions treat existingdata differently, due to inconsistent windowing algorithms. In the best case we could takean inventory of our applications making note of product type and version number and thenmark it as not compliant, unknown, or probably compliant. The reason that we can only say"probably compliant" rather than "absolutely compliant," is that evenif the vendor states that the product/version is compliant, the end user can still alwayscorrupt the application with non-compliant data. Thus an inventory is not a statement ofcompliance.

Legal Considerations. Remember, there are about 60 million PCs in use. Thus,if only 1 percent break that’s over 500,000 failures.

Vendor Relations

Availability. To begin with, some PC manufacturers are providing free fixes tothe BIOS problem. In fact, some third-party software vendors are offering BIOS fixes asfreeware, or are bundling in BIOS fixes with their own software as a courtesy. In the caseof third-party software, companies might try to contact the vendor, only to discover thata surprising situation awaits them. For example: Is the vendor still around? Is thereanother vendor who can help you? Are they planning to stay around? Are they deliberatelylying or are they at least trying to tell the truth about a Year 2000 upgrade? Is itreally the truth, or have they, themselves, made an honest mistake? Are they planning todeliver an upgrade? Will it be on time? Will it allow you time to fit it into yourenvironment?

Compatibility. Even under the best of circumstances one can not assume thatsimply getting the new version of the product is all that needs to be done. The reason, asmentioned earlier, is that the new software may not be compatible with the existing datafiles. For example, Access 95 interprets all yy dates as 19yy, but Access 97 interprets00-29 as 2000-2029 and others as 19yy. Excel 95 interprets 00-19 as 2000-2019 and othersas 19yy, but Excel 97 interprets 00-29 as 2000-2029, and others as 19yy. And, finallyLotus 1-2-3 97 interprets 00-49 as 2000-2049 and rest as 19yy. Thus, as we can see, simplygetting an upgrade to an existing product could actually compound the problem. The ironyis that in their own individual ways, the products are Year 2000-compliant –it’s just that they are just not consistent with each other. Thus, it becomesincumbent upon the user to know and understand how any given product has been treating(and will begin to treat) two-digit years, vis-à-vis its own particular windowingalgorithm.

Plus, there is the ever-present dilemma in dates that can span more than one hundredyears. For example, a birth year of 97 could mean 1897 or 1997. Although this has alreadybeen a problem, it is going to get worse in a couple of years, when a birth century couldbe 18, 19 or 20. Thus, it might make sense to just expand the years in birth dates (andall other dates, for that matter) to four digits in order to eliminate the risk associatedwith fluctuating windowing algorithms.

Is "Finding" Date-Related Problems Enough?

Knowing that we are going to have to tackle this huge problem, we need to give somethought to automating the process. Remember, there is very little time left and anenormous number of PCs (and associated spreadsheets and databases) that require repairs.

Drawbacks of Simply Automating the Identification Process. In some cases, itmay be possible to use tools that find the problems, but unless the tools automate theprocess of fixing the problems there may not be much of a gain. In other words, it may berelatively inexpensive to find Year 2000 bugs on the PC, but it may be quite expensive tofix the problems, if the fixes are done manually. Plus, in some companies it may not bedesirable to bring in teams of consultants to do the repairs manually because of thedisruption of workflow. Additionally, a labor-intensive approach may not allow enough timeto complete the conversion by the end of the century. Moreover, if consultants are reliedupon too heavily, then the users will not learn much about the mistakes that are beingrepaired and the habits that need to be corrected. Furthermore, in most cases, consultantscan not even do the work alone, since the user has special knowledge about the applicationthat’s being repaired.

However, since in most cases, the users will not know how to fix the bugs themselves,they will be able to benefit from some automated assistance during the repair process.

Should We Automate the Entire Process?

Now that we’ve concluded that the repair process should be as highly automated aspossible, let’s consider what that really means. In many cases the process can bepurely automatic, such as the text fields which merely need to be expanded or windowed.However, in the cases of the calculation fields which may require user intervention, itwill be helpful for the user (1) to be alerted to the need for manual assistance, (2) tobe given an indicator of the degree of difficulty or risk of impact involved, and (3) tobe guided through the fix process with pull-down screens and help menus, etc.

This same principle applies to software written in programming languages, such asVisual Basic, C and C++. In other words, it may not be possible to automatically applyfixes to complex program logic, but it should be possible to at least point theprogrammers to the Year 2000-vulnerable locations and guide them through the repairprocess.

Technical Considerations. As we embark upon the remediation process, we willhave to decide how we wish to support a full four-digit year. Basically, it can be done inthree different ways (including combinations). They are: (1) Permanent expansion, (2)Temporary windowing and (3) Manual modifications.

For the physical expansion approach we are choosing to permanently convert the data sothat it will now carry an explicit century value, such as "19" or"20." In some cases, such as birth dates, where the year could lie within two(and soon to be three) different centuries, this may be the only realistic choice in orderto permanently eliminate ambiguity.

For the windowing approach, we leave the data, itself, alone, but instead, for purposesof consistency, we use the window associated with the given product and its particularversion.

For the manual approach, it may be worth permanently expanding the field, rather thanhaving to decide which windowing algorithm to use. Otherwise, we’d have to choose awindow that is compatible with the application (such as 1978-2067) – or choose awindow that is compatible with a new version of the product (such as 1930-2029), an olderversion of the product (such as 1920-2019), or an older still version of a predecessorproduct (such as 1950-2049?)

Delivery Systems. Now that we’ve committed to fixing the problem,let’s consider the difficulty in performing assessments on, delivering fixes to andmonitoring changes on PCs – across an entire enterprise. First of all, and inrecognition of the fact that many applications are running on older computers, it isessential that the repairs be done not only under WINDOWS 95, 98 and NT, but also WINDOWS3.1 and even DOS.

Because PCs permeate organizations, we may find it necessary to have an automateddelivery and tracking system. Such a system can be useful for identifying the locations ofthe PCs, deploying the fix-it technology, and surveying the progress being made towardbringing the applications up to Year 2000 compliance. Not only would this process providea simple inventory of the PCs, but management could benefit from reports generated to showwho, within the organization, has downloaded and run the software – even breakingsuch reports down by department if desired.

Obviously, the more thorough the overall delivery, tracking and reporting system, thebetter prepared an organization will be to meet the upcoming century change. Ideally,within a company it would be most desirable if each PC user could simply logon to theintranet and download the software (after identifying their serial number and type ofequipment for inventorying and tracking).

Less elaborate delivery systems might involve a central person within an organizationwho would either receive the software on diskette (or download it themselves from theInternet) and then would dispatch the software to other PC users by e-mail or physicaldiskette.

In scenarios where the software is delivered non-electronically, we probably

wouldn’t be able to use a CD-ROM, since most older machines don’t have aCD-ROM drive. It’s also important to realize that when the delivery system is manual,then the tracking and reporting systems become manual as well – which in most casesmeans that the central person would be the one to monitor individuals who had received(and deployed) the software fixes.

Making the Repairs. In all cases, though, once the software has beendownloaded, the recipient ought to be guided through the conversion process. There is morethan the normal good reason for this – which is that many PC users are not verytechnical (and should not have to be). Thus, it can be extremely helpful, if not actuallynecessary, to lead the user through the repair process with install wizards, tutorials,practice files, online help systems and execution wizards that can assist the end userwith the remediation process. The value of such tools, in addition to easing the process,is to prompt the user for answers to serious questions they might not think to askthemselves. For example, "Should I expand to a four-digit-year or should I use awindowing algorithm?" and "If I’m doing a manual change and I select thewindowing approach, then which window should I use? (i.e., 1930-2029 or 1920-2019?)"

Follow Up/Ongoing Certification

Now that we’ve fixed the problem, we’d want to give some thought todocumenting the work, understanding the impact to the enterprise and taking steps toprevent the re-introduction of Year 2000 problems on the PCs we’ve just repaired.Maintaining compliance is at least as important as establishing it in the first place.

Considerations. To help ensure that the repaired applications, on any givenPC, remain Year 2000-compliant, it would be helpful to build in scanner routines whichinvoke the repair technology whenever there is the possibility an invalid date can beintroduced. If that situation were ever detected, the user would be alerted to the factand required to correct the problem on the spot. This can happen at several points in thelife-cycle of the spreadsheet (for example).

The first opportunity to detect a Year 2000 bug would be when a pre-existing file isopened. That way a user would not be able to work on the file without also having to makeit Year 2000-compliant.

The next opportunity would be if the user introduced a new field with a two digit year;at which point the user would be notified of how the product is going to interpret the twodigits (i.e., 30-99 means concatenate a century of "19," and 00-29 meansconcatenate a century of "20").

The third opportunity would be if an invalid date is entered at all, at which point theuser would be issued an error message. Finally, when the file is closed (whetherpre-existing or new), if there are any non-compliant dates, then the user would benotified and expected to remedy the situation.

As far as the impact that PCs might have on the enterprise, it is vital to know, inadvance, how data flows between PCs and mainframes throughout the company. Otherwise,there is the potential for corrupting the newly repaired PC systems with data from themainframe (vis-à-vis screen scrapping operations, for example). Conversely, even if thePC applications are made Year 2000-compliant with eight-digit dates, the mainframe may notbe ready to receive them. In such a case (as with the earlier example) it may be necessaryto utilize temporary bridging programs.