UCAR and Y2K

UCAR > Communications > Quarterly > Spring 1999

Spring 1999

UCAR and Y2K

It's not just the year 2000

Not all millennium bugs will wait for 1 January to appear. On Saturday, 21 August, at 0000 Greenwich Mean Time (6:00 p.m. Mountain Daylight Time), the world's Global Positioning System (GPS) satellites will have to hurdle a time-code glitch of their own. Although this problem has nothing to do with Y2K, the possible impacts on transportation and other areas could be significant.

Call it the week zero problem. When the initial NAVSTAR network of GPS satellites was launched in 1979, week one was labeled 0000000000 in ten-bit binary code. Week two was indicated by the binary code 0000000001 (denoting 2), week three by 0000000010 (denoting 3), week four by 0000000011, and so forth. "The engineers who set up GPS said 'How many bits do we need?' and decided 'Uh, ten bits,' and so at week number 1,024 it goes back to zero," says Randolph Ware, director of GPS Science and Technology (GST, formerly UNAVCO).

That week of reckoning--the week that follows 1111111111--arrives on 21 August. At that point, the timekeeping software aboard the GPS satellites will reset to 0000000000. In effect, the software will think it's 1979 again, analogous to Y2K-vulnerable software that will interpret next year as 1900. "It's the NAVSTAR millennium," says Ware, "a singular event in GPS history."

The key question is how the wealth of GPS receivers and related software will handle the rollover to week zero. Ware says that some manufacturers have pledged their readiness, while others aren't making any promises. One company's receivers failed to handle the transition from week 0111111111 to 1000000000 in 1989. (That firm later went out of business, although it may have been unrelated to the transition failure, says Ware.)

"The satellites are all set to roll over and just keep transmitting with the new [zero] time, and it's up to the GPS-receiver manufacturers whether or not their hardware and software can deal with that," says Ware. "The receivers may not work unless they're upgraded." According to Ware, anything that relies on GPS signals--aircraft navigation systems, traffic lights that use GPS for timing, and more--has the potential to malfunction if the bug isn't addressed. GPS is not yet an FAA-approved standard for aircraft navigation, but some private pilots and smaller airports already make use of it. "I wouldn't want to be trying to land a plane with a computer that thought it was 1979 instead of 1999 without knowing all the implications of that," he adds.

GST has asked the Jet Propulsion Laboratory and Trimble Navigation to provide simulated GPS signals for week zero from their signal generators. These simulated signals can be used to test the response of receivers so that GST staff can understand and (they hope) correct any problems before week zero. Meanwhile, ATD director David Carlson has been checking with manufacturers of GPS components used in ATD's dropsonde and radiosonde systems. Thus far, he says, he's encountering confidence that problems in the use of these sensing systems will be minimal. • by Bob Henson, UCAR Communications

by Zhenya Gallon
UCAR Communications

You can't turn to your favorite news medium these days without encountering a story about the year 2000 problem (also known as the millennium bug)--the question of how computers will deal with the fact that computer shorthand for next year, 00, is a smaller number than 99, the two-digit version of this year's date. UCAR received notification from NSF to "take all steps necessary to mitigate potential [Y2K] problems," but to do so within existing funding.

To accomplish this directive, UCAR's Y2K Task Group has targeted "mission-critical" activities as its top priority. The consensus of the group is that what's truly critical to UCAR's mission is the performance of the scientific supercomputers and related user services. To find time to assure that supercomputing and other facilities, along with a few other areas such as health and safety, will continue to function after New Year's Eve, staff are putting other projects on hold to tackle this problem.

What's happening in SCD?

Al Kellie, the new director of NCAR's Scientific Computing Division, was the project director for Y2K compliance at the Atmospheric Environment Service (the Canadian weather service), which was identified as a mission-critical system for the Canadian government. His budget was roughly Can$25 million, and when he left, "the count was about 360 FTEs involved." However, Al adds, "I am not charged with the same responsibilities at NCAR, nor am I proposing the same degree of zeal at SCD. This is a research institute. If we have to go down for a short period of time it's not as calamitous. . . . But it's very important that we do as thorough a job as we can so we can continue to provide services."

SCD's plans for the supercomputers and other systems in its purview can be found on the Web. The first step was to identify all equipment with potential problems. The next step was to obtain manufacturers' upgrades.

"The target is April to have all our systems upgraded to vendor-supplied, Y2K-compliant software," says task group member Thomas Engel, who manages SCD's High Performance Systems Section. All the supercomputers have been upgraded, but a few other systems might not make that target. Engel points out, "The time we have to become compliant keeps decreasing, and yet it's only been in the last one to three months that our major vendors have released Y2K-compliant systems and product sets. So we're trying to play this balancing game between becoming compliant and not destabilizing our production environment."

