Time is slipping away on Year 2000 fix

For government officials coping with the Year 2000 software emergency the missing ingredient is time both in computer date fields and on policy calendars not enough time to launch procurements appropriate money agree on standards or get the word out. 'Usually in a computer project dollars are the

For government officials coping with the Year 2000 software emergency the missing ingredient is time both in computer date fields and on policy calendars - not enough time to launch procurements appropriate money agree on standards or get the word out.

"Usually in a computer project dollars are the most critical resource and you set a schedule and the schedule slips " one Year 2000 policy-maker said. "In this case the schedule can't slip. At some point we'll pass a point where no matter how much money we put on the problem we won't be able to fix it because we can't fix the schedule."

The problem stems from the two-digit year fields found in software hardware and firmware. When the Year 2000 arrives many computers will display 00 as the year and interpret the result as Jan. 1 1900. The resulting inaccuracies in date-based calculations comparisons and sorting will generate corrupt data and cause systems to crash. Failure to fix the problem will cause more than just computer snafus. The agencies' very missions could be threatened.

"It's more than just their computer systems " said one government official who is helping oversee solutions to the problem. "It's important that agency folks realize that their business livelihood depends on their fixing this."

To help fight agency inertia an "awareness" campaign is being staged at the highest levels of government and so down to the rank and file: The President's Management Council has been briefed - twice - on the problem by the deputy director for management at the Office of Management and Budget which is acting as "corporate headquarters" for managing the crisis.

But awareness is cheap. Fixing the problem will be expensive. So far estimates are soft but they range from $2 billion to $30 billion for the federal government alone. No hard estimates will come in until January when OMB will have sifted through Section 43 information technology budgets for fiscal 1988 which federal agencies must file by Nov. 1. That is also the deadline for agencies to respond to language in the fiscal 1997 Treasury and Postal appropriations bill that asks OMB to report on a comprehensive strategy for fixing agency systems.

Those reports should reflect agency estimates of what they will need in fiscal 1998 and what funds they wish to "reprogram" from their 1997 budgets to target the Year 2000.The problem of course is time.

"I would hope that agencies show considerable dollars that will be reprogrammed " the government official said. "Because in 1988 from a systems development point of view you need to be pretty far along that's where you're going to need a lump of money."

Based upon a general methodology created by the Year 2000 Interagency Committee a group that meets regularly to discuss Year 2000 issues agencies will need the 1998 lump to finance the brute code renovation in those systems they intend to keep. The last year 1999 should be devoted to testing. But according to a report card on agency readiness issued earlier this month by Rep. Steve Horn (R-Calif.) chairman of the House Government Reform and Oversight Committee's Subcommittee on Government Management Information and Technology few agencies are likely to be ready. Less than half of 24 agencies surveyed by the panel earned a "C" or better.

But so far most agencies are not looking for nor expecting monetary handouts.

The Defense Department which is looking at costs of at least $1 billion is sticking to orders from Emmett Paige Jr. assistant secretary of Defense for command control communications and intelligence that DOD agencies take Year 2000 money "out of hide." What part of the department's hide? DOD is decentralizing the search according to Bob Molter chairman of its Year 2000 Workgroup. The first place would be operations and maintenance funds of the individual service agencies he said. "Those are the people that would generally be doing these fixes unless it is contracted out when it becomes too much of a workload for them " Molter said. "Then we have to look for other areas to get the funds from."

One of those areas may yet be Congress. Horn and Rep. Constance Morella (R-Md.) chairwoman of the House Science Committee's Subcommittee on Technology have indicated they will ask the Appropriations Committee to consider approving additional funding for agency Year 2000 fixes.

Should money earmarked for Year 2000 become available it must be used wisely one policy-maker cautioned. "Why are you going to develop new features to go on your system if the basic system you are going to put those features on is going to fail?" he asked. "You should rethink these new features or [consider whether] you should reorient some of that money to fix the system itself."

Assigning Responsibility

The flip side of how the government will fund the Year 2000 problem is what responsibility vendors bear for systems that are programmed to self-destruct on Jan. 1 2000 or that might still crash even if fixed.

The government's first attempt to address the problem was language in the 1997 Senate Defense authorization bill asking the secretary of Defense to ensure that all systems purchased after Sept. 30 1996 comply with time and date standards for providing "fault-free" processing of date and date-related data in 2000. When the General Services Administration developed similar language for Year 2000 contract modifications recommending warrants for fault-free performance vendors got nervous.

