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 Y2K problem stems from decades of programming practice that conserved memory and keystrokes by representing years with two digits instead of four (e.g., 99 rather than 1999). This worked fine from the dawn of modern computing until now. The problem with switching from "99" to "00" at the end of this year is that the second number is smaller than the first. Computers that aren't programmed to recognize 00 as 2000 may assume that anything that happens in 00 took place before 1999 (i.e., in 1900).
Someone said that the year 2000 problem is about 85% hype and 15% real. And the essence of the problem is that we don't know which 15% is real.
--Steve Dickson (F&A)
These questions have been on the minds of F&A's Steve Dickson and the seven other members of the UCAR Y2K Task Group at least since the end of 1997. With Steve as project manager, the group has developed a working document designed to keep UCAR moving forward on Y2K issues (see UCAR Web sites). The plan is part of UCAR's response to notification by NSF to "take all steps necessary to mitigate potential [Y2K] problems." Those steps must be taken within existing funding. How do you equip a multifaceted organization like UCAR to mitigate potential Y2K problems with no additional funds? Staff around the organization are making room by putting other projects on hold. "We just kind of squeeze it in," Steve says.
So far, that strategy is working. "Most of the problems," Steve notes, "the ones costing gazillions of dollars to fix that everybody's talking about, are COBOL code in large-production operations like banks, manufacturing, or utilities. . . . We don't have any of that in this organization.
I am not concerned about our ability to continue delivering data and computational resources to the UCAR community--outside of things that are beyond our control.
--Tom Engel (SCD)
It's a chaotic system, just like the climate, where small perturbances in one part of the world can cause calamitous effects in other parts of the world.
--Pete Peterson (SCD)
"The target is April to have all our systems upgraded to vendor-supplied, Y2K-compliant software," says Tom. While all the supercomputers have been upgraded, a few other systems might not make that target. "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, Tom 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]."
Basil Irwin is Y2K project leader for NETS. He says the current proposal "is scaled down but offers SCD testbed facilities that will be available for others." The new design uses equipment in the production network while keeping test traffic logically isolated from production traffic. Some money may need to be spent, according to Basil, to test host-based services like DNS (domain name service, a part of Web administration) and e-mail. (See UCAR Web sites for more on the testbed proposals.)
Nobody that's honest will tell you that the power grid definitely will not fail. Hopefully the probability is close to zero, but no one knows how close to zero it is.
--Basil Irwin (SCD)
Basil is disappointed in the lack of additional funds for testing. "My personal opinion? It makes me wonder how serious [NSF] is about really fixing things. The institutions that are serious about fixing this problem have spent hundreds of millions of dollars." Here at UCAR he sees a lot of effort to address potential problems at the grassroots level, but a lack of oversight. "I'm seeing bottom-up, but not top-down. There are lots of isolated pools of people dealing with it in a noncoordinated fashion." On coordination, Steve Dickson concurs: "It's not clear in all cases who's got operational responsibilities, and maybe that needs to be more centrally coordinated."
ATD: UCAR Y2K Task Group member Susan Stringer is a software engineer in ATD. "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 prioritize their mission-critical systems and start the upgrading process.
Although staff are spread thin, Susan isn't expecting a crisis. "We'll keep plugging away with the resources we have and see how it works. 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."
Ron Ruth manages data for 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." Ron 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," Ron explains.
RAF is examining two systems on the aircraft themselves: the inertial navigation system and the Global Positioning System (see It's not just the year 2000). 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, Steve Dickson doesn't want to take chances with the aircraft, even if they're upgraded in time. "We probably will avoid flying at midnight on December 31st because the consequences of us being wrong are not tolerable. The risk is too great," Steve says.
ACD: Division administrator Brad Crysel, who also serves on the Y2K Task Group, has been making sure their administrative systems are compliant. "Our division director, Guy Brasseur, has made it an area of emphasis." They've purchased machines from the same vendor within the past year, at least partially to ensure Y2K compliance.
ACD systems administrator Tim Fredrick emphasizes the distributed nature of the problem. "Fixing the Y2K problem is really something that happens at many different levels. 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." Tim is hopeful that staff in the division will take a look at what they're responsible for and communicate with him. He points out that "each programmer who is responsible for code in ACD and at NCAR will need to take a careful look at that code to fix Y2K problems."
Tim has completed a good deal of testing on the division's central systems. He's hoping to attach clones of ACD's two primary servers to the NETS testbed "to further prove to myself that those systems will be able to provide the services on January 3 that they provide today."
UOP: Unlike NCAR's research divisions, most of UOP's activities were spun up in the past decade, when Y2K awareness was already starting to emerge. Thus, they have a head start on compliance. "We've talked to every program in UOP," says Kathy Strand, manager of budget and administration for UOP and the contact person for the office's Y2K effort. "Some problems were identified, but they're being taken care of. Overall, we are in good shape and feel as if we've checked things out."
We will try to touch base on everything we have. Routine maintenance should uncover most concerns.
--John Pereira (FSS)
If there are power fluctuations, SCD's supercomputers can be safeguarded in a number of ways. The uninterruptible power system (UPS) gives machine-room technicians about 15 minutes to power down, protecting delicate disk drives from power spikes. SCD's Infrastructure Support Group has installed a new UPS that, among other things, is Y2K compliant. (Problems in rebooting equipment after the UPS installation resulted in a computer shutdown that affected several SCD systems on Friday, 22 January.)
A history of cooperation and communication with Public Service Company provides UCAR with another level of protection. "We have an account representative, so we have direct contact," says John Pereira (FSS). After the snowstorm in April 1997 there were successive power outages the next day. "Problems started about seven in the morning," John recalls. Public Service "told us they couldn't guarantee stable power for the next 24 hours or so. So SCD decided not to bring everything back up until it had stabilized. . . . The decision to shut down happened about ten in the morning, and the computer room didn't have stable power until sometime after midnight."
If, as the most extreme Y2K warnings predict, the power grid were to go down for an extended period, UCAR facilities would close until power was restored, according to Steve Dickson. "We've got emergency procedures for closing the facilities, with all the steps and who's responsible. . . . We can essentially mothball our facilities. The chances of that are very remote, but it's the sort of thing we need to talk about."
The part of emergency planning that Steve Dickson would like to see develop further is communication. "The year 2000 problem is going to have at least a community-wide impact, not [just in] individual locations." He would like to see ongoing communication with UCAR constituents "so they understand where we are, what our problems are, and have confidence that we are giving them as much information as we can [and are working] to minimize the inconvenience."
Steve Sadler, who's been in charge of Health, Environment, and Safety, has just donned an additional hat as director of all those functions plus Security. As he settles into his new responsibilities, he'll be carving out some time to investigate Y2K issues and consult with others around the institution. "As far as security goes," says Steve Dickson, "we're interested in data security"--keeping hackers out--"and physical security. We'll be looking at both of those things to make sure that we're on our toes."
According to UCAR president Rick Anthes, "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. I am confident that everyone in the organization will help make that happen, so we can get on with our business of research and service."
So how does project leader Steve Dickson sum up UCAR's preparations for New Year's Eve 1999? "We've made an incredible amount of progress, and I'm pleased with that. But the problem is we're running out of time. As the deadline approaches, the attention will increase. But it's about time to turn on the afterburners and hit it. And I think we're doing that, in most areas." Zhenya Gallon
Staff Notes Monthly will revisit UCAR's Y2K planning as the year progresses.
Y2K resources and answers
The Whole Year-2000 Catalog: Y2K on the Web
It's not just the year 2000
Getting in and phoning out
What about the physical plant?