To those closely involved with information technology, the problems facing the world’s computer systems when the Year 2000 dawns are well known. The concern of the technologists now is to spread the message to the boardroom and beyond, to government seven, so that the worst case hype of aeroplanes falling from the skies, elevators grinding to a halt, grannies being recalled to school and insurance policies terminating before they start can be avoided. The real problem is to find the means to get senior management to take notice and commit to spending money by painting a realistic picture of the problem, rather than over or understating the extent of the possible damage. There are no easy answers and in reality, no one will really know the full extent of the problem, or whether it can be fixed in time until January 1 2000 arrives.
2000-proofed
The fact is that millions of systems, with billions of lines of code, store dates with just the last two digits for the year, so that in 2000, or 00, the system will not differentiate between 1900 and 2000. Those in the business of selling tools to help identify or fix the problems tell us we are hurtling toward technological disaster as, one by one, those computer systems that have not been 2000-proofed come crashing down round our feet. However, many of the large corporations most likely to be affected are unwilling to talk about the scale of the problem, presumably because to admit there was a big problem would be bad for business. Year 2000 tools vendors tell us there may not be enough time, programmers who know Cobol or PL/I, or money to fix the problem, unless of course we start immediately, and preferably with their help. Large companies are claiming to have it all in hand. Industry watchers are speculating whether companies will simply be propelled off the mainframe and on to client-server systems sooner rather than later, and whether this will be the moment they migrate to packaged software and ditch the bespoke legacy. After all, it must surely be easier to justify the right budget for a shiny new system than for fi xes to an aging legacy system. So just what is the extent of the problem? Is everything going to grind to a halt as the clock strikes midnight on December 31 1999, or will everyone have overcome the problem with a minimum of pain and expense? Doug Neilson, a systems consultant at IBM Corp’s Enterprise Systems division has been evaluating the extent of the problem among the unit’s customers for some time
By Joanne Wallen
He is convinced that there is not one answer to the question of how much damage the problem will cause. He says every customer’s situation will be different, depending on how old their systems are, who wrote them and how, which, if any, disciplines were followed when the code was written, what proportion of their system is based on packaged software, and so on. What IBM is urging its customers to do now, if they have not already done so, is to go away and fully evaluate their systems, so they can discover the exact extent of the problem to their own organization. Then, and only then, can they hope to take the necessary business decisions on what to do to fix the problem. Which of course is the surest way all the Year 2000 vendors have of making money out of the dilemma. In fact, since the beginning of the year shares in the likes of Computer Horizons Corp, Viasoft Corp and Data Dimensions Inc have shot up (CI No 2,904). Most are offering either tools or methodologies, or both, to e nable companies to audit their systems. Typically, these tools will identify anything that looks like a date, anywhere in any program. However, as Neilson says, there is no substitute for hard work. It still takes human intervention to look at each program individually and decide whether to correct the program, replace it or ditch it altogether. For some companies, this may be the first time they have ever carried out a system audit. The time consuming piece of the exercise may not be in fixing the program, but testing the software, says Neilson. It may be difficult to set up a test environment where the system is fooled into thinking it is now the Year 2000, without impacting the company’s main operational systems. The other major problem of course is that in many cases, a company will not have the original source code for the affected programs. But the overriding issue in all this is time. There simply will not be enough man-years available to fix every line of code that needs fixing. The actual date fix, to one line of code within one program, is a relatively simple one. It is the sheer volume of dates in the sheer volume of programs that is the problem. Added to which, there is not an infinite number of suitably skilled programmers, and this is where the panic may set in.
Impacted by dates
Viasoft, a mainframe software company that is making its money selling Year 2000 tools and fixes, reckons that the UK is nine to 12 months behind the US in dealing with the problem, and that the rest of Europe is six months behind the UK. From its studies so far, the company says that 80% to 85% of a business’s program code is impacted by dates. Obviously, many of these programs will simply display dates, perhaps on reports or screens, and may only be used internally by the company. IBM’s Neilson reckons when it comes to the crunch, many companies will simply live with these programs showing wrong dates.
