Lots of stuff today, folks. See page B1 (3 articles). Also see pages A3 and A10.

Can someone help and post the articles? Thank you.

-- eve (123@4567.com), December 23, 1999

Answers

for entertainment purposes only....link not provided, pay service

Z

Browse Entire Paper Return to Front Pages

Y2K Countdown: Will the Bug Bite? --- How the Fixers Fended Off Big Disasters By Lee Gomes 12/23/1999 The Wall Street Journal Page B1 (Copyright (c) 1999, Dow Jones & Company, Inc.)

If this New Year comes and goes without any computer catastrophes in the U.S. -- as a growing number of people now think it will -- does that mean that all the alarm about the Y2K bug was Chicken Little hysteria?

Hardly. Suppose, for example, that the New York Stock Exchange had ignored the Y2K bug. NYSE technicians wouldn't have spent $30 million over the past four years rewriting software, rewiring hardware and testing all those changes over and over again.

The result: No trading at all on Jan. 3, 2000, NYSE technicians say, and maybe not for days or even weeks after. A pileup of date errors in the programs that control the exchange's basic operations would have brought business to a halt.

"Had we not done anything about Y2K ," says Bill Bautz, vice president for technology at the NYSE, "about the only thing that would have worked on the trading floor that first day would have been my lynching."

It's a similar story at other big U.S. companies and institutions that depend on mainframe computers. Programs on these computers rely on hundreds or even thousands of internal date references to conduct their business. Without a Y2K push, the programs in some cases would have registered the rollover to the new year as Jan. 1, 1900, and begun wildly incorrect operations. In many cases these programs would have, in effect, thrown up their hands in despair and shut down.

At Allstate Insurance Co., year-2000 coordinators say that had they ignored the date bug, computers might have refunded a century's worth of premiums to a customer canceling a three-year insurance policy. Clorox Co. and Sanwa Bank of California say their business operations would have shut down. And Southern California Edison says a cutoff of monitoring data to its technicians might have left some of its customers in the dark.

The NYSE offers a case study in how quickly, and how badly, things would have gone awry. As far as its computers go, the NYSE opens for business at about 2 a.m. on each trading day, when about 75 technicians start showing up for work at two data centers in lower Manhattan and Brooklyn. Their first big task is to fire up the exchange's Tandem mainframe computers, and then run a program called SuperDot, which oversees communications between the stock exchange and its brokerage-house members.

Testing revealed that SuperDot was riddled with Y2K glitches, says Mr. Bautz. Had technicians not made the necessary repairs, a legion of date-dependent operations would have gone awry and the system would have crashed promptly at 2 a.m. on Jan. 3. That would have left brokerage houses without any way of sending in orders to the exchange by computer.

The next crash would have happened at 8 a.m. That's when technicians launch another mainframe program called OARS, for Order Automated Reporting System. OARS queues up orders so they can be executed; technicians found that it, too, was full of similarly fatal date errors. Without OARS, stock orders couldn't be passed through the system to the trading floor.

Shortly before 9:30 a.m., when the bell ordinarily marks the start of a trading day, the computer networks that link the exchange floor with the two data centers pop on. Without any Y2K efforts, it's likely those networks would also have gone down, says Mr. Bautz. As a result, the various trading posts on the exchange floor would have displayed, not stock prices, but random blinking lights.

Different variations on that sort of chaos would be happening at companies everywhere. In fact, for some mainframe users, glitches would have started cropping up long before the New Year.

Allstate, for example, says data on some of its car-insurance policies written in 1995 would have gone bonkers had the car's owner had a five-year bank loan. With the bank loan running out in "00," the computer would have interpreted the date as 1900, and assumed it no longer needed to keep the bank apprised of changes in the policy, as it is required to by law, says Rich Harris, who oversaw Allstate's $125 million of Y2K work.

But that would just have been a warm-up for much messier Y2K problems at Allstate. Starting in 1997, for example, the computer file for someone with a three-year policy would have shown that policy expiring in "00." If that customer then canceled the policy and asked for a refund of the unused premium -- a common occurrence -- the computer would have sent a refund check equaling a century's worth of payments, says Mr. Harris.

By early this year, date-related miscalculations would have been rife throughout all of Allstate's programs -- sometimes unnoticed. "If the programs would simply choke and shut down, that would have been the best thing," says Mr. Harris. "But most of our programs would have kept running, creating errors all over the data files. By the time they stopped, it would have been nearly impossible to sort things out."

