Mark Beachill is bugged by stories of millennial computer doom
Are you ready for year zero zero?
Tony Blair is out to create a 20 000-strong 'army of bug-busters' to deal with what he calls 'the biggest problem facing the world economy'. A Millennium Bug summit will focus on the problem in Moscow. Not to be outdone, the CIA is collecting data on what its man calls the 'social, political and economic tumult' that it thinks could result around the world.
What could be causing this global consternation? The fact that many computer programs use too few digits to store the date.
Instead of using four digits to store the year, many programs use just the last two: so 1998 is stored as 98. In the year 2000 (Y2K) the first two digits change - and these programs will think it is 1900 again. Will hire cars due back on 29 December switch from being two days late to being free-hire for another 99 years and 363 days? What will computers do about phone bills that cross the millennium and seem to go back in time? The worry is that unpredict- able things will happen, including computer failure.
And then what? Don't computers run everything these days? The press is full of stories about pacemakers stopping, planes falling from the sky, a computer-instigated depression. Simon Reeve, co-author of The Millennium Bomb, says, 'unless the G8 governments mobilise their workforces as if for war, the dawn of the new millennium will herald an immediate breakdown in global telecommunications'. Edward Yardeni, chief economist of the Deutsche Morgan Grenfell merchant bank and a self-confessed 'alarmist', keeps revising upwards the chance of a global recession 'at least as severe as 1973-74'. Presently he puts it at 60 per cent and rising.
What are we to do? The advice of Ed Yourden, author of 25 programming books, has a distinctly survivalist edge: 'Most of all, we strongly suggest that you spend the next two years paring down and simplifying your life, so that you can face the millennium with as much flexibility as possible.' I am sure he doesn't mean that we should all head for the hills. But these kinds of warnings are having an impact, especially on business practice. The question is, why?; for despite the plentiful scare stories, the problem is not what it is cracked up to be.
In summary the situation is this: many companies' software is already what is called 'year 2000 compliant'. When and if problems do occur, they are rarely critical; systems will keep on working into 2000. Programmers will attempt solutions and tackle persistent problems on a case by case basis, as usual.
If you are one of the many people running Windows and Microsoft Office software, or variants, you are most likely fine already. Companies which produce accounts software or order-processing applications will have made a year 2000 version, and their single effort will resolve many other people's problems. If they have not, they will soon lose customers to those who have.
It is custom-built software that needs checking and amending the most. But any computer program that works with a range of dates stretching into the next century already has to work with the Y2K problem. Examples include calculating bond deals, planning production schedules, accepting credit cards and handling sell-by dates (go to the supermarket and look at the 'best before' date on the beans).
Most major corporations which use this sort of bespoke software are already having to deal with the problem. A recent Information Technology Associ- ation of America survey found that 45 per cent of business and IT managers have experienced year 2000-related failures under actual operating conditions. In the same survey 65 per cent reported failures while testing. That we are already experiencing problems is good. Programmers are acquiring experience and developing novel, rapid solutions.
Systems have also been designed to ensure that big problems cannot occur. Take the example of power stations, often touted as systems likely to fail. The power station itself will run on failsafe control systems that monitor temperature, power output and fuel use. There is little need for a computer to make calculations based on the date. Where there is a date calculation it is for something like forward ordering of fuel, which is usually carried out by separate computer systems. The possible tem-porary failure of a system for calculating the fuel needed two years hence is not exactly a crisis waiting to happen.
Where most errors will occur with dates is not in operations, but in recording and reporting data: important, but not important enough to bring things to a dead stop. For example, pacemakers are programmed to work no matter what the date is, but they record the date and time whenever the wearer has a heart murmur. If the test equipment cannot handle the transition from 99 to 00, medical assessment might be impaired, but the clock is hardly ticking to a deadline for pacemaker wearers.
Where operations are dependent on handling dates this can be anticipated and adjustments made. Already large corporations and government departments with custom software have teams of programmers working on the code. Some have started late, largely because their IT departments see it as a boring repetitive task. For them, solving the Y2K task is a simple, if tedious, programming exercise, a 'no brainer', or, as one IT chief put it, a three on a difficulty scale of one to 10.
Overall, we might say that problems will occur where there is custom software being used and where that software is for vital operations and where the date is a vital part of it working and where the problem will only emerge on 1 January 2000 and where the company has been too stupid to do anything about the most anticipated technical problem in history.
So why all the panic? And why the international summits on the issue? What the predominate response most illustrates is a tendency to hype up problems today, combined with a lack of confidence in peoples' ability to cope - even when it comes to the IT department, whose usual joke office-sign is 'the impossible we can do today, miracles take time'.
Even when you can rely on your programmers, what about everybody else? Manny Fernandez, the CEO of Gartner Group, a large US consultancy firm selling $300 'Year 2000' videos like hot cakes, puts it like this: 'The year 2000 problem isn't just your problem. You can be thoroughly prepared. But what about all your suppliers, vendors and customers? It's going to be a mess.'
Fernandez has hit on the fear that is motivating many large corporations. Rather than trusting their suppliers and the market, they are acting like the government inspectors they railed against in the past, creating a stifling industry of red tape and mistrust. Instead of talking to suppliers, many companies on both sides of the Atlantic are spitting out questionnaires on compliance, quasi-legal documents which threaten cancellation of contracts if suppliers cannot guarantee immunity from the Millennium Bug. This spread of panic and mistrust across the economy threatens to be a bigger problem than the bug itself.
Government might have responded to the warnings, which came as early as 1986, by encouraging and subsidising businesses to upgrade their systems to the latest technology and to bring new compliant software systems online. But in modern government there is a complete absence of strategic thinking. And far from filling this gap with a rational approach of their own, businesses have tended to sink into a morass of reactive fear, trusting neither the market nor one another. Instead of taking the Y2K in its stride as a delimited, simple and foreseeable technical problem, business has suffered something like a nervous breakdown as it goes off on a wild bug-hunt.
Even though I work as a computer programmer, let me assure you that come the morning of 1 January 2000 I will be nursing a hangover, not manning the computer barricades. You can, however, e-mail me at firstname.lastname@example.org with offers of ludicrously well-paid Y2K work if you want to help me enjoy the new millennium.
Reproduced from LM issue 112, July/August 1998