This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern/ for current CERN information.
DATIME and the Year 2000
Up: cnl228.html
Previous: Letters from/to the Editor
Michael Metcalf IT/ASD
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!
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?
http://www.bcs.org.uk/millen.htm the BCS site;
http://www.iee.org.uk/2000risk important reading
on embedded systems
from a professional engineering body;
http://www.year2000.com/ a commercial site;
http://www.ncc.co.uk/y2k.html the National Computer
Centre's site;
http://www.itaa.org/Year2000.htm the US trade
association's site;
http://www.brainstorm.co.uk/disc/products/welcome.html
for `best practice'
and a conformity document from a standards body.
Happy Hogmanay '99 (whoops - 1999)!
DATIME and the Year 2000
Up: cnl228.html
Previous: Letters from/to the Editor