UW team works to head off the ultimate deadline: 2000

Robert Irons caught a glimpse of the future last year during a trip to Disney World with his daughter. His laptop computer burned up on him, cutting him off from work and e-mail. Irons called his wife the next day, only to find that their home computer was also toast from a nearby lightning strike.

Then, the triple whammy: His cellular company notified him his cell- phone number had been cloned during a recent trip to New York City, and his account had to be closed down.

“We still went to Disney World and we still had a good time,” explains the UW–Madison computer specialist, “but this was incredibly annoying. It took weeks to get everything back to normal. Then I thought to myself, this is how the whole world is gonna feel in a couple years.”

Irons, UW–Madison’s go-to guy on Year 2000 computer problems, is sure that nuisances great and small will greet electronics users like a bad hangover in the new millennium. But he is working to minimize those problems on the UW–Madison campus with a campaign to make the university’s operating systems bug-free by July 1, 1999.

Irons and his five-person staff started by getting their own house in order, evaluating code throughout the Division of Instructional Technology (DOIT). Last spring, he evaluated 1.6 million lines of code in the university’s sprawling accounting system, fixing all the date-related glitches they encountered. Next in line are the student registration and payroll systems.

“We’re serving as consultants for the entire campus,” Irons says, encouraging any office that’s worried about software to give him a call. “We have a great capability of fixing our own software. But if you do nothing, all of these problems people are predicting will come true.”

What problems could possibly be caused by an innocent date? After all, the problem looks deceptively simple: To save memory, early computers had years represented by two rather than four numbers (81, rather than 1981), meaning that when the new millennium rolls around, “00” will look a lot like 1900.

So what? Well, experts believe a cascading effect of incorrect computations will start to occur with any tasks that are date-dependent. Many experts think it has frightening implications for industries such as airlines, utilities and banking.

Thomas Reps, a UW–Madison computer scientist, offered a down-to-earth scenario for consumers. If you decide to purchase a life insurance policy in January 2000, the computer will calculate a premium based on your average life expectancy. A person born in 1964, to the computer, will either be 36 years old or minus-64, in which case a hefty refund is in order.

“When the rollover hits, it will be as if everyone will be running a new piece of software that hasn’t been tested,” Reps says.

Reps was recently tapped for a vastly more complicated problem. He served as a consultant for the Defense Advanced Research Projects Agency (DARPA), the high-tech arm of the defense department, on the Y2K issue. The agency wanted Reps to identify basic university research that could be applied to the problem.

Reps found one technology, called “path profiling” and developed by UW- Madison computer scientist Jim Larus and student Tom Ball, could be useful. It can help tease out date-related problems by feeding a program pre-2000 and post- 2000 dates, and looking for differences in the path profiles.

He proposed to DARPA an accelerated program to develop a suite to help correct the problem, but it did not receive funding.

“Ultimately, the officials who DARPA’s senior management report to decided the Y2K problem was someone else’s problem to fix,” he says. That was almost two years ago, and Reps is now convinced the agency faces “enormous problems.”

For example, one DARPA project that carries out space surveillance in the northern hemisphere include more than 70 different interacting subsystems, all of which are large and many are old. The messages they pass around carry time- stamps with two-digit years, which could wreak havoc at the turn of the century.

Irons believes the real Y2K dilemma is not one of complexity, but of complacency. From his experience so far, Irons has found the bugs to be far less “dense” in computer code, showing up in one is 5,000 lines of code rather than one in 500. That’s makes it both cheaper and faster to fix.

For the older mainframe business systems that are most at risk, Irons recommends calling his office at 263-6909 or e-mailing bob.irons@doit.wisc.edu to schedule an appointment.

As for personal computers, Irons says no Macintosh computers are at risk of any year 2000 hardware problems, and the majority of all new computers are also compliant. A testing tool called YMARK 2000 exists for PCs and can be found at: http://www.nstl.com/html/ymark_2000.html.

There are some problems, however, beyond the user’s control. Any bugs in the “embedded chips” that control a wide range of equipment, such as cars, refrigerators, microwaves and VCRs, are at varying degrees of risk. But those problems need to be identified and fixed by the manufacturers.

While the hard-and-fast deadline has generated the most angst, Irons actually considers it a silver lining. “I am bored to death with this issue,” he says. “Since we have the solutions, it’s basically like factory work for me now.

“One of the things we’re all happy about — and my family is happy about — is this thing has a deadline.”