The Year 2000 Problem

t is being described as a ticking time bomb destined to wreak havoc on millions of computer systems around the world. On Jan. 1, 2000, six-digit date fields in computer programs will read 01-01-00--causing machines to interpret the date as Jan. 1, 1900, instead of Jan. 1, 2000. This misinterpretation will cause computers to crash or, at the very least, to make costly and potentially dangerous miscalculations.

Nowhere will the so-called "year 2000" problem be more prevalent than in the federal government, where thousands of mainframes are operating on Cobol computer code written in the 1960s. The inability of that code to recognize the new millennium will affect all time-sensitive computer programs. If not addressed immediately, the year 2000 problem could have disastrous consequences.

Payroll and benefits checks will not be cut, interest payments will not be calculated, permits will not be issued. Purchase orders will expire long before their issue dates. Inventory programs will think stock is outdated. Hospital records will mistake newborns for the elderly. And weapons systems will malfunction.

"You cannot underestimate the seriousness of the problem," says Kathleen Adams, associate commissioner for systems design and development at the Social Security Administration and chairwoman of the government's Year 2000 Interagency Committee. "The government is so large and has so many billions of lines of code. Locating and correcting all the date references within such a short time frame will be expensive, and yet it must be done."

Agencies are expected to fork out as much as $30 billion over the next four years to solve the year 2000 problem, according to the Gartner Group, an information technology marketing research firm in Stamford, Conn. Much of that money will be spent on software tools for organizations doing date conversions in-house, and outsourcing services for those choosing to contract out the labor-intensive work.

Gartner estimates conversion costs at $1 for every line of computer code, providing revisions begin immediately. That average excludes date conversions on weapons-systems code--these are expected to be significantly more expensive. Costs are expected to escalate as much as 50 percent for every year projects are delayed.

"Many agencies who have not yet started working on the year 2000 problem will discover that the longer they wait, the more expensive it will be," says Adams, who began year 2000 preparations for the Social Security Administration in 1989. "Some organizations already are seeing problems crop up in five-year forecasting programs and other applications."

Approximately 20 percent of all business software will falter this year because of problems involved in computing the year 2000, according to the Gartner Group. An estimated 90 percent of all computer applications will fail by 1999 if date fields in software code are not amended.

"There's a sense of urgency because there is a definite deadline and it cannot be extended," says Sally Katzen, administrator of information and regulatory affairs at the Office of Management and Budget, which is working to boost awareness of the year 2000 problem. "Time is running out."

Best Intentions Blighted

Mainframe programmers in the 1960s and 1970s never anticipated the doomsday scenario now presented by the year 2000 problem. Back in those early days of computing, developers were surprised to see their Cobol programs survive three years--much less three decades. They expected code to be replaced as hardware became more sophisticated. Instead, many agencies chose to patch and update the code, thereby burying the date references. As time passed, the six-digit date fields became standard.

Although programmers were shortsighted, their intentions were good. Computer memory was expensive in those days, so developers sought ways to use as little disk space as possible. By not storing the century as part of the year, programmers could delete two bytes per date. Considering dates may be replicated thousands of times throughout a single program, this translated into millions of dollars saved.

"It may sound crazy now, but we were living in a era when computers did not have keyboards and programmers thought 12K of memory would last a lifetime," says Rick Rineer, special assistant for technology fusion at the Education Department and a former Cobol programmer who is spearheading his agency's preparations for 2000. "Now everyone is realizing that both the principal and interest on the money saved is coming due."

After lying dormant for 30 years, the year 2000 problem is troubling those in data-intensive businesses such as the insurance industry, the financial community and all levels of government. Professional seminars on the topic are playing to standing-room-only audiences, and business school classes designed to help organizations manage computer programming transitions are frequently overbooked. Dozens of home pages on the Internet's World Wide Web offer advice and products for what are becoming known as "Y2K" projects.

The year 2000 problem even has gained the attention of Congress, which is scheduling hearings on the subject. Sen. Daniel Patrick Moynihan, D-N.Y., has asked the Congressional Research Service to study the issue and report on its implications for the federal government.

"As ranking minority member on the Senate Finance Committee, I am concerned about how the problem will affect agencies such as the Treasury and Social Security Administration, as well as other government and private computer systems," says Moynihan. "This problem may cause widespread errors in computation of government benefits and taxes."

