DEFUSING THE Y2K BOMB The Millenium Bug. Year 2000. Y2K. Names are supposed to clarify meaning, but in this case more has not been better. So many terms have been flung around in regards to Y2K that sometimes it's hard to know exactly what what the problem is. Explained as broadly as possible, Y2K means this: After December 31, 1999, two-digit date storage and computer logic will fail to operate as intended. Some particularly rude tangents include: * incorrect day-of-week calculations, because systems will reference the wrong century calendar (1900-1999, instead of 2000-2099). * the year 2000 not registering as a leap year, throwing off March-December dates by a whole day. * the loss of data tagged with an expiration date of "9999," or September 9, 1999 in "People-ese." (This easy-to-type code was used to fill the expiration field for data not meant to expire.) * improper indexing by functions that sort by date. Yeah. So what? For the average human who considers computer science the alchemy of our day, these things mean very little. Well, as the saying goes, there's some good news and some bad news. The bad news is that many of the personal horror stories floating around are plausible. Uncut payroll checks. Shrinking or skyrocketing investment/loan interest. Stagnant or destroyed inventory. Malfunctioning weapons and medical systems. Misprocessed records. Unpaid Social Security benefits. Misguided aircraft. Unexpected power incidents. Inaccurate mortgage computations. Better yet, the assumed deadline could be a cruel hoax: We might not have until January 1, 2000, to make necessary changes. The Social Security Administration ran into problems in 1989, due to 10-year projections that crossed into year 2000. Since most billing software looks ahead at least one year to determine interest payments, future assets, and possible expenses, the crisis might be upon us sooner than we might think. The good news is that, with our current awareness of the problem, Y2K won't spell the End of Western Civilization As We Know It. In all reality, there will be a number of snafus, but not nearly enough to signal the technological Armageddon predicted by some of the more outspoken systems prophets. The biggest surprise is how dependent the United States has become on computer technology. The Million-Dollar Question: Why? Considering its potential threat, Y2K was surely the master plot of some computer-obsessed hackers or a global madman such as the fictional Dr. Strangelove. At least, that's what we'd want to think, because (believe it or not) Y2K originated not from malice but from overly auspicious problem-solving. In the Dark Ages of Computing, when programs read data from punchcards and single machines inhabited entire basements, storage concerns were paramount. Since each standard card could hold only around 80 characters -- barely enough for one person's name, birthday, contact information, and Social Security number -- the number of cards required by an agency such as the SSA was staggering. (For comparison, we can now store 20 million punchcards of information on a $200 hard drive no bigger than a Walkman cassette player.) To keep budgets in the black, agencies had no alternative but to compact data as much as possible. These first computers were also extremely slow by today's standards: The now-plodding 8086 processor was a virtual powerhouse compared to the computers we used to send men to the moon in 1969. Every processed digit put significant strain on the old systems. In order to save space, money, and time, programmers made the very sane choice to avoid processing all non-essential data. The two-digit century indicators in dates were deemed non-essential. After all, people knew what time period they lived in, and computers had no reason to look past the 20th century. Cutting the year field in half was an ideal temporary shortcut. The key word was "temporary." Everyone admitted that, in a few decades, the missing two digits would become quite important. However, computers would then be cheaper and faster. Old systems using the two-digit years would have been retired. Four-digit years could be easily reinstated. Or so went the thinking. Unfortunately, conventional business practices and human nature prevented Y2K from being fixed until it was almost too late. The costs of storage space and computing power did eventually drop, but agencies never found it convenient to implement the four-digit year standard. Programs were a pain to revise, two digits were two keystrokes too many, and the year 2000 was still far in the future. As long as systems worked, no real problem existed. Meanwhile, because new applications had to run on the old systems, they were written to accommodate the "temporary" two-digit year processing. Along with lack of concern came lack of funding. Because preventive maintenance maintains the status quo without bringing positive benefits, it usually receives little attention on the annual budget. Funds that could have solved Y2K problems were instead channelled into agency growth, to directly impact critical missions. Another assumption was that Y2K wouldn't be a big deal to fix once the time came. (After all, it was only two digits, right?) Unfortunately, procrastination spawned problems at an almost geometric rate. While Y2K hibernated, system programmers continued to tinker with agency computers. In order to fix glitches or add software to the base-level code running their mainframes, they often slapped "patches" (code snippets) into the gaps instead of rewriting software. Because patches are small separate files that can call other programs stored all over the mainframe, it's difficult to track down and correct each one during a global system change such as Y2K. Another programming problem was that many date fields weren't conveniently called "date" but had unrecognizeable names. To complicate matters, programmers were notorious for not documenting changes (which took time away from active programming), so when a programmer left the agency, all knowledge of the small changes he made went with him. Locating and isolating problem areas has been one of the worst Y2K headaches. Probably the worst contribution to the Y2K situation, however, has been indifference. More than one commercial CIO has been overheard to say that Y2K wasn't his problem, since he'd be retired by the time it became a concern. Similar to the policy of borrowing tomorrow's money to fund today's work, the "My-Replacement-Will-Deal-With-This" attitude dumps a truckload of hot potatoes on the last guy in line. Problems are passed down until they are too large to be ignored -- and often too large to be fixed. So what began as a noble attempt to make do with limited computer resources eventually became a Sword of Damocles swinging over the government's forehead. The old nursery rhyme, "For want of a nail... the kingdom was lost," never seemed believable until now: For want of two digits of storage space, computer systems worldwide could finally suffer a complete breakdown. How much will it cost us? For a long time, agencies had trouble deciding whether or not Y2K was actually a problem. (Most of them finally decided that it was.) With that out of the way, the IT world's new debutant became what the pricetag should read. (Most of them still aren't sure.) Gartner Group estimates that a medium-size organization will spend almost $4 million to make Y2K changes, with single lines of code costing 80-100 cents apiece to fix. Y2K vendor Viasoft estimates the cost of correcting one program to run around $600-1200 -- which is small change compared to the US deficit, but a real drain on the pocketbook when you realize that most agencies have thousands of programs. OMB estimates a contested $2.5 billion to fix federal computer systems that were not already going to be fixed or replaced for other reasons. The Navy started a brouhaha when they claimed Y2K would only cost them $90 million, in comparison to the Air Force's $371 million. And so the debates went, leaving time to prove the victor. Most people agree that fixing the United States' Y2K problems will run $50-75 billion, and that to fix those of the entire world will cost $300-600 billion. Now that sounds like a lot of money, especially in light of OMB's announcement that Y2K work funds must come from existing agency budgets. But to throw a nice spin on things, Leon Kappelman (University of North Texas) and James Cappel (Western Michigan University) claimed last year in the Journal of Systems Management that the two-digit year format saved a typical organization over $1 million per gigabyte of total storage from 1963-1992. Invested properly, these savings would have returned $15 million per gigabyte over the same time period. Considering how many gigabytes the average organization uses (tens or hundreds), today's headache of fixing Y2K should have still left them rolling in dough. Apparently we just forgot to save up for a rainy day -- such as the one most likely to occur on January 1, 2000. ---------------------------------------------------------- (c) 1997 by Fed Services, Inc. Electronic Government, Vol. 2, No. 2, pp.??? Material to be used solely in regards to examining my credentials for employment.