Consider whether the following areas in your company will be affected by the Year 2000 problem.
Off-the-shelf applications You should review off-the-shelf applications and systems that have been purchased externally. In particular, consider any third-party custom controls (VBXs, OCXs, DLLs, and so on) that might include date processing. Calendar controls are an obvious concern here.
Internally built applications It’s possible that your company has hundreds of small in-house applications for a variety of purposes. These applications are potentially dangerous because they might have been built “on the quick” and therefore might not have been subject to the usual quality control measures.
Operating systems Regardless of the operating systems currently used within your company (Microsoft Windows 3.x, Windows 95, Windows NT, and so on), you still need to be certain that the Year 2000 problem will not adversely impact the operating system’s performance. So check it out!
Databases Your Visual Basic applications might interact with any number of external databases—local Jet databases, shared Jet databases, client/server databases, and so on. You need to ensure that any data processing that includes date values in these databases will function as expected into the year 2000.
BIOS for PC systems I’ll cover this topic a little more in a bit. For now, be aware that certain makes of PC will reset the clock date to 1980 if they are turned off before the turn of the century and then back on again after the turn of the century.
Costs of fixing the Y2K problem Nobody knows for sure exactly how much the Y2K problem will cost to fix. Because of the likely shortage of available staff and the time involved, however, the costs are likely to double each year between now and 2000. In other words, it will cost you twice as much to fix the problem if you put it off until next year as it would if you were to begin fixing the problem now.
Most estimates making the rounds at the moment tend to consider the number of lines of code (LOC) in an application when estimating costs. At the time I wrote this chapter, between $0.50 and $1.50 per LOC was considered an acceptable estimate. So obtaining a detailed inventory of your applications will obviously help you answer the following questions so that you can better estimate the costs involved in fixing the Y2K problem:
Some applications use special dates to indicate certain processing boundaries, such as 00/00/00 or 12/31/99. Watch for these dates, and consider their use after 1999—that is, will they still be valid?
The Y2K day-of-the-week problem What is the Year 2000 day-of-the-week problem? This problem could affect some programs that calculate the day of the week. January 1, 2000, is a Saturday; if the Visual Basic application incorrectly defines the date as January 1, 1900, any application that relies on the day of the week will interpret this day as a Monday.
Dates in keys Some database tables and data files use a date as the key for a record. For example, a table of appointments keyed on Customer Surname and Date would have data in the format “Smith010198,” indicating that customer Smith has an appointment on January 1, 1998. If the date format of a database table or file doesn’t include the century digits, all sorts of problems can occur when a user is attempting to retrieve records based on a date past December 31, 1999. Again, be sure to look for the use of dates as keys.
2000 as a leap year Some programmers have been known to calculate the occurrence of leap years incorrectly by not following the rule stating that when the year is the last year of a century (the year xx00) and divisible by 400, it is a leap year. See the “Leap Years” section on page 409 for a more detailed discussion of this problem.
Tools for testing Many good testing tools are available. You might save time and money by investing in a testing tool that permits automated testing, including regression tests, based on test scripts.