THE origins of the Year 2000 problem are simple enough - even if the solutions are not.
In the early days of computing, processing power and storage were limited in scale and very expensive. Programmers tried hard to minimise the amount of data these early machines had to handle or store and one obvious way to do this was to store only two digits for the year element of a date, "70" instead of "1970" for example.
Halving the amount of information stored for the year component of every date on a system was a worthwhile saving and the practice was almost universal. Those early programmers did not expect their work to be still in use 20 or 30 years later, so they didn't worry too much about what would happen when 1999 gave way to 2000.
In fact, many of those early systems, or components of them, are still around, having been moved to new hardware or incorporated into newer systems. Software which has been written specifically for a company represents a large investment and managers are reluctant to cast it entirely aside.
The same datehandling shortcut was used in many other areas of computing in some operating system software, in the "basic input output system" (BIOS) which is the lowest level of software in a PC, and in "embedded applications" - the microchips which control all sorts of devices from microwave ovens to traffic lights to lifts.
The danger of the shortened date format is that computers will interpret the day after December 31st, 1999, as January 1st, 1900, rather than January 1st, 2000. They may generate rubbish output, corrupt information that they hold or, perhaps, shut down altogether - not a happy thought if the system in question is running the safety systems of a nuclear power plant, or an airtraffic control system.
What might happen to a billing system which suddenly thought most of its invoices had been issued 99 years into the future? Or what about calculating interest payable, pensions and dividends for periods that cross the millennium?
Already there have already been reports of problems. They range from credit cards with expiry dates in 2000 being rejected by validation systems to batches of preserved food being rejected by supermarket computers which assumed that their "best before" date in 2000 was 97 years ago.
Year 2000 problems (or "Y2K" in the jargon) can arise at many levels with a given computer system. In some cases hardware may have a limited range of dates coded into components. The more likely areas, for problems, however, are the BIOS, the operating system which runs the computer or the application programs run by users. Even a system which does not have Year 2000 problems itself may suffer if other computers to which it is linked are affected.
After a slow start awareness of Year 2000 issues is now spreading rapidly and a mini industry has arisen around tackling the problem. Solutions are not easy to find, however.
One of the main difficulties is finding all of the problematic items. There may be little point, for example, in having a company's computers functioning perfectly in January 2000 if the computerised security system will not let staff into the building, or the company switchboard is dead.
Secondly, having found pieces of software which are not Year 2000 compliant, there may be practical difficulties in rectifying the problems. Older programs may be written in an archaic programming language for which programmers cannot be found. A company may not be able to find the "source code" which was used originally to create a program and which is required for updating it. Even when fixes have been made, testing them fully can be difficult.
While the scale of Year 2000 problems has at times been hyped up, the central facts are clear. Many computer systems will have severe difficulties unless modified and the problem is not going to go away with just over two years and eight months to go.
