On November 27th last, Greenwich Mean Time marked the 400-day countdown point to the Year 2000 by reporting an analysis of calls to its consultancy. When asked "Why haven't you dealt with this problem sooner", 23% of callers said "I don't understand the problem", which is fair enough. But for others,
19% said "my computer is new so I don't think it will be affected",
17% said "Microsoft (or the computer industry) will fix it"
13% said "I thought the problem only affected mainframes"
These and similar myths (full analysis at www.gmt-2000.com /news/400 days.htm) may be circulating among others who have not yet called for help. (Because of some sensationalist coverage, 5 per cent of respondents even thought it was a scam by the computer industry.)
The real problem is ignorance. Users do not know how to actually check whether systems can process data for the year 2000 and beyond. Fundamentally, the problem for software lies with programmers' practice of storing date data with only two digits for the year. Such a simple representation fails when calculating, comparing, or sorting dates before and after the rollover from 99 to 00. This applies both to the hardware clock with which a computer tracks the date and time, and to software programs running on the computer. Both are relevant whether the computer is an embedded system, a PC/Mac, a mid-range, or a mainframe computer. The Macintosh is, however, exempt from the hardware clock issue, probably the least interesting and most-hyped problem. The first step is to assess the problem. List all the hardware, software and data files containing dates on your systems. This is most easily done with inventory tools such as GMT's Check 2000 or Viasoft's OnMark. Both are also available re-badged other under names. Those with more time than money to spend can carry out the audit manually. For all software, note the actual version number. For data files such as spreadsheets and databases, you need to understand how these dates are processed.
Once the list is complete it can be checked off against suppliers' Y2K statements on websites. This process can be supplemented by your own tests where appropriate. Assessment is the first test, to determine where the problems are. (Functional or acceptance testing is the last test, to be sure that the software now works correctly).
When the time comes to do your own assessment testing, observe all the standard precautions about backups and safe testing. It is very easy to corrupt or lose time-sensitive data, so it is vital to have a complete backup, verified as being able to restore the systems. Where possible, test on a spare machine, or a duplicate system. Some companies may have to hire equipment or co-operate in user groups to achieve this, but it should be possible with a PC to borrow a machine to set up a duplicate system for testing. Remember, the purpose of tests is to find faults. If the program fails and data becomes corrupted, the test has succeeded. But if the data was "live" and the backup fails, an extra problem has been created.
For some time now there have been advertisements along the lines of "Your Millennium Bug Problem Solved! Send £45". The solution turns out to be a PC clock fixer. The clock problem is uninteresting because it is so easily diagnosed and so easily cured. To diagnose it, use one of the many testing programs freely available on the Internet (see below), or from a PC supplier. It can be tested manually, but this involves too many possibilities for error. Simply setting the date forward on a PC may test - and fail - more than was intended. For example, date-sensitive applications such as a backup scheduler or personal organiser may erase data for earlier years if they think the year is 2000, or upon a return to 1998 after an apparently successful use in simulated 2000.
Next week: the operating system and programs
Patrick O'Beirne is a software consultant with a special interest in Year 2000 problems and the Euro.
Contact: pobeirne@sysmod.ie or www.iol.ie/sysmod/sysmod.htm