Are Your Programs and Files Year 2000 Compliant?

Although Information Technologies staff have been assessing and correcting centrally supported UNIX and MVS systems and software, an essential part of University Y2K-preparedness falls to you, the users of these systems, your departmental systems and your personal desktop and departmental systems.  It is your responsibility to assess and correct files and programs you have written or may be using, and to look at their input and output files for potential Y2K problems, regardless of whether these are on central systems, departmental systems, or personal systems.  As part of your individual preparedness, you should check on your desktop hardware (Windows, Mac) and its operating system (Windows, Mac).

Introduction

The key question for you is whether you use 2-digit year-values or 4-digit year-values to represent or store dates. In these cases, the corresponding programs, spreadsheet or database files,and related input and output files need to be examined. The secondary question is whether the software you are using has Y2K limitations. This can often be answered by consulting our web pages on application software Y2K compliance. These web pages consist of  links to simple workarounds and Y2K-compliance warnings supplied by software vendors for Windows systems, Mac systems, and our central UNIX systems.

Problems can occur whether you're using commercial software with command files you've written (e.g., SAS, SPSS), compiled programs such as home-grown Fortran, C, or Cobol programs, or spreadsheet and database files that you created or use on microcomputers. The problems may be compounded by the format of data files that you may be receiving from others.

To aid you, IT staff have prepared guidelines and procedures to do an initial assessment. Y2K issues are discussed at great length in print and on the web. Our suggestion is that you use our introductory descriptions to do the preliminary assessment. Then, if the effort seems warranted, consider reading more detailed discussions that emphasize the sometimes complex remediation techniques, as described in references given at the end of this document. Our discussion here draws heavily upon Effective Remediation Strategies, by Michael Wheatley, IBM Corporation.

Risk Assessment

First, you should assess the risks the Y2K problem brings to bear on your data files and programs, and on your work in general.

Conversion Assessment

The second step is the determination of whether a problem may exist. Remember: the source of problems is the presence and ambiguity of dates where the year is represented by 2 digits. Therefore, the assessment may involve testing the program with data whose dates span the century mark and through careful examination of the results.

Since the success of this testing depends on the quality and representativeness of the sample runs, you may not actually detect a potential problem. A more structured approach is generally advised which involves analysis of the data files and the program files that are being processed (e.g., SPSS, SAS, LOTUS, Excel, dBase, Access) or compiled (e.g., Fortran, C). The remainder of this document presents specific program and data characteristics that might lead to Y2K problems. The mere presence of these characteristics does not mean that there will be a problem. It does provide you, however, with a basis for deciding how much remediation may be needed.

Potential problems in data files

Potential problems in program logic

There are several parts of the program logic that you should examine in light of the Y2K problem. In this section, the most likely categories or situations you will encounter are described. Although the examples are oriented to programming languages and to statistical packages, the concepts are also relevant to spreadsheets and databases that contain complex logic or macros.

Techniques

There are several ways to locate potential Y2K problems. Unfortunately, no single approach is comprehensive or even guaranteed to work. In most cases, the data values, variable names, functions, and program logic identified by the procedure as potential problems are perfectly fine and harmless. In other cases, non-apparent real problems may not be identified at all. In the final analysis, knowing the details and assumptions of your program or source code is the real key to proper problem identification and remediation. Nonetheless, there are simple mechanical aids you should consider using to locate potential problems.

More on the Y2K Problem

One excellent introductory overview to the Y2K issue was designed by IBM. Its on-line animated presentation must be viewed on a Windows 95 system and requires that you download the Bamba audio player plug-in. The presentation takes approximately 1-2 hours to complete.

K.C. Bourne's Year 2000 Solutions for Dummies (IDG Books Worldwide, 1997) is another short, approachable resource.

Microsoft maintains a web site providing Y2K-relevant information on each of its products.

Information on the compilers and application software available on the University's central UNIX systems is on the University's Year 2000 Compliance for Application Software page.

Effective Remediation Strategies, Michael Wheatley's (IBM Santa Teresa Laboratory) excellent description and discussion of a variety of remediation techniques including expansion, windowing, compression, and encapsulation.

Information Technologies' in-depth description of remdiation techniques, Year 2000 Software Solutions provides extensive Fortran examples of techniques such as expansion, windowing, bridges, and compression.

Peter de Jager's Y2K clearinghouse site, Year 2000 Computer Crisis Information Center / Millenium Bug, provides many additional overview articles.

YEAR 2000 READINESS DISCLOSURE
Main Y2K Help Page
Questions or Comments
Copyright © 1998, University of Delaware.
Last Updated: March 17, 1999