IPENZ Engineers New Zealand

HOME > publications > engineering-NZ > volume52-1997 > 1997-03-mar

Back to Publications

New Zealand Engineering 1997 March

Festures

Judgement Day

Story by Peter King

Will you be a survivor or DDuMMYY ?

At NZT12.00am on Tuesday, 31st of December 1996 the control software on all 660 process control computers at Comalco's smelter at Tiwai Point hung. Although staff worked furiously to keep the pot lines rolling by manually over-riding the computer system, five pot cells overheated and will have to be replaced at a total cost of about $1 million. Two hours later the same thing happened at the Bell Bay smelter in Tasmania. The problem: Comalco programmers had forgotten to take into account the 366th day of 1996, a leap year. The result: untrapped errors suspended all processing across the entire system.

Three years hence the passing of 12:00 am on Saturday, 1st of January AD 2000 will be a moment when all around the world software and electronics engineers will hold their breath and cross their fingers. They will be hoping that every program on their systems which ever contained that deceptively familiar date variable declaration DDMMYY ( for two bytes each for day, month and year) has been found and the processes which deal with it modified. The probability is, however, that some systems will fail, either because of date calculations based on arithmetic or failure to account for the year 2000 leap year, and the Comalco experience will be repeated in companies around the globe as the world enters the new Christian millennium.

Not that any of those engineers whose systems fail will have anyone to blame but themselves. The date calculation issue, or the Y2K problem as it is widely known, where, due to truncated data fields, the year 00 will appear less than the year 99, has been discussed in information technology circles for years. The problem has been making people realise the time horizon for dealing with the problem may not be as long as they might want.

Time is running out
Bob Smith is the information technology manager for Telecom.

"I think what has surprised me has been the scope of the change management process we've realised we are now engaged in. It's one thing to identify a problem but it is another thing to move a broad range of systems into year 2000 compliance while maintaining operational capacity. For example, we've just put in one year 2000 compliant system which, because it has to relate to other non-compliant systems, has to have bridging software to operate."

Telecom began looking at the year 2000 issue last year with a preliminary investigation to check whether a problem existed. The investigators soon found systems which were not going to cope with the arrival of the new millennium and Telecom moved to appoint consultants to scope the problem. That report is due on Mr Smith's desk this month, providing the first clues as to the sort of budgetary impact the Y2K problem is likely to make on New Zealand's largest corporate.

Coincidentally, ECNZ Information Technology manager Peter Mayhook will be receiving his consultant's scoping report at precisely the same time. Both managers are keen to have their year 2000 compliant systems operating for a full year before the year 2000 to provide a safety buffer if one is needed. Neither Mr Smith nor Mr Mayhook see any profit in attempting to "contract out" of managing the Y2K problem. In the end any software failure which seizes up their productive plant or corrupts their billing data will create competitive issues which no amount of damages would ever fully recompense. Both companies are therefore adopting a policy of supporting key customers and working with key suppliers to ensure information about the problems are disseminated as broadly as possible.

Looking at PABXs Mr Smith says Telecom is keen to help companies even if they have purchased their PABX elsewhere.

"In the end it doesn't do us any good if our customers are hit by this problem, so we are trying to do as much as we can to improve awareness and share information."

For Mr Mayhook the issue has been making sure that there are no downstream problems once power is generated, so ECNZ has been keen to offer help to network company Trans Power to achieve year 2000 compliance as well.

Escalating costs
For large organisations with complex systems this seems to suggest that if you have not started your year 2000 planning now you are already behind the eight ball. Unisys Y2K programme consultant Russell Withers puts it this way:

"The later organisations leave it the more expensive the whole exercise will get because there is only a finite resource of people around who can be called on to help fix it and as the big day gets closer the demand is going to grow. That means that a project that might have cost say $10 million today will cost $25 million by this time next year and so on. As one of my friends in Australia said in an email to me the other day, `when you've got people by the two digit date code they will follow your rules'."

