Assessing the Extent of the Problem for Customized Applications

The Goal
The goal of this phase is to answer two questions for EACH customized application in the department:

(1) When will the customized application start having Y2K problems? For example, a room scheduling system that looks ahead six months should be fixed before July 1999.

(2) Approximately how much work is needed? Put differently, how much source code needs to be changed so that the application does not have a problem with any date used by the system?

For a discussion of the importance of assessment, here's an article from PC Magazine, October 6, 1998.

Before You Begin Looking for Dates
If the application was built using application development software that isn't Y2K compatible, and (say) the vendor of that software is out of business, then the assessment also needs to include the work needed to migrate the application to an environment that is Y2K compatible, or a decision to replace or stop using the application.

If the application needs to be upgraded because the operating system or application isn't Y2K compatible, then the assessment needs to include the costs (labor and other ) of these upgrades. (For a discussion of Y2K fixes for hardware, operating systems, and off-the-shelf software, click here.)

Basics and Tools
The Basics: First, you need the current source code (whether you print this out or not is up to you). Second, it will be helpful to have copies of all input screens, copies of all data file (or data table) formats, and copies of sample pages of most or all reports. Third, if there are any user manuals or other documentation, that should be obtained. Fourth, your functional experts should describe any date-dependent functions the system in question performs so you can examine these functions.

General Tools: You should consider whether you want to use (and in most cases pay for) one or more automated tools for scanning source code. While tools are generally designed to find specific problems (and thus are used in later phases than the assessment one), they can be very helpful in giving you a sense of the size of the problem. For more information, click here.

Specific Tools: You should also look at information provided by vendors, and tools designed to be used for specific products. For more information, click here.

The Assessment
Assess the components of each system with respect to date usage

Here's where the fun begins. You will have to scan the system's entire source code to identify all date-related calculations, comparisons, sorts, and other date-dependent tasks. Document what you find - that will be very helpful for the phase where the actual fixing occurs. Remember that the goal of this phase is a rough assessment of how much work is involved.

Here are some examples of processes to look at and questions to ask:
1. If you have a system that tracks orders from other departments or external customers, how are data elements such as "date ordered" and "date filled" recorded? If a product is back-ordered, how is this identified? It's not unheard of for a system to use a certain value in the date field to indicate a status or condition. For example, the system's procedures and logic might call for something like "99", "00", "01/01/01", "9/9/9", or "99/99/99" to be entered when a product is back-ordered. As we move into the years 1999 and 2000, the existence of such data in your database and the continued use of the practice may trigger unanticipated functions. There is also the problem that the original meaning of the values will be lost and operational errors may follow.

2. A system that calculates age or has an aging process for unpaid bills, noninventorial assets, years of service on a committee, etc., is fertile ground for Y2K bugs. Computations involving two-digit years will cause problems when 99 is subtracted from 00 (the system year after December 31, 1999), for example.

3. If your system uses the date as part of a unique identifier, you should look carefully at what digits are captured and used internally by the application in view of the new millennium.

4. Find all instances of dates captured in fields defined as character or text rather than as date. You have likely had problems with these fields before and now you have an opportunity to improve your system's consistency.

5. Besides looking at processing logic, inspect user interfaces (screens/panels), any related forms, and all reports generated, to determine how dates are captured and displayed.

6. Report programs must also be reviewed for any sort logic involving dates, and user interfaces must be analyzed for any edits on date fields.

7. In general, identify and review all code where a date value triggers a subsequent process in your departmental system, to insure that the results will not be unpredictable due to the new millennium. Also, don't forget the leap-year impact on date-triggered logic; the year 2000 is a leap year.

Return to Seven Phases to Y2K Compliance