The Office of Management and Budget also is concerned, and has brought up the issue with the President's Management Council. Agencies are being urged to include the cost of Y2K conversions in their fiscal 1998 budget estimates and five-year information technology forecasts. OMB, which recently took over computer-procurement oversight from the General Services Administration, may issue guidelines for estimating year 2000 conversion costs.

"We want to help agencies determine the magnitude of the problem," says Katzen. "By raising consciousness, we hope to give people a better understanding of the solutions available."

OMB may consider implementing governmentwide contracts for year 2000 consulting services and software conversion tools so that agencies do not have to handle their own procurements. The Office of Federal Procurement Policy, meanwhile, is trying to get language put in contracts certifying that new information technology products will feature eight-digit date fields (MM-DD-YYYY). Some organizations, such as the Defense Department, already mandate Y2K-compliance for new purchases.

Convincing the Boss

The Social Security Administration is the government's year 2000 trailblazer. The agency began preparing for the problem seven years ago and expects all 30 million lines of its code to be Y2K-compliant by 1998. About 20 other agencies have appointed year 2000 coordinators who are responsible for drawing up date conversion battle plans.

Many other organizations, however, have not started Y2K projects. Perhaps the biggest challenge for agencies preparing for the new millenium is getting top managers to understand the severity of the year 2000 problem. As with most issues, funding is the major stumbling block.

"Managers are already skeptical about the money being spent on information technology and now they're being told that they have to spend millions on projects that will bring them no added functionality," says Ian Temple, manager of the Gartner Group's Information Technology Executive Program for Government. "It's hard to convince administrators to commit to year 2000 projects because they're not getting any return on their investments."

OMB, in conjunction with the Year 2000 Interagency Committee, is educating senior managers about the Y2K problem so they can earmark funds as soon as possible. Many managers, however, refuse to acknowledge the complexity of the problem and the amount of time, money and personnel involved in converting the date fields.

"The first reaction by senior management is denial, followed by an assumption that the technical people will find a silver bullet," says Robert Molter, computer scientist for the Information Technology Directorate in the Office of the Assistant Secretary of Defense for Command, Control, Communications and Intel- ligence. "Trust me, if there was a simple fix, it would have been used a long time ago."

Dates, Dates Everywhere

The main reason there are no simple fixes for the year 2000 problem is because six-digit date fields are present at every level of computing, including operating systems, software applications and databases. Dates even can be found in computer hardware, from mainframes and midrange machines all the way down to networks, PCs and pocket-sized electronic schedulers.

Date fields are used in basic computer functions such as calculating, sorting, comparing, projecting, validating and simulating. Agencies use them in everything from weather forecasting and weapons targeting to inventory management and payment scheduling. Even the smallest federal agency could have thousands of programs requiring year 2000 conversion.

"The problem is complex, both from a management perspective and a technical perspective," says Rear Adm. James Davidson, commander of the Naval Information Systems Management Center. "The sheer size of this problem adds to the complexity because dates are everywhere. That means all program code must be examined to determine if a change is necessary."

Finding the dates can be difficult because they often are embedded in complex encoding schemes. Patches and updates that have been made to software since the 1960s have created what programmers call "spaghetti code" that runs around endless strings of references. These software mazes sometimes can be impossible to decipher.

"Proper data administration has never been done because no one thought it was necessary to keep a record of date stamps that appeared all over the place," says Bruce Rosen, manager of software standards at the National Institute of Standards and Technology. "It represented too much overhead, but now most of the original programmers are gone and along with them went the knowledge of how to safely change some of the source code."

Farming out the Work

Conversion of six-digit dates to eight-digit fields in software code is complicated, time-consuming and repetitive work that involves looking at every single line of code. Many short-staffed federal technology shops may not want to dedicate their best and brightest computer programmers to such mundane work. Other agencies may not have qualified people in the first place.

"There's a real skill shortage when it comes to fixing the year 2000 problem," says Olga Grkavac, vice president of the systems integration division of the Information Technology Association of America (ITAA), a trade group representing 6,700 direct and affiliate member companies. "A lot of places are suffering from a lack of talent because there just aren't enough Cobol programmers around. Many of them got out of the business years ago."

Some agencies are using outsourcers to help them do date conversions. A recent ITAA survey of federal information technology professionals indicated that 79 percent plan to contract out one or more phases of their labor-intensive Y2K projects.

"We simply don't have the internal resources to do this," says Education's Rineer, who learned firsthand about the Y2K problem when newly issued student loans recently showed up as being in default because the agency's computers thought the notes were due in 1901 instead of 2001. Any manager who has the luxury to "stop what an agency's technology people are doing and devote them to the year 2000 problem should have been fired a long time ago," says Rineer.

