Interested in reading more?

Computer consultants warn that the cost of adjusting programs will skyrocket if researchers wait until after their systems crash Jan. 1, 2000, is coming. While self-proclaimed prophets are out pounding pulpits to warn against impending cosmic doom, computer programmers, engineers, and information specialists are wringing their hands over a far more mundane issue-how computers will handle the switch from the year 1999 to the year 2000. Many fear that some instruments and applications won't handle the change, because the programmers have instructed computer programs to track the year using just the last two digits (such as 98), leaving the century ambiguous. After Dec. 31, 1999, computers won't know whether the new year is 1900 or 2000. Sounds pretty harmless, doesn't it? But picture yourself on Monday morning, Jan. 3, 2000, the first work day of the new year. You sit yourself down in front of your DNA sequencer-coffee in hand-to check the weekend's runs. There seems to be a problem, though. The Saturday and Sunday runs are blank-no data collected. The computer is flashing some nonsense about these runs having already been completed-sometime around Jan. 1, 1900. What's that? Your system wasn't ready for the date change? Uh-oh. You've got some explaining to do. PLAN AHEAD: It could cost up to 10 times more to repair problems after a year 200 crash than it would cost to convert systems beforehand, warns consultant Capers Johns. There are in essence two kinds of software that must be dealt with-software purchased from a vendor and those programs that have been developed in-house. Store-bought software may need to be replaced by the software's manufacturer if it is not year 2000 compliant. But programs that have been written in-house to fulfill a specific need, such as sharing data between applications or coordinating automated tasks, must be corrected by the programmers who wrote them. That means correcting the code line by line to be sure that dates are read in unambiguous terms. That's an arduous task, but if your lab or company depends on in-house programming, it's well worth addressing before the clock strikes midnight, not after, according to year 2000 consultant Capers Jones, founder and chairman of Software Productivity Research Inc., a Burlington, Mass.-based research, development, and management consulting firm that also counsels companies on handling the year 2000 conversion problem. Jones predicts that the cost of repairing problems following a Jan. 1, 2000, crash will be two to 10 times more than the cost of updating software and equipment before the problems occur. Dates can have far-reaching implications. "Time stamps are often used for sorting, categorizing data, and setting alarms," among other applications, says Jeff Bloom, vice president of business development at Turnkey 2000 Inc., a year 2000 consulting and software-development company based in San Jose, Calif. "Much of instrumental software is related to time stamping, and of course no one can really know what the impact will be until someone looks." Turnkey 2000 has developed a program called UNRAVEL that helps organizations determine the impact the year 2000 bug will have on their applications, and to analyze and correct code. And if the programmer who did the work has moved on? "Bring the programmer back . . . either that or pay more money" to have someone come in and analyze the code, advises Dave Ghosh, CEO of Turnkey 2000. Jim Lynch is a consultant at Ajilon Services Inc. of Towson, Md., an information technology consulting firm that is working with DuPont-Merck Pharmaceutical Co. to help the Wilmington, Del.-based firm deal with the year 2000 transition. He concurs that for those with the programming expertise, the bug is a potential boon. "It's not a career, but it is an opportunity to pay a few debts or buy a bigger house," Lynch says. So you've got a roomful of computers and instruments, much of them sharing time-related data. What to do? "The absolute best advice is to get on it as soon as possible," says Jim Lynch, a consultant for Ajilon Services Inc. of Towson, Md., an information technology consulting firm that is helping Wilmington, Del.-based DuPont-Merck Pharmaceutical Co. manage its year 2000 problem. Instrument manufacturers will be swamped with requests the closer it gets to December 1999, he predicts. First of all, Lynch advises researchers to call the manufacturer of each of their individual instruments and computers to find out if all the different units are year 2000 compliant. But if you've got a lot of instruments and several technicians, centralize the process by having one person do it, recommends year 2000 consultant Capers Jones. Those instruments that have passed the manufacturer's test can be crossed off the worry list. Remaining instruments that are not compliant, and those whose status is still unknown, should be graded according to their function, with high-priority functions attended to first. "You have to do a triage," says Lynch, referring to the method used by battlefield surgeons, ushering the most critical patients into surgery first. Identify which systems will produce the most dire impact on your lab if they go down on Jan. 1, 2000-keeping in mind not only that they will not work, but also that the manufacturer's technical team will likely be far too swamped on January 2 to be much help. Other systems can be ranked in order of importance, with some glitches being merely inconvenient and others (such as the wrong date printed on a word-processor document) hardly noticeable at all. Options for handling noncompliant systems include purchasing new equipment, putting additional pressure on the manufacturer to provide a fix, or bringing in a specialist to crack open the instrument and correct the problem.-J.K. Although fixing errant code is a daunting challenge, others are more worried about so-called embedded systems-in which software is stowed away in inaccessible chips. Any lab instrument that carries out automatic tasks is relying on software that contains a time function, and if there is no software interface (such as a computer), its operation is likely being controlled by a chip squirreled away somewhere within the instrument. "Chips are often trickier to fix. . . . Vendors have to get involved, and I'm not sure they are even aware of [the problem]," says Software Productivity Research's Jones. Deborah Madsen, technical team leader for standards and product performance at Beckman Instruments Inc. of Fullerton, Calif., agrees with the sentiment: "I don't think there's enough awareness out there yet; people aren't taking it seriously enough." Beckman is feverishly working on its own instrumentation, testing each device to see which models will handle the year 2000 transition. "We have gotten inquiries from users-we have set up an internal system to handle them," says Vlad Ghiulamila, manager of global product standards and certification at Beckman. "If the product in question is compliant, we will provide a statement of compliance. If the product is not yet certified or we are not sure of it, we'll tell them that we're working on it and keep them posted on when certification is completed." Fortunately, not all instruments will hiccup on that fateful day. Many devices don't process dates at all, and so will be unaffected, while some that do use dates will have been written with unambiguous code. "I don't think you can make any generalities," says Madsen. REAL-WORLD PROBLEM: University of Washington's Mark Haselkorn notes that the main issue is information transfer and how dates are defined. But those programs that use dates-including many that are embedded in the chips that drive instrumentation-may be integrated into other processes, swapping data and information back and forth, so that one failure could disrupt the workings of surrounding instruments. "It's an interdependency problem," notes Mark Haselkorn, a professor of technical communication at the University of Washington, who has been retained by the National Science Foundation to help coordinate its external year 2000 activities. "To think that you are 65 percent done because you've [corrected] 65 percent of your trouble spots is wrong." The Beckmans and Hewlett-Packards of the world have the resources to tackle the year 2000 problem, but smaller suppliers may not be able to afford the extensive testing and repair necessary to certify their instruments. Networks made up of instruments from various manufacturers are a particular challenge, because even if most of the components handle the date transition, that glorified bean-counter in the middle could shut down the whole system by passing along an ambiguous date. For instance, "say a [lab] has a number of instruments linked, then over a network you collect data from each instrument," explains Bill Pelster, quality initiatives manager at Cleveland-based Keithley Instruments Inc., which develops electronic test and measurement equipment that often finds its way into scientific instrumentation. "If there's a product out there you are counting on for time information and it's noncompliant, that can affect the whole system." AT WORK: Beckman Instruments' Deborah Madsen and Vlad Ghiulamila says their company is testing its instrumentation and handling inquiries from users about year 2000 compliance. And if all that weren't enough to cause lost sleep, that trusty desktop computer you bought last month may not be safe, either. There is an internal chip in most PC's that tracks the date-called the BIOS chip-and 47 percent of the computers sold in 1997 had BIOS chips that were not year 2000 compliant, according to figures released by Greenwich Mean Time, a company based in the United Kingdom that is analyzing software programs for year 2000 compliance. "Any software that gets dates from the BIOS chips will not function correctly," Beckman's Madsen insists. As dire as all of that sounds, Haselkorn warns against focusing too intently on software and hardware fixes, while ignoring the larger issues of information transfer and how dates are defined. "The biggest myth is that [year 2000 compliance] is primarily a software problem," he says. "It's about how dates are used in the real world, and that's what makes it messy. A database is not just a bunch of values; it is data structure, data definitions. Even the ways user communities define dates evolve over time. If you think your information system is solely hardware and software, you're going to miss the way it works." James Kling, a writer and consultant based in Bellingham, Wash., is producing a year 2000 resource geared toward scientific applications. For more information, contact him at jkling@nasw.org.

Act Now To Avoid Doom When The Year 2000 Comes

Jan 4, 1998

Interested in reading more?

Become a Member of