CERN Accelerating science

This website is no longer maintained. Its content may be obsolete. Please visit for current CERN information.

next up previous
Next: DATIME and the Year 2000 Up: cnl228.html Previous: Letters from/to the Editor

The Millennium Bug

  Michael Metcalf IT/ASD

The Bug is born

The Millennium Bug is not some exotic insect, but an error that is lurking in computer programs, waiting for the chimes of midnight on 31 December, 1999, before emerging to bite us -- hard. Even as the champagne corks are popping to herald in the last year of the second millennium, planes will start to fall from the sky, lifts will stop working, banks will stop paying correct interest, and society in general will grind to a halt -- or so the story goes. To illustrate what the fuss is about, consider an early sign of the Bug's presence. In 1993, a lorry carrying a consignment of corned beef attempted to deliver its load to a British supermarket. Corned beef has a shelf life of seven years, but when the supermarket's computer tried to check this, instead of subtracting 1993 from 2000 to get seven, it performed truncated arithmetic, subtracting 93 from 00, to give -93! The load was refused (but accepted manually).

The story really begins in the early days of computing, when the year 2000 seemed a long way off, and nobody even considered the possibility that the COBOL and other programs that were been churned out would ever have such a long life. In those days of minute storage devices, it appeared to be eminently sensible to save a few bits in memory by storing only the two least significant digits of the year when storing dates. Things were no different in high-energy physics: the DATIME routine of CERNLIB (Z007, submitted in 1977) returns the year either as part of the six-digit integer value yymmdd, or, apparently, as 19yy! Thus, if nothing is done before the fateful day arrives, even HEP code could start putting wrong date stamps on fresh data.

The Information Technology (IT) industry has been aware of this problem for some time, and particularly in the US and UK it is taken very seriously. Professional bodies like the British Computer Society have published guides on action to take, and government departments are pressing business and industry to take corrective action. A whole industry has sprung up in which consultants advise on how to audit and modify the billions of lines of code involved. Conferences are being held that are devoted entirely to the Year 2000 (Y2K) problem, and books written. COBOL programmers are being brought out of retirement on high salaries to fix code that a younger generation cannot understand.

Parasites are out there too, writing foolish `newsletters' that purport to give investment advice on how to make a killing on the stock market when it crashes to 2000 points in 2000.

On the other hand, responsible computer companies have for some time been producing system and application software that is `Y2K compliant'. This is the sort of software that CERN has been buying over the last few years. Correct use of such software should ensure that the great event passes painlessly. However, the onus is clearly on users to ensure this happens. It's pointless Oracle providing us with a four-digit year if only two digits are used! (See the following article on Oracle use for more guidance.)

Considered opinion within the IT industry as a whole is that the time and resources available to eliminate the Bug are certainly too limited, and that the associated difficulties are almost unavoidable. This remains true even if old software is replaced by new - often the best solution. And this is one deadline that can't be moved!

The situation at CERN

Saturday 31 December, 1999, will fall in the annual shutdown of the laboratory. There will be no continuous processes running, apart from security and monitoring, so nothing will break down on the spot. Any final corrective action in the on-line and off-line computers and control electronics can be taken as part of the start-up procedures at the beginning of January.

Things are less simple in the administrative area. If a Fellow has a contract that runs from January 1999 to December 2000, spreadsheets that calculate the number of months the contract covers must find 24 and not some large negative number. Fortunately, AS Division is well aware of the problem, and is taking steps to ensure that all will be well. Among these steps are the appointment of someone with overall responsibility for tackling the Bug, and the carrying out of a simulation run in good time. Once again, it is incumbent on users to ensure that that applications software is correctly applied. All divisions are recommended to appoint similar `Y2K Czars'.

A major problem could be in the use of data from the experiments themselves. Is the validity period of a calibration file properly calculated? Are data stored with adequate time-stamps? Are the checks on these in the processing chains made correctly? The only way to answer these questions is for each experiment that expects to be processing data around that time to appoint, now, a person responsible for auditing the experiment's software and proposing suitable solutions.

Within IT Division, internal checks will be made to ensure that central systems are properly handled. One problem that has been identified is that DATIME needs correction to both its documentation and code, and this is being undertaken as a matter of urgency. Although (as explained in the following article on DATIME), for backwards compatibility, it will continue to provide yymmdd as one form of the date, the other form will give a correct ccyy. This new version will be available in release 98A of CERNLIB.

In general, for applications that perform date arithmetic on yy only, a quick patch is, of course, to add 100 to values less than 50 before performing any calculations.

Even if CERN gets its own house in order, that does not necessarily mean that it will be spared any inconvenience. At the time of the change, deliveries of LHC components from suppliers will be in full swing. What happens if a critical supplier has ignored the problem and suffers from significant internal disruption as a result? In order to protect itself, it is as well for CERN to specify Y2K compliance in all contracts from now on. Doing this will also serve to spread awareness of the presence of the Bug within European industry - a useful end in itself. Modern business is so dependent on computers that, for instance, one European PTT thinks it will have to spend US$100 million to avoid collapse. And a freight carrier will consume 12,500 man days of effort to achieve compliance. Are all our business partners as aware as this of the task ahead? Is insurance protection required?

Further information

As mentioned above, the BCS has produced a brochure that is a good start in planning which actions to take. Many Web sites give helpful information that is kept up to date. Among them are: Above all, if your activity could conceivably be adversely affected by the Bug, do something about it now - Monday, 2 January, 2000, may be too late! Even if all systems and application programs are Y2K compliant, it is up to the end users (you) to make sure that their own applications are also immune to the impending chimes.

Happy Hogmanay '99 (whoops - 1999)!

next up previous
Next: DATIME and the Year 2000 Up: cnl228.html Previous: Letters from/to the Editor