The Hardware Problem

Each computer model will react differently to the Year 2000 problem. The first rule is to contact the manufacturer of your machine(s) with your model numbers. Many manufacturers have devoted web site space to include detailed listings of which machines will be affected.

Which machines will be affected?

If you use a Macintosh, you'll have no "Millenium Bug" hardware problems. The clock on every Macintosh ever made is designed to be accurate until February 2040 (see Apple's Year 2000 FAQ.) .

Many IBM compatibles manufactured today won't have a problem with the year 2000. But some older machines may have a problem with the CMOS and the BIOS. The CMOS is the hardware that keeps track of the date and time on your PC when the machine is turned off. The BIOS (Built In Operating System) is the code built into a PC's ROM to provide the basic instructions to control system hardware. Together, the CMOS and BIOS work together to fill in dates when needed.

In most machines, the CMOS only has space for two-digit dates. So, at startup, the CMOS will send a two-digit date to the BIOS. In the problem machines, when the year 2000 arrives, this two-digit date will read "00", which the BIOS will then convert to 1900. This incorrect date will then be sent to the operating system and then to other applications. MS-DOS, the operating system in most PCs, does not recognize the year 1900. So, if the BIOS passes it a date of 1900, it will simply reset the machine to some totally arbitrary date.

Can I manually set the date to 2000 to test for this problem?

Caution before you do this! Some programs, such as those with built in time limitations, could be rendered inoperable. In some cases, data could be lost from your hard drive.

Some machines have a BIOS chip that simply cannot recognize four-digit dates past 1999. You can test your machine by downloading and using a free utility called Test2000, created by Tom Becker. You can download this utility, as well as several other useful Y2K tools from www.RighTime.com (or from WSI...see below). It conducts a date-forward test (setting the BIOS date to near midnight on December 31, 1999, then letting it run forward) and a reboot test (to see if the new date is stored after rebooting). If your PC fails either of these tests, and resets itself to some strange date, your BIOS will probably need to be replaced. In this case, contact your hardware vendor.

A word of caution, Test2000 simulates what will actually occur when your PC's clock reaches the year 2000. So you could lose data (albeit highly unlikely) or cause time sensitive applications to expire. So be sure you close all date-sensitive programs, and if possible make a full system backup before you run Test2000.

Click to Download Test2000 (69k)

Click to Download Doschk (81k)

Both the above zip files contain full instructions in text file format. Doschk, although not described above, is an excellent and easy to run test. Should your PC fail the compliance test, the Year 2000 fix (37k) is available for download at www.rightime.com or here or it can be sent to you as an e-mail attachment (as can either of the tests above) from WSI Admin.

Under Two Years to Go…..before the millenium bug BYTES!!

Article written by David Neiger as published in Engineers Australia December 1997

By now, most engineers would be aware of the year 2000 problem which will supposedly affect many computer systems on the 1^st January 2000. Depending upon what one reads predictions of disasters range from aircraft dropping out of the sky to a constant stream of minor nuisances such as lift and security systems locking doors at the wrong time.

As engineers who work with computers, software and computer controlled devices, this problem will affect us more than most people. Whilst there are presently no legal cases before the courts, a prominent Sydney intellectual property lawyer, Michael Perkins of Hooten Perkins predicts that the number of these cases will increase significantly. Engineers, in particular, face the risk of being sued for negligence by either designing systems which may fail after the year 2000 or failing to take appropriate action to ensure that all computer systems will be year 2000 compliant.

The year 2000 problem arose out of programming techniques which were developed when computer systems had significantly less memory than they do today. In order to save memory, the year component of the date was shortened to two digits and the 19 was assumed. Even though the problem was recognised many years ago, it was thought at the time that legacy systems of twenty to thirty years ago would not be in operation and would not pose a problem for current systems.

Unfortunately, this programming practice of truncating the year has continued and as a result, the next date after 31/12/99 may be assumed to be 1/1/00 or the 1^st January 1900. Whilst this will cause problems for banks and other organisations who rely on dates to calculate interest payments, the problem is also likely to manifest itself in other computerised devices such as building control systems, security systems and air-conditioning systems.

In PC and mainframe based systems where the code can be examined, it is theoretically possible to examine each line of code and modify each date calculation to ensure that it is year 2000 compliant. However, modifying the date calculations on their own is not sufficient to overcome the problems. This is because the data structures and field and the way that data is communicated between the various program modules also needs to be changed so that it is year 2000 compliant.

Even ensuring that the program is fully year 2000 compliant will not guarantee its operation in the next millennium. This because the program is often dependent upon information provided by other programs or sources (such as data loggers) and on date information provided by the operating system. Whilst most current operating systems are year 2000 compliant (such as Microsoft Windows NT 3.51 or later and Windows ‘95), older operating systems (such as some versions of Xenix) may incorrectly report the date and thus cause errors.