"The language did not define Year 2000 compliance and `warrants' is a very high standard - not one you find in the commercial sector " said Olga Grkavac vice president of the Information Technology Association of America's Systems Integration Division. But the Year 2000 Interagency Committee which is working with GSA on the contract language is expected to produce a final recommendation later this month that sources said will back off the fault-free standard. In addition the Senate is expected to soften language holding agencies to a deadline for fault-free compliance.

But that may not settle the issue entirely. "I think it's going to be a difficult thing to enforce because it's not like there is an [American National Standards Institute] standard out there for Year 2000 compliance " said Nancy Peters director of business development for Software AG Federal Systems Inc. "We will assure our own product set is compliant. The sticky part is where we hand a product over to a customer and they do what they want with it. We can't guarantee their use of the product."

"Right now we've been supporting sticking to more open language " said Maj. Ron Spear the Army's Year 2000 project director. "It kind of goes along with the acquisition streamlining that we've been doing and getting away from using mil standard and mil specs. Instead of telling them how to do it tell them what functionally needs to be done. A similar thing could be said for this."While a fault-free performance standard may be scrapped many contracts have latent-defects clauses that may be applied to the Year 2000 problem. Indeed the question of who will pick up the tab for maintaining compliance and performing code conversions remains sticky.

The answer may depend on whether it's a big problem or a little problem. "A contract for software development is one thing the purchase of a product is entirely different " said Judith Draper project director for the Year 2000 at the Social Security Administration.

"There's a difference between a PC that has a BIOS chip and a mainframe application that coordinates with maybe 50 other applications that is built over generations " ITAA's Grkavac said. "Industry is trying to be responsive but also believes this cannot be fixed for free. People are saying it's going to be a lawyers' delight."

Part of the problem is that the government has not encountered a problem of this complexity before. "I think it is virgin territory for the industry " said Spear of the Army which is still working out the legal ramifications of the Year 2000 problem on a case-by-case basis.

Be Specific

Whatever the solution vendors and agencies need to be "very specific not only [in] what agencies are asking for but also what vendors agree to " Grkavac cautioned. "Both sides may agree that a specific release is compliant but the government as well as companies have a lot of software that has been developed in-house and you really need to be very careful in your contracting arrangements that it's clear to both sides what each side is expecting and what one side is agreeing to."

"Because of the legal [issues] we've even had to be very precise about not making promises on date changes beyond the year 10 000 " Grkavac said. "We've had to be that specific."

In the end both sides will need to bend. "We don't want to lay a requirement on contractors that they can't meet " one agency official said. "But what we're not anxious to do is get into a lengthy negotiation about this. We need to come up with [standard contract language] that gets us 80 or 90 percent there and go with it."

Interface Issues

While most policy-makers have focused on creating awareness and ensuring compliance most agencies have not addressed the problem of interfaces or how communications with the outside world will affect compliant systems. What happens when systems are linked and defects are passed over networks?

"You may have a system in which you address the problem but that system also talks to five or six or several hundred systems and they may be passing you bad data which you think is good data and if you process [that data it] will give you a bad answer on your machine " said Terry Zagar chief scientist for BDM Federal Inc.

To ensure compliance among systems the National Institute of Standards and Technology has instituted a federal information processing standard change notice that strongly urges all agencies to use four-digit year elements. OMB has endorsed this standard for adoption by federal agencies. In addition the Year 2000 Interagency Committee decided "early on" that it would request a four-digit year on data exchanges.

One hang-up however is that the standards are voluntary and while they recommend four-digit year elements they do not specify a sequence for the day and month elements of an eight-digit date. Again time is of the essence.

"I think what is important is the fact that we all are ready and we all can recognize which century we're in when we try to do date calculations " SSA's Draper said. "But whether we put the date before the month or the month before the date I think is immaterial as long as we know what we're getting and can react to it."

Most agencies should make an inventory of interfaces when they look at and analyze their source code and data said Ken Heitkamp technical director of the Air Force's Standard Systems Group Hanscom Air Force Base Mass.

"Certainly if systems aren't going to be brought into compliance at the same time then the interface is going to have to be of concern " he said.

The issue is one Congress may take up. But although Morella's subcommittee currently has plans to hold hearings many caution that Congress should not consider legislation mandating an interface standard.

"Congress is extremely good at raising awareness " one policy-maker said. "But they shouldn't try to write law because this is not a problem you fix with law it's a problem you fix with technicians." Said another "If the threat of your computers crashing and your business failing isn't motivation enough I don't think a congressional mandate would do the job."McCloskey is a contributing writer to FCW.

NEXT STORY: GATEC: A view from the front line