YEAR2000.TXT 10/21/97 UPGRADING DATA FILES AND SYSTEMS FOR YEAR 2000 COMPATIBILITY If you have an existing Epi Info data system and/or data file that uses two-digit dates and that you intend to continue using in the year 2000, you should convert dates in the data file to dates with four-digit years and seek out and correct potential problems in programs, check files, and custom reports that were designed for two-digit years. The remainder of this file gives instructions for converting existing systems that are based on previous versions of Epi Info and contain dates with two-digit years. UPGRADING DATA FILES FOR YEAR 2000 COMPATIBILITY First (Always, Always, Always), make a backup copy of your data files, make sure it is a good copy, and put it in a safe place. View the screen format of your data file by running ENTER or ENTERX and giving the name of the file as the data file with option 1. Locate all the date fields containing years. If there are no fields of the format or
or they have already been converted to or
, then no further conversion should be necessary. If there are fields containing two-digit years, ascertain whether there is space on the screen to add two characters to each one. If so, you can use YYTOYYYY.EXE to do the conversion, as in the next section. If not, then skip to the section entitled REVISING AND, IF NECESSARY, PRODUCING A .QES FILE. USING YYTOYYYY TO CONVERT DATE FIELDS YYTOYYYY.EXE is a utility that will create a new, empty data file and add two characters to the year portion of either US or European dates in the field definitions. MERGE can be used to copy existing data to the new file, adding the current century to the year field as it does so. To convert dates to or
in a file called DATAFILE, the steps are: Run YYTOYYYY by typing YYTOYYYY DATAFILE.REC from the DOS prompt. Run ENTER by typing ENTER DATAFILE.REC from the DOS prompt Examine the screen layout and be sure that the new longer dates do not overlap other fields or extend beyond the right margin of the screen. If they do, go to the section on REC2QES below and correct the spacing. Run MERGE by typing MERGE DATAFILE.REC DATAFILE.OLD NEWFILE.REC 4 where NEWFILE.REC is the name you prefer for the new file, and 4 is the REVISE option in MERGE. MERGE will copy data from the existing file to the new, empty file, adding the current century ("19" until the year 2000, or "20" thereafter) to the date fields. Run ENTER with NEWFILE to make sure that all data fields were transferred correctly and then run ANALYSIS, READ NEWFILE, and do a FREQ of several fields including the revised date fields to be sure that the file contains the correct number of records and that all fields are as expected. REVISING AND, IF NECESSARY, PRODUCING A .QES FILE (Only necessary if you need to change spacing on the screen) If it is necessary to change the spacing between fields on the screen in order to accommodate the enlarged date fields, this requires a .QES file, the original questionnaire from which your data file was made. If the .QES file can be found, and you have not changed the names of any fields in your data file, then proceed as follows: Find the dates in the .QES file and change the 2-digit years ("yy") to 4-digit years ("yyyy"). Be sure that none of the fields extend beyond 79 columns on the screen. Save the .QES file. Be sure that the revised .QES file is in the same directory with the .REC file, and that it has the same name (except for the .QES extension). Now run ENTER or ENTERX and give the name of the data file. ENTER should notice that the .QES file is newer than the .REC file and ask if you wish to revise the data format. Respond with "Yes." ENTER will automatically produce a new data file from your revised .QES file and use the MERGE program to copy data from your existing .REC file into the new file. In doing so, MERGE will add the current century to any yyyy field that previously contained yy. The result will be a new .REC file containing the "Year 2000 compliant" data. Use ANALYSIS and/or ENTER with the .REC file to confirm that the revisions are appropriate. If any fields should contain dates not in the current century (e.g., predictions of future dates of immunization), pay particular attention to these; you may have to use ANALYSIS to make corrections. Your previous data file will be renamed to .OLD, in case problems occur. Either the .OLD file or the backup file you made before beginning the revisions can be used to reverse the updating process. If you need to recover and rename the .OLD file, be sure not to run ENTER again until you do, as only one generation of .OLD files is kept. PRODUCING A NEW .QES FILE (Only necessary if you do not have one AND you need to change the spacing of fields on the screen) Making a new .QES file is only necessary if you have misplaced the original file. The program REC2QES.EXE will produce a .QES file resembling the original .QES from the .REC file. If you have changed the field names after the .REC file was produced, however, you may have to repeat this operation to obtain a suitable new .REC file. First run REC2QES with the name of your data file. It will produce a .QES file with the same name, say OLDFILE.QES. Use ENTER with option 2 to generate a new datafile, say NEWFILE.REC. Before performing a merge to copy existing data to NEWFILE.REC, use ANALYSIS to see if the field names match exactly, by READing each file and typing VARIABLES to produce a list of variables. (Another method is to put both files into one READ statement. If they do not match, you will get an error message.) If the two file structures match exactly, you are ready to revise the .QES file in EPED, change the spacing of fields, and change long date fields to or
. Then perform the merging and data checking steps as follows, assuming that the filenames are as in this example: Run MERGE by typing MERGE NEWFILE.REC OLDFILE.REC NNEWFILE.REC 4 where NNEWFILE.REC is the name you prefer for the new file. Run ENTER with NNEWFILE.REC to make sure that all data fields were transferred correctly and then run ANALYSIS, READ NNEWFILE, and do FREQuencies of several fields, including the revised date fields, to be sure that the file contains the correct number of records and that all fields are as expected. CONVERTING .CHK, .PGM, and .RPT FILES TO BE YEAR 2000 COMPLIANT (Only necessary for existing systems built around dates with two-digit years) Converting a data file so that dates with 2-digit years are converted to dates with 4-digit years is relatively simple, as outlined above. Converting an entire software system, such as those used in state health departments for reportable disease surveillance, takes several more steps, and must be done carefully. Here are the steps we recommend: Make a complete backup of your system, including all data, programs, and associated files. You should have this in any case, but it is especially important before attempting any changes. If your system is completely or partially maintained by others, or if the data files you produce are sent to others or are read by others, be sure to think about the implications, and be sure that those who need to know about changes are informed and given a chance to provide input. They may have ideas that will be helpful. State health department surveillance groups using NETSS or other Epi Info systems should consult with their CDC counterparts, city/county health departments with their state counterparts, etc. The data files, after careful backup, are converted as described in the instructions above. If you do not have the .QES file from which your .REC file was made, you can use the program called REC2QES.EXE to produce a .QES file from the .REC file. BE EXTREMELY CAREFUL, however, to check that the variable names in an empty .REC file generated from the new .QES file match exactly the variable names in your existing data file. If the variable names in your existing file have been changed and do not match those generated from the new .QES file, the merging process that occurs when you run ANALYSIS will result in LOSS OF DATA. You can prevent this by generating a new .REC file and then changing any variable names that do not match those in your old file so that they match. Once the data file has been upgraded, assure yourself that the values are indeed intact in a sample of records, and that the dates turned out as desired. Until the year 2000, the merging process will insert the century as "19." If this is not suitable, then corrections can be made by writing a suitable program in ANALYSIS to correct the data and write out a new file. CHANGES IN .CHK, .PGM, AND .RPT FILES. There are several changes that may be necessary in .CHK, .PGM, and .RPT files. These are: *Wherever a substring like DATE[7,2] occurs in an ANALYSIS .PGM file for the purpose of extracting the 7th and 8th characters of a date (the "yy" in "mm/dd/yy", these characters are now 2 characters to the right, at DATE[9,2] or, preferably, should be treated as a 4-digit year--DATE[7,4]. EPED or another text file editor can be used to replace "[7,2]", examining and confirming each case, in .CHK, .PGM, and .RPT files. *In .RPT files or possibly in other output documents, it may be necessary to make adjustments for dates that are now 2 characters longer than previously. Running all reports and examining the output should disclose such problems. *In situations where input of dates is requested, programs may have to be altered to accommodate 4-digit years or to prompt the user to enter 4-digit years. Again testing is the only way to be sure that all such situations have been resolved. In addition to testing all the updated programs, it may be helpful to search for key items such as the words "Date" and "Year" and to examine the programs in places where these occur. Finally, the testing should include a simulation of the year 2000, by setting the system date to sometime in the first months of the next century and simulating conditions with dates likely to be encountered at that time, including some from 1999. If all goes well and your programs function correctly, it is time to notify interested parties that you are now "Year 2000 Compliant". You should be ready for the Millennium.