Not surprisingly, vendors have risen to the occasion. Many large firms, such as Anderson Consulting, Coopers & Lybrand, Electronic Data Systems, Ernst & Young and IBM, have opened year 2000 divisions and are offering products and outsourcing services. Cap Gemini Sogeti, for instance, has a TransMillennium service in which duplicate tapes of software code can be sent to the company's Renovation Center in Tarrytown, N.Y., where they are analyzed and returned to clients.

Funding Crisis

In order to keep costs lower, some outsourcers are farming out Y2K work to programmers in places like India or the Philippines, where labor costs are substantially lower.

Although offshore programmers can bring software-conversion expenses down to below the $1-per-line-of-code benchmark, costs still can multiply quickly--particularly at agencies with lots of customized hardware and software.

Mitre Corp. estimates that year 2000 conversions for weapons systems, for instance, could be as much as eight times more expensive than Y2K projects at civilian agencies because new microchip production would be required. The Defense Department declines to comment on how much year 2000 conversions will cost but analysts--taking into consideration all the DoD-unique hardware and software--put the figure in the low billions.

"All I can say is that it will cost more than our operational and maintenance information technology budgets combined," says DoD's Molter. "And the worst part is that it's unplanned. No one has projected these costs and we don't expect Congress to give us any new money."

In an effort to fund year 2000 projects, state governments are increasing sales taxes. Nebraska, for instance, recently raised its cigarette tax by 2 percent in order to help pay for software code conversions. The only option for federal agencies, however, is to put new systems-development projects on hold.

"We're all being put in a position where we have to invoke Solomon's law and choose among our children," says Rineer, who estimates his agency will spend about $1 billion on year 2000 software conversions. "We will try to mitigate the damage by focusing on mission-critical areas such as personnel, payroll and procurement."

Choosing a Methodology

Funding is not the only headache involved in the year 2000 problem. Agencies have to settle on methodologies for doing software code conversions and, like so many information technology projects, no single set of rules applies. Strategies depend on how much code an agency plans to be running after the year 2000, and whether customized code can be replaced by new off-the-shelf software.

Hardware may have to be replaced as well. Some legacy systems--mainframes containing original Cobol code--are not expected to survive the transition into the new millennium. IBM has announced that its S/370 line of mainframes cannot be modified for the year 2000. And some Unisys machines can't, either. In addition, the basic input-output systems (BIOS) on older PCs will not be able to accommodate the century change. As a result, some machines will require a date-command execution every time they are booted up.

"On a recent year 2000 test, 97 percent of our computers failed," says Education's Rineer. "We will have to replace the BIOS on all these machines and will end up buying a lot of servers."

Experts recommend starting year 2000 projects by doing a thorough inventory of hardware and software. Source code must be analyzed for all date references. Once the complexity of the required changes is determined, the cost of the conversion project can be estimated.

"Intimate knowledge of your information systems is essential to solving the year 2000 problem," says DoD's Molter. "Without an accurate assessment of what's involved, agencies could face major surprises down the road. Unfortunately, there can be no false starts on this project because the clock is ticking."

A wide variety of software tools and services are available for locating and changing date fields, but even the best products can automate less than half the process. The rest of the work must be done manually either by agencies or outsourcers, or a combination of both.

Experts recommend developing a plan based on the importance of applications and their impact on customers. Then a proper mix of resources can be chosen to conduct the analysis, conversion and testing phases. Agencies not wanting to wait for new governmentwide contracts to be implemented may want to buy year 2000 products off existing task-order contracts, such as the General Services Administration's wide-ranging Federal Systems Integration and Management contracts.

Federal year 2000 projects will succeed to the extent that date fields are identified precisely and conversion methods are accurate.

Quality control will play a major role in Y2K projects because overlooked date references could shut down computer systems or infiltrate "clean" data. Fire walls should be put into place to keep out infected data. "Bad date references from business partners can be every bit as dangerous as computer viruses," says Adams of the Social Security Administration.

Success also will depend on the commitment shown by senior managers and whether service providers deliver year 2000 solutions on time and within budget. Above all, agencies should begin Y2K projects as soon as possible in order to have time to sort out last-minute complications.

"The important thing is to get going because the sooner agencies start tackling the year 2000 problem, the sooner they'll finish," says Adams. "After all, it's less than four years away."