Likewise at Sanwa Bank of California in Los Angeles. Wayne Socha, senior project manager for Y2K at the bank, says his employer, like most other banks, found pervasive Y2K glitches. Many bugs were in code that tracks deposits. Had Sanwa not sought and fixed the bugs -- it spent $25 million on Y2K -- bread-and-butter banking functions like tracking account balances or figuring out interest amounts would be going haywire after New Year's Day. As systems managing the banks basic operations crashed, Sanwa tellers trying to access terminals would find them not responding; ATM machines probably wouldn't work; and online banking, not to mention end-of-month statements, would have been out of the question.

Mr. Socha says the bank might have been able to operate for a few days into the year 2000 in an emergency contingency mode. But after a couple of days, even that would have become impossible, he says. The bank would have had to shut down for weeks or months, he says, to fix its machines.

Some Y2K fears proved unfounded. In the end, most Y2K problems involved mainframe computers, where the date-change problem was first recognized during the early 1990s. While there had been widespread warnings about the "embedded" chips in other electronic devices -- everything from elevators to microwave ovens -- these problems proved much less vexing than many people had initially feared they would be. Many chips, for example, do not have date functions in their hard-wired programming. For others that do, the date rollover may cause an inconsequential error, not a disabling one.

Indeed, many of the most lurid fears about Y2K would probably never have come to pass, even if people had done nothing. Airplanes, for example, probably wouldn't have tumbled out of the sky, because there are no systems on planes where a date-dependent failure would be catastrophic.

That isn't to say there wouldn't have been any aviation problems. Boeing Co., for example, says it found a date glitch in the way preflight data were entered into the navigation systems of some of its aircraft. If the bug hadn't been fixed, the plane wouldn't have been able to take off.

With no Y2K fix, the power grid would likely have stayed up at New Year's midnight -- at least for a while. Eric Trapp, year-2000 program manager at Southern California Edison, a unit of Edison International Inc., says his teams didn't find any potential date problems in the various relay lines, substations, transformers and the like that carry power to the company's 11 million customers spread out over 50,000 square miles in central and southern California.

"Those systems are largely electromechanical and dumb," says Mr. Trapp. "There is not a lot of digital functioning in them."

But that isn't true in other parts of the utility's network, especially in the hundreds of sensors located throughout the system that each send back hundreds of bits of information every few seconds. Those all rely on computers, and they might well have failed at 4 p.m. Dec. 31 California time -- midnight in the Greenwich Mean Time used as a standard by the utility industry.

There are enough manual overrides in the control room that a systemwide shutdown would have been unlikely, Mr. Trapp says. But with control-room technicians not getting accurate reports about power usage in a particular area, they wouldn't have been able to allocate electricity properly to keep pace with demand. That might have led to localized brownouts.

Another potential danger: With its sensors down, the utility wouldn't have known which of its power lines were "hot" -- something that could have endangered the lives of its repair crews.

There was a comparable situation at Clorox, says Jenniffer Hamilton, Y2K -program director at the Oakland, Calif., household-products company. She doubts that any midnight catastrophe would have erupted at any of the company's 26 manufacturing plants if Clorox hadn't undertaken its $42 million repair program. Most of the actual production machines, she says, are relatively simple devices without date-sensitive parts in them.

But Y2K problems were lurking in the mainframe programs that Clorox uses to coordinate its manufacturing, order its inventories and schedule its shipments. Many of those processes would have come to a halt, Ms. Hamilton says.

While Clorox is expecting the year-2000 rollover to proceed smoothly, like most other U.S. companies it isn't taking any chances. For its plants that use especially harsh chemicals, like those involved in making bleach, the company plans to shut them down over New Year's -- just in case.

---

Y Stop at Y2K ? Other Bugs Are in the Numbers

Y2K may just be a taste of things to come. Modern civilization can't get by without numbers. But over and over, people neglect to use them with much foresight. How else to explain the Y2K computer problem? Only a generation back, computer programmers decided to preserve memory space by setting aside only two digits to represent a four-digit year. History will repeat itself after New Year's Eve passes, with a parade of new computer-related number troubles to worry about, from phone numbers to Social Security numbers to leap years. None of these problems are likely to reach the heights attained by the Year 2000 Bug. ` Y2K was one of the biggest business problems we have seen in all of human history,' says Capers Jones, a Y2K consultant. `The rest of these are small potatoes.' So consider this a small-potatoes guide, a primer on the other number bugs, with anxiety ratings from one to three. Y2K skeptics may note that other supposed date crises were uneventful this year. One instance: the quiet passing of Sept. 9, 1999, a date whose shorthand version, 9999, was used as a stop command in older computer systems. Others may note that most of today's computer systems won't still be operational, say, 38 years from now. But just remember, that's the very logic used by programmers circa 1970.