The computer hardware also plays a part in year 2000 compliance since the time is kept in a battery backed up real time clock (RTC) to be read by the operating system on boot up. Whilst most of these clocks do have a century byte which stores whether it is 1900 or 2000 many computers do not automatically roll over the date correctly. This may be caused either by the RTC or by the programs stored in BIOS chips on the motherboard which are used to read the RTC. In a recent test carried out by the British Daily Mail newspaper, it was claimed that over 93% of the computers made before 1997 failed certain year 2000 date roll-over tests. The problems experienced varied considerably between systems; the most common problem being where the date after 31^st December 1999 was set to 1^st January 1900 or another arbitrary year from 1980 onwards. Other systems constantly rolled back the clock to 11PM on 31^st December 1999 or stopped dead at midnight!

As a general rule, clone computers were more likely to be affected by the problem, however it is still necessary to check all computers particularly file server or machines used for time critical tasks.

Greenwich Mean Time Pty Ltd, an international consultancy specialising in the Millennium problem suggest several tests which should be carried out to ensure that computer hardware is year 2000 compliant. The first test is involves setting the date to 31^st December 1999 and making sure that the next day the PC time has rolled over to 1^st January 2000. Most PCs should pass this test because they are working off a software clock controlled by the operating system. However when the PC is turned off and rebooted, Greenwich Mean Time Pty Ltd expect that around 80% of PCs will fail because the hardware clock will not have properly rolled over to the year 2000.

Even if the PC fails the roll over test, it may be possible to manually reset the clock to 2000, however this will be extremely inconvenient for larger organisations where hundreds of PCs will need to be manually reset. Manually resetting each PC may also cause problems with larger networks or client server applications (such as Novell Directory Services and Lotus Notes) which rely on the time being accurate and consistent throughout the network.

Some PCs with certain versions of the BIOS program may incorrectly detect the year 2000 date as being invalid and may force the PC to a "default" date when reset (such as 1^st January 1980). If a PC experiences this problem it may be necessary to either upgrade the PC’s BIOS program (which may not always be possible), obtain a software upgrade to correct the problem or in extreme cases replace the PC’s motherboard.

Even if a PC passes the year 2000 rollover tests, it is important to ensure that the system recognises that the year 2000 is a leap year. Systems incorrectly assuming the date to be 1900 will fail this test because 1900 was not a leap year. Instead they will calculate 2001 to be a leap year when it is not.

Novell have also addressed the issue of year 2000 compliance and have compiled a check list of issues which should to be addressed in order to ensure that systems and software will work after 31 December 1999.

Some of these items include ensuring that systems correctly calculate the day of the week. Since the 31^st of December 1999 is a Friday, the 1^st of January 2000 must be a Saturday rather than Monday as was 1^st of January 1900. Novell highlight critical dates to check as being 31/12/1999, 1/1/2000, 28/2/2000, 29/2/2000 and 1/3/2000. Novell also stress the need to ensure that systems can correctly count the number of days between any given period (that is calculated the number of days between 1/1/1980 and 1/1/2035 as 20,089 days).

They also advised to check that systems sort the date in the correct order. This is critical to ensure that program or data upgrades made in 2000 are treated as being newer than modifications made in 1999.

Another danger area, according to Novell, is systems which use a predefined arbitrary date (such as 9/9/99), as a "blank" data field. This was a common programming practice particularly with legacy systems and is particularly dangerous since a genuine occurrence of that date will be treated as either a blank or invalid date. This can lead to data corruption which may not be detected immediately.

Novell also stress the importance of thoroughly testing all software and ensuring that all converted software is able to access old date information which may be stored in unconverted or backup data files and is able to communicate date information with older program modules.

Microsoft have also addressed the issue of year 2000 compliance and whilst they state that their software is year 2000 compliant they warn that there are some areas which require attention. Engineers who use Microsoft software (such as Project or Excel) should search the Microsoft web site at www.microsoft.com with the phrase "year 2000" to locate a list of articles relating to year 2000 compliance.

Whilst there has been considerable focus on the year 2000 problem and how it may affect PCs and computer software, one of the hidden problems facing engineers is the software stored in embedded systems. Embedded systems is a term used to refer to any device which uses some form of computer chip or microprocessor to control its functions.

The trouble with embedded systems is that they are almost everywhere including places least expected. Some examples of embedded systems include burglar alarm systems, air conditioning controls, building security systems, data loggers, measuring tools and even domestic appliances such as the VCR and microwave oven.

The greatest problem with these systems is that they very difficult if not impossible to test since they tend to be used for mission critical functions which cannot be suspended. They are also likely to be prime candidates for the year 2000 problem since they have limited capacity and are most likely to use two digit year calculations.

According to Professor Mike Vitale of the Department of Information Systems at the University of Melbourne "the problem is that it is very difficult, perhaps impossible, for us to examine the software of the alarm system, the way we could examine the software of [say] the student registration system." This is because it is unlikely that the supplier of such embedded systems (who are usually distributors) would know how the software works and have tools available to examine the software and change it if necessary. Vitale also warns that "we have no easy way of experimenting with the alarm system either, the way we can experiment with the software of our PCs by setting the date forward and seeing what happens".