Asked if people may cynically suggest the whole issue has been hyped by consultants in order to extract more money, Mr Withers responds that companies may believe what they like but the year 2000 issue is not going to go away. "It's as sure as death and taxes that there will be a year 2000 and come that day people are going to be sorted into those who did something and those who hoped nothing would go wrong. It doesn't really matter what organisations do so long as they think about the issue, even if they quickly conclude that there really isn't a problem, just as long as they have given it some proper thought." Mr Withers suggests that that thought isn't confined to quick conversations in the tearoom either. "Directors are going to have a duty to demonstrate that they have been duly diligent over the issue. If they haven't got something to show that their organisation at least had a look at the problem - even if the report was wrong - they put themselves at risk in terms of fiduciary duty. The same applies to acquisitions. If one company acquires another does the acquirer know whether the purchased company's systems are compliant or whether, come the end of the century, they will have a nasty surprise in store."

Rudd Watts and Stone law partner Gavin Adlam concurs. He too warns that directors should have some form of documentation to support any claims they may have that they have had the year 2000 problem examined. Mr Adlam points out that companies may not even be directly affected, a failure by a supplier as remote as a haulage company due to the problem may also cause business loss which should have been anticipated. "It ends up becoming a part of an organisation's complete contingency planning."

Let the supplier also beware
Mr Adlam also warns suppliers that unless they have supplied equipment making clear representations that from a specific date the equipment can no longer be used, the customer has a clear right to assume it can continue to be used. If the equipment then fails on the 1^st of January 2000 or thereafter causing loss, the supplier may find itself in a sticky situation. "At first I had thought that this was just a straightforward technical problem with a date but as you get into you start to see the permutations and combinations become quite alarming" he says.

Of course one of the problems is establishing how deep into the logic of a system one is prepared to go. At the uppermost there is the customisation level where a surprisingly large number of organisations use simple systems to make quite crucial decisions. Many large financial institutions rely on the spreadsheet in the economist's office to plot forward cash positions. These systems are often unaudited at the best of times and may be overlooked. Then there is the applications and operating systems levels which will receive most of the attention from any professional information technology team embarking on an Y2K audit; and finally there is the hardware level where any date logic errors burnt into EPROMS (erasable programmable read only memory) will be practically impossible to pick up by anyone other than the supplier.

To help customers, a worldwide Y2K compliance programme has been developed among suppliers. In this country the Information Technology Association of New Zealand has established a web site devoted to the issue (http://www. Itanz.org.nz) which includes a list of compliant suppliers and links to its US and British sister organisations.

While the risk of chip level programming errors are probably the main cause for concern among engineers, working without source code makes it practically impossible for any customer engineer to take ownership of the problem and this can only be pursued with suppliers. For their parts Fisher & Paykel Electronics general manager David Grant and Harding Electronics engineer Stuart Parker say that their domestic electronics and traffic lights systems built here do not use date based functions anyway and so the problem does not arise.

Overseas the United States Department of Defense has testified before Congress (http:///www.army .mil/ army-y2k/ osd-Y2K /c3itest.htm) that it is treating the problem very seriously with literally hundreds of millions of lines of code to work through. Because many weapon systems incorporate their own maintenance management systems the potential problem is quite large. Closer to home the New Zealand Defence Force began work on the problem in April 1996, passing management of the problem down to the respective Services and the corporate computing unit. Commander Rex Edwards, who reports to the Chief of Defence Force on the matter, says the first scoping report on the problem is due on April 1^st 1997 but has been heartened to hear informally that to date no problems have been found.

For many engineers the safety issues caused by the year 2000 problem will be, at most, theoretical matters of speculation, but for one of New Zealand's leading "conciousness raisers" on the issue - John Good, a consultant with Azimuth Consulting, and originally trained as a mining engineer _ this is more of a pity than anything else. " I think the end of the century problem highlights two major concerns. One of them is the way we have allowed information systems designers to get away with designing and building systems with a lot less rigour than would be expected from traditional engineering disciplines. On the other hand, engineers were certainly less than enthusiastic about accepting information technology as a legitimate discipline of their profession."

Mr Good believes that the community is only now beginning to realise the ubiquity of automated systems in their lives and the year 2000 problem is a healthy reminder to both the community and professional technologists that they can no longer afford to treat software development as anything other than a complete engineering exercise.