The most widely used software in departmental computing is probably commercial desktop software from major vendors: word processors, spreadsheets, scheduling and calendar products, etc. Although much of this software is critical to day-to-day functioning, it is unlikely to present major year 2000 problems. The vendors are all aware of the problem and in the process of making their products ready for the next century. It may be necessary to upgrade to a more current version, but a year 2000 compliant version will probably be available. All ITS Supported Software will be Y2K Compliant. Step 2B - Evaluate Software Problems
It is far more likely that major problems will arise in departmental business applications and programs. These include local applications (written or maintained by the department) or leased ('turnkey') systems maintained by a smaller vendor. Local departmental applications are often used for decision making or planning, and therefore may have significant business impact if not corrected. In addition, individual researchers may use programs unique to their projects and will need to determine which of those programs are critical to the research project, may have problems, and must be corrected.
Using the software inventory sheets from Step 1, you should review all such applications used in critical research, academic functions or administration to be sure they will continue to function in the year 2000 and beyond.
Commercial desktop software
A good place to start your software inventory is by checking the page, ITS Supported Software. Where known, the year 2000 compliant version or release date is shown.
If you are running software that resides on your desktop or on a local server not on the list of ITS Supported Software, you must check for compliance. If your software is not year 2000 compliant, you should upgrade to a compliant release.
Word processing programs are not likely to have problems within the software since they pick up their dates from the machine they are running on. However, spreadsheets do need to be checked for date-specific processing and date formats. Also, be sure to check scheduling or calendar software.
Remember, some date errors in display may not be critical. If your LAN calendar shows an appointment for January 6, 1900, you'll know to show up on January 6, 2000. But if the process simply does not work at all or will not accept any date after December 31, 1999, it will have to be upgraded or replaced.
Be aware of desktop processes and conventions that may be affected by dates or depend on date formats. DIR commands in DOS and file management functions in Windows still display 2-digit years and may produce unpredictable results if used for sorting. If you run programs or routines in desktop applications that generate file names with dates (e.g., ab971231.txt), the limitation of 8 characters in a file name and 3 in the extension may make it difficult to expand dates to include 4-digit years in pre-Windows95 desktop systems.
If you are running a Microsoft product, you can check their Frequently Asked Questions web page for additional information.
Other commercial software from vendors
Check the vendor's web site, if there is one, or contact the vendor. Attached is a Sample Letter to Vendor requesting a compliance statement, along with a Guide to Evaluation of Vendor Compliance Claims.
Departmental business applications and programs
As stated above, locally written or maintained systems will need to be made year 2000 compliant if required for critical departmental functions. Such applications may be used to support research, academic functions or departmental business needs. If you have any questions, check with ITS. If it is not ITS Supported Software, whenever possible, contact the vendor, contractor, or the original programmer. They will be most able to determine year 2000 compliance and convert the code if necessary.
If the original provider is unknown or unavailable and the application or program is critical to department functioning, it will have to be reviewed and tested. If it is not ready for 2000, it will have to be corrected or replaced.
To even determine if there is a problem, you may need assistance from someone familiar with the language and technology in which the system was written to do that review. Academic departments should contact Robert Davis; administrative departments should contact Kimberly Butz.
Warning! Be very careful about testing for year 2000 compliance without expert technical help. In many cases, just setting the date ahead to sometime in 2000 can corrupt current data beyond recovery.
Shareware/freeware
Contact the original source, if known, for compliance information or consider abandoning or replacing with compliant software.
If the software is critical, make sure you are running the latest available version, and test carefully and thoroughly.
Application interfaces
Determine whether the application or program: 1) runs alone or 2) interfaces with other applications or programs - such as central College systems maintained by ITS; other departmental systems or systems external to the College.
In the case of interfaces (i.e., data generated by one application and passed to another or processes in separate applications dependent on one another), it is not sufficient that the applications or programs are known to be year 2000 compliant: the interface must be tested for compatibility.
Year 2000 Inventory of Applications and Program Worksheet
Back to Tool Kit Steps Go to next step
|
Return Home |