Waiting for vendors to supply upgrades has slowed the installation and testing process--not just for the supercomputers, but for desktop systems as well. For the many people running Microsoft's Windows NT, for example, Engel notes that Version 4.0, Service Pack 3 "was proclaimed Y2K compliant when it came out," but then some noncompliant features were identified. "I anticipate that the same thing is going to happen with Service Pack 4. And there may be patch sets that we'll have to obtain from Microsoft [to fix that]."

Testing, testing

Even after systems are upgraded, they still need testing to see how they'll perform with the clock set to the year 2000. SCD has proposed a testbed to accomplish that task, not only for its supercomputers and other systems, but for other UCAR users as well. SCD's Network Engineering and Technology Section (NETS) is proposing a dual-purpose testbed using "hot spares" already attached to existing networking systems. (Hot spares are run attached to production systems so they can be tested continuously and upgraded with new software whenever the production system is upgraded.) The proposed configuration would allow anyone in UCAR to connect to the testbed.

Basil Irwin is Y2K project leader for NETS. He says the proposal "offers SCD testbed facilities that will be available for others." The design keeps test traffic logically isolated from production traffic. Some money may need to be spent, according to Irwin, to test host-based services like DNS (domain name service, a part of Web administration) and e-mail.

The NETS testbed is not designed to put the supercomputers through their paces. That's the responsibility of the Supercomputing Systems Group. According to SSG's year 2000 Web pages, the group will acquire a small SGI Origin 2000 for system testing. The plan is to configure that computer as a stand-alone testing environment. To test how CRAYs handle Y2K will require removing one from production and configuring it for testing only.

Elsewhere in UCAR

A variety of other preparations are under way within UCAR's divisions and programs.

Aircraft. Ronald Ruth manages data for NCAR's Research Aviation Facility (RAF). Most of the instruments on the NSF/NCAR aircraft are analog sensors that transmit voltages in real time. "We don't have a lot of date stuff going on." Ruth is confident that in the few cases where dates are involved, fixes will be uncomplicated. RAF custom-built the data acquisition system for the aircraft it operates. "We have the ability to convert to four-digit dates when we do ground processing of resulting data sets," Ruth explains.

RAF is examining two systems on the aircraft themselves: the inertial navigation system and the Global Positioning System (see sidebar). Both are crucial for flying long routes over the oceans. "We've called the manufacturers and they've said 'We're not worried about it, but we're still working on it,' " says chief pilot Henry Boynton. "That's their business, so I'm sure they'll have fixes for it. It doesn't make any sense to worry about it." Still, Y2K project manager Stephen Dickson (UCAR Finance and Administration) doesn't want to take chances with the aircraft, even if they are upgraded in time. "We probably will avoid flying at midnight on December 31st because the consequences of [our] being wrong are not tolerable. The risk is too great," Dickson says.

Other facilities. UCAR Y2K Task Group member Susan Stringer is a software engineer in NCAR's Atmospheric Technology Division. "We're trying to inventory everything we have," she reports. Some of their computers, scientific equipment, and software were purchased off the shelf, and some were built by ATD staff. "We have embedded processors in some of our equipment that someone put there 15 years ago, and [that person] is no longer here." Once they've figured out where the problems are, they'll start the upgrading process. "A lot of our problems are probably in our postprocessing software, where the date 00 will show up, but it's not going to stop the system."

Computer models. Systems administrator Timothy Fredrick (NCAR Atmospheric Chemistry Division) emphasizes the distributed nature of the Y2K problem. "We're not in a position to fix models or applications that scientists have developed, but we are in a position to apply vendor updates to the systems on which those models run. . . . Each programmer who is responsible for code [that they plan to run] at NCAR will need to take a careful look at that code to fix Y2K problems."

UOP. Unlike the NCAR divisions, most projects in the UCAR Office of Programs spun up in the past decade, when Y2K awareness was already starting to emerge. Founded in 1983, Unidata is UOP's oldest program, but most of its software development has taken place in the 1990s. "Our code has all been written within the last seven years, using the newer languages with none of these Y2K problems," reports Sally Bates. Nearly all of Unidata's software is created in house, and "the software we distribute by others has all been made Y2K compliant." For example, the McIDAS interactive display package, created two decades ago at the University of Wisconsin, has reportedly been brought up to speed by UW.

UCAR president Richard Anthes summarizes, "It's important that we all take the year 2000 issues seriously but at the same time not overreact. UCAR and NCAR management are committed to taking all reasonable actions to make the transition from 1999 to 2000 as smooth and nondisruptive as possible."

In this issue... • Other issues of UCAR Quarterly
UCAR • NCAR • UOP