The paper consists of two parts. The first addresses the symptoms of the Y2K problem as well as possible solutions and tools. In the second part we describe our experience in solving the Y2K problems affecting the student records information system at the University of Ljubljana. A strategy for solving the Y2K challenge in Clipper applications is presented, and a description of two tools (source code scanner and data aging tool) is given. Finally, some statistical results that illustrate the size of the problem and enable comparison with similar efforts are presented.
The Year 2000 Challenge is a consequence of the fact that many computer applications were designed to use only the last two digits of the year (e.g. '98 instead of 1998). Therefore, the year 2000 will be presented as '00, and the time will reverse itself: earlier dates will become later dates, events of last year will seem to have happened 99 years ago (or will not happen for 99 years), credits will become debits etc. McDermott [1] lists the seven most deadly symptoms that may occur:
Symptom 1: 2001 > 1999, but 01 < 99
Using two digits for the year works just fine when you need to decide which of two years is earlier, as long as both years are in the same century. However, when the years span the century divide, the opposite is true.
Symptom 2: 2001 - 1999 = 2, but 01 - 99 = -98
A simple subtraction of years no longer works when one date is in the 20th century and the other date is 21st century.
Symptom 3: 00, 99 = Never
Certain dates are sometimes given a special meaning, such as never, missing or not applicable. If 00/00/00 has been used as the default blank date, all entries that were left blank will appear to be from the year 2000.
Symptom 4: The last shall sort first
On sorted lists, the items from the 20th century and the items from the 21st century will trade places. Consequently, serious errors may occur if it is critical that items be processed in chronological order.
Symptom 5: An interface built for two
Introducing a four-digit year in a spot where previously only two digits were shown will require changes in all screens and reports containing date fields. Sometimes there will not be enough room for the extra two characters.
Symptom 6: The days of our weeks
Dates in the 21st century lag their 20th-century equivalents by one weekday (from March 1, 2000, until Leap Day 2000 the lag will be two days). Therefore, the day-of-the week algorithms that assume a date in the 20th century as the base will be off by one or two days.
Symptom 7: The one you forgot about
In spite of careful testing some bugs may remain undiscovered.
There are several techniques for solving the Y2K problem, each of them having its advantages and disadvantages [1]:
Replacement: If the existing system is old and difficult to maintain, it is often easier to replace it than to fix it.
Expansion: Expanding all date fields to allow room for four-digit years is the cleanest approach, but usually the most expensive. It requires an extensive data conversion and - once a field is changed - all screens and reports that contain it have to be fixed. All the changes must be made simultaneously for each upgrade unit: convert the data, restructure the database, fix the programming logic, recompile all the programs etc.
Windowing: A "window" of 100 years (e.g. from 1920 till 2019) is defined in which we place the two-digit year. If the window pivots on 20 (as in our example) the years between 0 and 19 are assigned to the 21st century, while years 20-99 are relegated to the 20th century. This solution is economical, it can be done piecemal, one program at a time, and it requires no restructuring. However, it is limited to dates within a 100-year range.
Compression: This is a form of expansion. Years are expanded to four digits, that are compressed back into the same space originally used, thereby avoiding the need to restructure the database.
Encapsulation: All dates in the database are converted by subtracting 28 from the year (because every 28 years the cycle of weekdays and leap years repeats itself). Then we intercept input and output operations and adjust the years back and forth for human consumption. Sometimes that can be done completely outside the program. This approach is messy, but is the only viable when we do not have the source code and replacement is not an option.
The choice of the most appropriate solution depends on many variables: the computing environment, the age of existing systems, what tools are available, and even the corporate culture. There are many tools that can greatly assist in the Year 2000 conversion project [2], e.g.:
Source code scanners can identify the critical parts of code, dealing with values of type date.
Capture-replay tools automatically record test inputs and replay them in subsequent testing.
Coverage analysers can check the code coverage achieved during testing (percentage of statements, branches, and paths exercised).
Data aging tools can help in the process of preparing and manipulating data by incrementing/ decrementing the dates by a number of years, months or days.
Date/Time simulators (Virtual Date Utility) are used to simulate some aspect of the operational environment. They return a specified time and date without affecting the actual system time, thus enabling to test concurrently multiple applications, each requiring different dates and times.
Test data generators can be used for adding/updating date values that simulate the future events.
Software for the student records information system at the University of Ljubljana was developed in 1991-1994 with the support of EU Tempus program [3]. All programs are written in CA-Clipper and comprise about 50,000 lines of code. Theoretically, using Clipper's date-type variables and fields, and comprehensive date computation capabilities all dates from January 1, 100 through December 31, 2999 can be handled without having date problems until the year 3000. However, in practice problems may arise, because the default date format for input and output is mm/dd/yy, thus allowing only two digits for year representation. This difficulty can be overcome using the set century on setting that allows four-digit years, but the post festum introduction of set century on (i.e. when the programs had already been written) requires changes in all screens and reports, even if the effect is just cosmetic. Additionally, all occurrences of the ctod function that converts a string value into date must be carefully examined [4].
In such a situation windowing seems the best possible solution. Using set epoch a fixed or sliding window can be established without affecting the program code. Nevertheless, to ensure proper operation after January 1st 2000, and to avoid defects belonging to symptom 7, a thorough examination of code and testing of programs in an environment, similar to that at the beginning of the year 2000 is highly recommended.
Considering the aforementioned facts, we eliminated the Y2K problem in the following way:
Windowing was chosen as the most economical solution. A fixed window of 100 years from 1920 till 2019 was introduced that accommodates all possible dates (the date of birth of a student being the lowest, and the expiration date of certain student rights being the highest possible date value in the system).
A glass box testing approach was used in order to find those places in program code that could cause difficulties in year 2000. To automate this task a special source code scanner was used.
After fixing the programs, all critical functions comprising date manipulations were tested. Using a data aging tool the values of corresponding date fields in the actual data base were increased (usually by one year), thus creating a special testing environment similar to the situation at the beginning of the year 2000. A test plan was developed that consisted of two types of tests: testing of individual transactions (such as entering an examination application) and testing of various reports that are produced using data stored in a database (e.g. an analysis of examination results with regard to time elapsed after a course was taken). Each test of the first type was executed only in the aforementioned testing environment, while tests of the second type were executed twice: first using the actual data, and then using the test data. Considering the one-year shift of date values between the actual and test data, the validation of test results was greatly simplified: the results of both tests had to be equal.
In order to speed up the conversion two tools were developed in our laboratory: a source code scanner and a data aging tool. The source code scanner performs two basic tasks (see also [5] for a description of other Clipper source code scanners):
It scans data in .DBF files looking for fields of type date. The result of this scan is a .DBF file containing the names of such fields together with names of corresponding .DBF files where these fields are used.
It scans source code looking for critical lines containing items defined in a search list. The source is usually scanned in several consecutive iterations. In the first scan the search list consists of names of date fields (that were found during the scan of .DBF files) together with some typical keywords (e.g. Clipper functions for date manipulation, such as ctod(), year(), date(), dow() etc.) and text patterns like 19, 1900, 00/00/00, 31/12/99 etc. In consecutive scans the search list is refined by adding or deleting names and/or search strings. Each scan creates a list of all lines containing an item specified in the search list as well as some statistics (e.g. number of critical lines vs. total number of lines scanned). Typically, two scans suffice. Before the second scan the search list is modified in order to include date variables found during the first scan.
Using the data aging tool each date field in the data base can be modified in two ways: by adding or subtracting a specified number of days or years, or by explicitly specifying the new value. Additionally, a condition can be specified that defines the scope of the change. The change may affect only the specified record, a set of records that fulfil the specified condition, or all records in the specified file.
In order to give some figures about the size of the problem and to enable comparison with similar efforts we list some statistical results:
Date intensity: Some applications involve more date manipulations than other. Date intensive applications (e.g. examination scheduling) are more Y2k sensitive than others. The percentage of date fields in the date base can be used as a rough measure of date intensity. In our case the student records data base contained 4.87 % fields of type date.
Percentage of critical code lines: During the first scan of the source code 538 critical lines out of 50,046 were reported, i.e. 1.08 %. The second scan detected additional 323 lines, thus giving together 1.72 % lines of code. However, these figures represent only average values. Statistics of individual modules show that in three most critical modules 10.63 %, 7.82 %, and 7.52 % of lines had to be examined, while six modules contained no critical code at all.
Effort distribution: McDermott [1] states that an average Y2K project spends 21.7 % of time on finding, 22 % of time on fixing, and 56.7 % of time on testing fixed programs. However, these figures may vary from project to project. In our case 45.6 % of time were used for code scanning, only 5.4 % for fixing (in Clipper fixing Y2K problem using windowing is very simple), and 49.1 % for testing.
McDermott, P. Solving the Year 2000 Crisis, Artech House Publishers, Boston - London, 1998.
Leung, H. K. N., Test Tools for the Year 2000 Challenges, Proceedings of the 24th Euromicro Conference, Västerås, Sweden, August 1998, pp. 830-837.
Mahnic, V. & Vilfan, B. Design of the Student Records Information System at the University of Ljubljana, Proceedings of the EUNIS '95 Congress, Düsseldorf, Germany, November 1995, pp. 207-220.
Lujanac, P. L. Clipper and Y2K, http://www.geocities.com/SiliconValley/4231/clip2000.html
Year 2000 issues in PC Database packages, http://homepages.iol.ie/~pobeirne/y2kxbase.htm
Viljan Mahniè
University of Ljubljana, Faculty of Computer and Information Science
Trzaška 25, SI-1000 Ljubljana, Slovenia
Phone: +386 61 1768 447, Fax: +386 61 1264 647
E-mail: Viljan.Mahnic@fri.uni-lj.si