Bug: The Feb. 29, 2000, Bug Rating: Two alarms Problem: Computers don't like leap years. Every four years, like clockwork, most companies with big mainframes gear up for the inevitable data-processing hiccups. Computers are programmed to know that years divisible by 100 are normally not leap years. But many computers don't know the exception: years divisible by 400 are leap years. Prognosis: So nasty is the problem that some businesses have postponed computer installations until March or later. The general Y2K debugging frenzy is expected to keep technical people on guard, at least until February passes.

Bug: The Running-Out-of-Phone-Numbers Bug Rating: One alarm Problem: The 10 digits in U.S. phone numbers theoretically make for 10 billion possible combinations. In practice, it's a lot fewer. Only 646 area codes are usable -- rather than 999 -- because they can't begin with 0 or 1, and numbers like 800 are set aside for other reasons. About 300 area codes are in use now, and the rest could be run through as early as 2007, by one estimate. That eventuality, though, may be pushed back a few years by better allocating numbers inside area codes, some think. Prognosis: Something called the Industry Numbering Committee, a trade group, is hard at work crunching digits to determine when, and by how much, phone numbers will need to be lengthened. Computer programs are littered with phone numbers, but any changes to them should be less disruptive for programmers than the problems Y2K wrought.

Bug: The 2019 Window Bug Rating: Three alarms Problem: Instead of changing every two-digit date reference in a computer program to four digits, many programmers used a quick-and-dirty shortcut called `windowing.' They simply agreed that `00' would represent 1920, 01 would represent 1921, and so on. The approach buys time until the year 2019 rolls over. Then, unfortunately, many computers will read the following year as 1920. Prognosis: This one raises a lot of worries. There was no consensus on what the new window ought to be: Some programs have it extending to 2015, others to 2019. That means that different programs, even at the same company, will have different windows expiring at different times. Think turmoil.

Bug: The Year 2038 Unix Bug Rating: Three alarms Problem: This is a virtual replay of Y2K -- involving the Unix operating system widely used in business and academia. Most Unix systems store dates based on the number of seconds that have elapsed since Jan. 1, 1970, the birthday of what is immodestly known in Unix circles as the `Unix Epoch.' But Unix sets aside only four `bytes' of storage space for this, enough for 2.14 billion seconds. On Jan. 19, 2038 (at about 3:15 a.m., Greenwich Mean Time), the Unix odometer is supposed to roll over. Or not. No one quite knows what will happen next. Prognosis: This bug should be easier to fix than Y2K , because Unix systems tend to get date information in one consistent way. Still, this has the makings of a big, messy data-processing problem. Does 2038 seem too far away to worry about? Many Y2K problems were first detected in 1970, when banks tried to record 30-year mortgages.

Bug: The Running-Out-of-Social-Security-Numbers Bug Rating: One alarm Problem: The nine-digit Social Security number can handle one billion numbers. But, just as with phone numbers, there won't be that many, since the first three digits are set aside for specific states. More than 400 million numbers have been assigned. When will we run out? `We haven't even started to look at that question,' says a spokeswoman for the Social Security Administration. Some people estimate it will happen around 2050. Prognosis: Social Security numbers appear frequently in databases, but are less problematic. The figures aren't added or subtracted like dates. One way to buy more time: reuse Social Security numbers of long-dead people. That could, however, create new data-processing problems of its own. And it's creepy.

Copyright ) 1999 Dow Jones & Company, Inc. All Rights Reserved.

-- theletterz (theletterz@yahoo.com), December 23, 1999.

This is a very interesting report. It acknowledges, with numerous specific examples, the mayhem potential of Y2K--lost data, production shut down, business failures, stock exchange lockup, etc.--all from the perspective of "it's all been fixed." What if the reporter's assumption is wrong? What if it has not all been fixed? Is it likely that a global project of this magnitude has been completed successfully? I don't think so.

What this article tells us is that Y2K is (or was, if you accept the reporter's point of view) a deadly serious problem. What each of us has to decide for himself is whether we think the problem has been solved on a scale sufficient to avoid major problems.

I noticed no mention of oil nor the status of the rest of the world in the article. Did I overlook this or did the reporter overlook it? Are most people overlooking it?

-- cody (cody@y2ksurvive.com), December 23, 1999.

theletterz,

Thank you so much for your prompt assistance.

-- eve (123@4567.com), December 23, 1999.

This is what DWay was talking about -- companies coming forward and confessing what their remediation actually fixed. This seemingly innocuous article has a much gloomier implication than JQP can possibly imagine. FOF in small business and foreign countries? I don't think so.

-- Dave (aaa@aaa.com), December 23, 1999.