But so what if my VCR thinks that it is Monday rather than Saturday, it is only a matter of changing the time and everything will be OK again. Whilst that may be so for VCRs and other smaller items, Vitale warns that "[whilst this] is not a terrible problem, but multiplied by thousands or millions of examples, it could be a major nuisance."

An extreme example of these "nuisances"is a case of traffic chaos when computerised traffic systems run a weekday lights cycle for the 1/1/2000 and then run the weekend cycles on 6/1/2000 because it was a weekend in 1900. Other examples include building control systems that open building doors on Saturday 1^st January allowing technology savvy bandits access to ransack offices and air conditioning systems which work on the weekend (consuming energy unnecessarily) but shut down during the week.

According to Peter De Jager, one of the founders of the Year 2000 Information Centre (www.year2000.com) one of the hardest year 2000 issues to tackle is understanding the magnitude of the problem and communicating this to senior management. It is predicted by 2001 that around 90% of business will suffer loses arising out of the year 2000 problem which could have been prevent by acting sooner.

On the other hand, fixing a problem which is only a minor inconvenience can be very costly. The engineer responsible for such systems needs to assess the implications of failing to be year 2000 compliant and decide whether the possible problems outweigh the cost of redesigning the system. Certainly it is not worth replacing your VCR because the date needs to be reset but it may be necessary to replace a component if it is used to control a life support system!

In any case engineers have a duty to their clients and management to advise them of the problem and urge them to take appropriate action.

One example of how this was done was when the Institution for Electrical Engineers in England recently sent letters to company CEOs asking them the "seven deadly questions". These questions were

"Do you understand the

• effect it [the year 2000 problem] will have on any computer or equipment control systems?
• Full operational, financial and legal implications of failing to cope?
• Impact on you of inaction by your suppliers and customers?

Have you

• appointed a first class project manager reporting to the Board?
• Started a full systems audit, an impact analysis and a priority plan?
• Decided how to convince your customers and shareholders that your systems are reliable?
• Allocated at least 20% of your IT budget for the next 3 years to resolving this?"

Perhaps as Australian engineers we should be raising similar issues with our clients and managers.

Novell have also drawn up a recommended action plan which involves establishing Project 2000 teams to coordinate all year 2000 issues and examine areas where computer and embedded systems are involved.

The first step for each of these teams, according to Novell, is to clearly define criteria for what constitutes year 2000 compliance. Some of these criteria have been outlined previously but generally include ensuring that system will function after 31^st December 1999,

Then each of the project teams should become aware of the year 2000 issues which affects their area. For PC systems this is quite straight forward, however the embedded system teams may need to catalogue all equipment which may be affected and run tests for compliance at suitable times (such as after hours or on weekends). At this stage the dangers should brought to management attention and management need to be convinced of the importance of providing adequate resources and funding to rectify the problems.

Once the problems have been identified, cost effective solutions should be put in place to rectify the problems. For computer software this may involve hiring programmers to modify code, for embedded systems this may involve purchasing upgrade modules or replacing non-compliant equipment.

During this conversion phase it is critical that the systems are checked and rechecked to ensure that the components work as part of an integrated system and that all documentation and log books are also updated. During this phase of the conversion additional checks such as leap year calculations and day calculations should also be carried out.

Finally for critical systems, either internal or external auditors should be called in to perform a final check of the systems and validate that the conversions were successful and that the project has been completed. Again, engineers should obtain a certificate from the auditors and management to minimise the risk of legal action for negligence.

Engineers would also be wise to obtain year 2000 warranties from their suppliers and sub contractors to protect themselves from any potential legal action if any components or software failed to be year 2000 compliant.

In summary the year 2000 problem affects all engineers whether directly involved with computer systems, software or embedded systems. The year 2000 problem is real and any engineer who ignores the warnings is likely to be held accountable for failing to address the issues. As the Institution for Electrical Engineers England caution "if you still think that you do not have a problem, you are probably not an engineer".

There are certain tests which engineers can easily perform to validate whether or not computer equipment is year 2000 compliant. Some of these tests have been outlined in this article, other tests can be performed with by using easily obtainable software.

It is critical to determine if there is a serious problem or merely a minor inconvenience and inform management accordingly. Document your advice in memos and letters so that if management fails to act, you have at least acted appropriately as an engineer.

Form project teams to investigate the year 2000 issue and take steps to rectify problems. Remember to look beyond PCs and investigate every device where computers or microprocessors are involved. It is important to check and recheck systems because if any of the components fail year 2000 compliance the whole system may fail.

Finally have auditors perform final checks on the systems and sign off that as far as possible the systems have been made year 2000 compliant.

Remember that whilst there are few year 2000 cases before the courts as at the time of writing, experts predict that the amount of litigation will increase as companies become aware of the problems. Take care to ensure that you are not the engineer being sued for negligence!