Beat the clock

The Year 2000 Problem, where the world's computers will collectively ignore any date after 31 December 1999, could create havoc in the financial system, cause running and screaming, and generally be quite upsetting. The act of adding a four-digit year to all those computer programs which used two digits to save memory could cost more than pounds 600bn worldwide.

In a large company, such as a bank, perhaps five to 10 million lines of computer code will have to be checked and fixed, and there are now less than two years to finish the task before things get hairy. Indeed, problems are already appearing - not least of which is a lack of skilled people to do all this work.

For example, there is a shortage of COBOL programmers, many of whom have now retired. As COBOL runs some 70 per cent of the world's mainframe applications, this could be serious. Fortunately, it is now possible to do most of the checking and repairing automatically, as used by one of the first Year 2000 Factories run by Digital Equipment Corp in Dublin. It caters for customers across Europe, including British utility companies and car manufacturers. Digital has now set up a similar operation in New York (using some Irish staff), but Dublin also works for US companies, as demand is so strong there. "The Americans have moved an awful lot faster on this," says John Doheny, project manager for Digital's Year 2000 Compliance Centre. "In Europe it has been a lot slower to take off. The UK has been very slow. It has only been since spring, with the setting up of the DTI's Year 2000 Taskforce and real media attention, that people have been taking it seriously."

Mr Doheny says some potential customers still believe "Digital is just scaremongering to make money". But companies that wait will pay more, because, even with automation, there aren't enough skilled people to cope.

"COBOL and Oracle personnel are getting very lucrative contracts in Holland in particular, which is taking it more seriously than other countries," Mr Doheny says.

Digital (http://www.digital.com/ info/year2000) has automated the process of assessing the code and changing it, using software from a specialist Irish company, Piercom (http://www.piercom.ie), which also provides versions for many other computers. It works for the main languages such as COBOL, C, Basic, Fortran, and Digital's own proprietary languages. This means applications can be changed in a matter of weeks, although testing then takes months and involves end users as well as IT people.

"It's not just the applications you have to look at," Mr Doheny warns. "You also have to examine your external links with other organisations." For example, some credit card organisations accept four-digit numbers in the US now, but not in the UK. "Some clients have had problems sending four-digit years to banks, who won't be ready to accept them for another two years," he says.

"The biggest problem is that management is finding it difficult to convince its boards to spend several million pounds with no tangible return, but if they don't spend this money, many organisations, especially in manufacturing and financial services, will literally go out of business."

Mr Doheny gives one example of a food manufacturer's computer system which has already caused havoc because it was rejecting long shelf-life ingredients with "best before" dates after 2000.

"If people haven't started at least assessing the size of the problem by October, I think they will be too late," he says. "They need to have the code fixed and tested, at the latest, by the end of 1998 because the repaired applications have to be phased in, in case of conflicts or bugs."

Some companies, such as Digital itself, will face the Year 2000 problem up to a year early because their financial year spans two calendar years.

Once they know the extent of the problem, Mr Doheny advises all computer users to first consider buying new technology instead of repairing their old systems, so turning an unproductive (but very necessary) cost into an investment.

For smaller businesses, especially, he says the simplest solution may be to go for packaged software running on a turnkey system. But if there is a suitable packaged system, buyers will still have to make sure it can be implemented, the way they want it, within the time remaining. If they want significant alterations made to it, there may not be the skilled people available to carry it out. It typically takes about two years to get a large project up and running once a decision to upgrade is made, so decisions have to be made now. "However, this could be a very good opportunity for these companies to take the applications they have and upgrade to new technology," he says.

If it is decided to fix existing code, there are two main ways of successfully altering it. One is to make every date use four-digit years. This can cause problems with two-digit dates coming from databases or other sources, so it might be better to use a windowing technique, which only converts the date into four digits at the point it is needed in a calculation, then exports it as two digits again, by assuming, say, any year below 20 is in the 21st century. However, this doesn't work where dates of birth are involved, such as in the calculation of pensions, as it would affect anyone over 80.

Whichever method is chosen "automation can save up to 60 per cent of the time needed to assess and fix the code," Mr Doheny says. It also makes testing easier, as the software produces a complete checklist of everything that has been changed. Although fixing doesn't require powerful computers, testing needs the fastest computers a customer has, which may mean buying a complete separate system where existing computers are already in use all day