In doing testing, you may find some general tools or some specific product-related tools to be helpful.

First, decide what date storage, calculation, and display standard will be used. Generally, storage and use of four-digit year (1976, 2002, etc.) is normally the standard. If you decide that this will be your standard as well, then there should be automatic conversion of any two-digit years from data entry screens.

• It is possible to use (that is, continue to use) two-digit years. However, this requires "windowing" (the computer must know if "05" means 1905 or 2005), which still requires code modifications.

• Once the date standard(s) have been set, these are the suggested steps to doing the Y2K remediation recoding:

1. Make sure you have the source code that matches the executable/load modules in production. One way to do this is to move the source code to another computer (or separate region), recompile it, and compare the executable code that results to the code in production. Hopefully they are the same.

2. Search the code for all date functions, explicit and implied, and record their location in the code. Date functions are line(s) of code that uses dates for calculations or decisions - for example, to calculate the age of an individual, or to calculate the number of months remaining for a federal grant, or to look at the oldest record in a file to decide if action is necessary.

3. Look for date fields, and record what you find.

• Search all data file and table structures for fields that are of the DATE type. Also look for fields that may contain the year as a part of the field, such as an article identification number that includes the year (YY-NNNNN, for example). Then repeat step 2, searching the code for these fields.

• Review all database table indexes for index keys that include DATE type fields.

• Search for stored (temporary) variables that contain date values.

4. Repeat Step 2, using information gathered in step 3.

5. Review all reports for date fields that must be changed. Regardless of how dates are stored, most reports probably should show four digits for years. (Also, if using only two digits for years, consider potential problems with sorting/sequence.) (Use this information in step 9.)

6. Review all user interfaces (input and display screens/panels) for date fields that must be changed for data entry and/or data display. (Use this information in step 9.)

7. Review any processes that receive data from or send data to another system, such as an interface from the central general ledger system. Verify how date data will be sent to you or how you must send date-related data to another system and modify the interfaces accordingly.

8. Review any paper-based processes for gathering data for system entry that may be impacted by application changes, or any paper-based filing or storage systems that may be impacted. At minimum, forms need to be changed where "19__" is found. Enlist the help of the operational managers to deal with these issues in tandem with the application remediation.

9. Work with the users/customers to review both the user interfaces and the reports from the system to determine how they should be modified to display/capture the year field in the manner selected for the system.

10. Using the work above, make the code changes to date occurrences that were noted as needing changes, and to all impacted date calculations. Make sure that any coded date calculations take into account that the year 2000 is a leap year. Also change all identified table structures, stored variables, and indexes.

11. If the application software provides a date-related function consistent with your remediation approach - for example, "turn century on", change the function setting as appropriate.