Lets FOCUS people!!!! What

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

Lets keep focused people. The time to debate the reality of Y2k is OVER. Don't get distracted by name calling and personal attacks on you or anyone else. What I want to know is this. What piece(s) of information? What fact? What quote, essay or stat made you go "Whoa, time to buy more beans!" If you can, please re-post it or the thread here.

I will post as many of the most relevant ones in my collection as I can find.

Meanwhile, Lets take another look at Big Dog's latest post. "The Simplicity of Y2k from IT perspective" One of the best explanations of the challenge we are facing in Y2k that I have seen in a long time. I suspect that this is the post (coupled with Bennet's latest statement) that has inspired all the sudden attention this forum has gleaned from the dedicated disruptors in the last two days.

Because not a single person has been able to really dispute Big Dog's concerns I think attacks and cheap shots are being levied elsewhere. This seems to be a desperate attempt to destroy the credibility of the forum ITSELF - and hence any posting that originates from it. it is a foolish tactic and will only succeed in wasting our precious energy and time. Lets focus people. Tell me what piece of info you think is MOST important to "Get" if you are going to understand the complexity and havoc of Y2k.

The Simplicity of Y2K from IT Perspective greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread --------------------------------------------------------------------------------

Ironically, the one reason I can find to be optimistic about Y2K is the widespread deceit and/or hidden-ness about the overall reporting of it. This gives me a faint hope that we are much further along in remediation than I expect and is why I personally still give a BITR a 5% possibility (see a's thread). Against this lies the simplicity of understanding Y2K from an IT historical point-of-view (remember, I'm speaking broadly about global efforts, not about the efforts of various, specific entities):

1. Y2K budgets have steadily escalated (bad project sign).

2. Deadlines have shifted backward (bad project sign).

3. Testing is being deferred, reduced or scrapped for FOF (bad project sign).

4. Optimism when 75-90% code complete has been reached is taking hold (bad project sign).

These bad signs historically lead to late projects. They are the one SURE statistical metric within our industry! Alas.

Against these facts, it doesn't matter whether every media outlet in the world SINCERELY publishes "good news" reports of "progress" (progress is always being made in software). It doesn't matter how huge the disconnect is between public expectations of a "bump" and what will "really happen". The public can expect whatever it likes, it doesn't affect what will happen. Likewise, the markets. Likewise, CEOs (IT pros know how little they understand about their own systems).

All that matters is understanding how it could be (could it?) that these historical predictors won't come to pass this time.

The only argument I have ever read that is partly credible is the very one which ensures that Y2K impacts are going to amaze the world: the date is inflexible so everyone must and will finish.

While this represents a strong wish, software history also indicates that it is literally impossible to finish projects behind schedule by throwing more resources at them and, generally, it makes projects even later than they would have been.

As an intuitive rule of thumb, IT pros know this is why stated completion dates of Nov. and Dec, 1999 cause us dread. Except in the rare instances where the completion date is really September (and the geeks simply "told" mgmt it would be December), this really means that the GEEKS have said December .... and that means trouble.

The inflexible date on top of the predictive markers that are in place as of July 15, 1999 is extremely ominous.

Adding

5. The unpredictable impact of embedded systems

... into the stew is that much more ominous. Chillingly so, since there are bound to be strange impacts, even if the percentage of bad systems is as low as hoped.

Now, if it is all so simple, why has the IT press not picked up on this and made a huge stink?

a) Outsiders cannot imagine how boring maintenance programming is, in general, and Y2K is, in specific, to the tech press. Yesterday's systems, yesterday's languages, yesterday's news.

b) Related to a), just as very few computing entities have ever applied the lessons of the historical programming markers I cited above, likewise, IT journalists haven't either. Saying "why" would take a book and many books have been written. Outsiders simply have to take on trust that something about this profession profoundly resists the simplest possible measurements of "real" productivity and project progress.

c) The IT tech press, even more than the mainstream, ordinary press, is a creature of products and services ("advertisers"). Investigative reporting is mainly non-existent. Not minimal. Nonexistent. Everything is future-oriented (reviewing products and the "next cool thing"). Also, without putting too fine a point on it, and there are exceptions, most IT journalists are not themselves very technical.

To repeat and also conclude, this is the most important thing:

"Good news" at this stage is not trustworthy when coupled to the facts I state at top. These facts, admitting numerous specific exceptions, cannot be denied (if you think they can be, give it a shot). No doubt, some of the good news is authentic (SSA, having spent 10 years on this, can be taken as good news; some others as well). I only state that the news, broadly, is not trustworthy, since we are in the "optimistic phase" (itself a BAD, not a GOOD sign). I hardly need to point out that even the good news is usually accompanied by bad news anyway.

Y2K (as Cory never tires of pointing out) is not a poll-driven or "feel good" process. The projects are either being completed successfully or they are not. IT history and metrics says THEY ARE NOT. That is a deduction, but a very safe one. Unfortunately.

We can have good news right through December and still have Infomagic. Or a bump, yes, it is possible.

Contra the usual assumptions, I would be delighted to be shown the error of my ways. But it has to be by serious IT software professionals, not by the usual bozos.

Your serve, friends .....

-- BigDog (BigDog@duffer.com), July 15, 1999

Thanks Big Dog

-- R (riversoma@aol.com), July 20, 1999

Answers

"I hope these statistics aren't as bad as they appear," Bennett said.

-- R (riversoma@aol.com), July 20, 1999.

"Net result: a global mess. Localized but widespread disasters of varying severity."

-- Flint (flintc@mindspring.com), July 15, 1999.

-- R (riversoma@aol.com), July 20, 1999.


Institute of Electrical and Electronics Engineers letter to the Senate Committee on Liability issue

TAB YEAR 2000 TECHNICAL INFORMATION FOCUS GROUP Piscataway, NJ, June 9, 1999.

To: Members, Senate Commerce, Science And Transportation Committee; Members, Special Senate Committee On The Year 2000 Technology Problem;

Members, House of Representatives Committee on Science, Subcommittee on Technology;

Members, Committee on Government Reform, Subcommittee on Government Management Information, and Technology; Sponsors, House Bill `Year 2000 Readiness and Responsibility Act of 1999,' H.R. 775.Re: Year 2000 Liability Legislation.

From: The Institute of Electrical and Electronics Engineers ( IEEE ) Technical Activities Board Year 2000 Technical Information Focus Group.

Dear Honorable Senators, Congressmen and Congresswomen:

As leaders of the Y2K effort of the Institute of Electrical and Electronics Engineers ( IEEE ) , the oldest and largest international non-profit association of engineers and computer scientists in the world, we would like to offer some thoughts on the pending legislation involving Y2K liability obtained from our years of work and collective wisdom spent studying Y2K. The IEEE has drafted an Institute position on Y2K Legal Liability regarding United States federal law, to which our committee greatly contributed. We offer these additional thoughts in hopes that they may further assist your understanding as you attempt to reconcile two very valid but conflicting underlying public policy goals in structuring and passing the Year 2000 Liability Legislation currently under consideration. Minimize Damage to the Economy and Quality of Life: minimize the overall damage to the nation's economy and quality of life by reducing the need of organizations to redirect their limited resources away from the task of maintaining their operations in the face of Y2K in order to defend themselves from lawsuits arising from alleged Y2K failures.

Maximize Incentive for Y2K Failure Prevention: maximize the incentive of every organization to prevent Y2K failures as well as preserve the legal rights and remedies available for those seeking legitimate redress for wrongs they may suffer resulting from Y2K failures. In addressing public policy issues we have no more expertise than the literate public. However, we do possess expertise in the technical issues underlying the situation that should be considered as you weigh the conflicting public policy goals in formulating appropriate Year 2000 Liability Legislation. In particular, for your consideration we offer the following points pertaining to the technical realities of Y2K.

1. Prevention of all Y2K Failures Was Never Possible: For many large and important organizations, technical prevention of all Y2K failures has never been possible in any practical way for these reasons: 1.1 `Y2K Compliant' Does Not Equal `No Y2K Failures.' If an organization makes all of its systems `Y2K compliant', it does not mean that that same organization will not experience Y2K failures causing harm to itself and other organizations. In fact, efforts to become `Y2K compliant' in one place could be the direct cause of such failures in others. If interconnected systems are made compliant in different ways, they will be incompatible with each other. Many systems in government and industry are mistakenly being treated as if they were independent and fixed in the most expedient way for each of them. When this `Humpty Dumpty' is put back together again, it will not work as expected without complete testing, which is unlikely ( see Complexity Kills below ) .

1.2 All Problems Are Not Visible or Controllable. In the best case organizations can only address those things they can see and those things they have control over. Given this reality, many Y2K failures are inevitable because some technical problems will not be discernible prior to a failure, and others, while discernible, may not be within an organizations' jurisdictional control to correct. This is especially true in large complex organizations with large amounts of richly interconnected software involved in long and complex information chains and in systems containing a high degree of embedded devices or systems purchased in whole from external parties. ( The temporary lifting of certain copyright and reverse engineering restrictions for specific Y2K protection efforts should also be considered as long as copyright holders are not unduly harmed. )

1.3 Incoming Data May Be Bad or Missing. To maintain their operations many organizations require data imported from other organizations over which they have no control. Such data may have unknowingly been corrupted, made incompatible by misguided compliance efforts or simply missing due to the upstream organizations lawful business decisions.

1.4 Complexity Kills. The internal complexity of large systems, the further complexity due to the rich interconnections between systems, the diversity of the technical environments in type and vintage of most large organizations and the need to make even small changes in most systems will overwhelm the testing infrastructure that was never designed to test `everything at once.' Hence, much software will have to be put back into use without complete testing, a recipe, almost a commandment, for widespread failures.

2. Determining Legal Liability Will Be Very Difficult. Traditionally the makers of products that underlie customer operations are liable if those products are `defective' enough to unreasonably interfere with those operations resulting in damage. Y2K is different in that those customers themselves are also at risk for legal action if they fail to fulfill contractual obligations or fail to maintain their stock values and their failure to `fix' their Y2K problems can be shown as the cause. This customer base of technology producers cannot be overlooked in this issue. As it constitutes most of the organizations in the world, its needs and the implications of legislative actions on it considered now should not be overshadowed by undue focus on the much smaller technology producer sector. Nonetheless, even there liability is not as clear as tradition might indicate. Several factors make liability determination difficult, expensive, time consuming and not at all certain.

2.1 There Is a Shared Responsibility Between Buyers, Sellers and Users of Technology. Computer products themselves have only clocks that have dates in them. Application software products usually offer optional ways of handling dates. The customer/user organizations, especially larger, older ones, have created much of their application software in-house. When new products are introduced into the buying organization, the customer/user usually has vast amounts of data already in place that have date formats and meaning already established. These formats and meanings cannot be changed as a practical matter. The majority of, and the longest-lasting, potential system problems lay in application software and the data they process, not in clock functions. ( Clock-based failures, those likely to happen early in January 2000, while potentially troublesome, will be for the most part localized and of short duration. ) Various service providers can be optionally called in to help plan and apply technology for business purposes. But it is only when these are all merged together and put to actual use that failures can emerge. It is very rare that one of them alone can cause a failure that carries legal consequences.

2.2 Many Things Are Outside the Control of Any Defendant. Incoming data from external sources outside its control may be corrupted, incompatible or missing. Devices and systems embedded in critical purchased equipment may be beyond the defendant's knowledge or legal access. Non-technical goods and services the defendant depends upon may not be available due to Y2K problems within their source organizations or distribution channel.

2.3 There Will Be a Strong Defense of Impracticability. Existing large-scale systems were not made safe from Y2K long ago for good reasons. Many systems resist large-scale modernization ( e.g., IRS, FAA Air Traffic Control, Medicare ) for the same reasons. Wide- spread, coordinated modifications across entrenched, diverse, interconnected systems is technically difficult if not impossible at the current level of transformational technology. New products must be made to operate within the established environment, especially date data formats. Technology producers will claim, with reason, that the determining factor in any Y2K failures lay in the way the customer chose to integrate their products into its environment. It will be asserted, perhaps successfully, by user organizations that economic impracticability prevented the prevention of Y2K failures. Regardless of the judicial outcome, it will take a long time and many resources to finally resolve. And that resolution may have to come in thousands of separate cases.

3. Complexity and Time Negates Any Legal Liability Incentive. Even if making all of an organization's systems `Y2K compliant' would render an organization immune from Y2K failures ( it will not ) , the size and complexity of the undertaking is such that if any but the smallest organization is not already well into the work, there is not enough time for the incentive of legal liability to have any discernible positive effect on the outcome. As an analogy, providing any kind of incentive to land a man on Mars within one year would have no effect on anyone's efforts to achieve that unless they had been already working to that end for many years. A negative effect will result from management diverting resources from prevention into legal protection.

4. The Threat of Legal Action Is a Dangerous Distraction at a Critical Time. There will be system failures, especially in large, old, richly interconnected `systems of systems' as exist in the financial services and government sector. The question is how to keep such technical failures from becoming business or organization failures. We should be asking ourselves how we as a society can best keep the flow of goods and services going until the technical problems and failures can be overcome. The following points bear on these questions.

4.1 Y2K Is a Long Term, Not Short Term, Problem. Irrespective of the notion of Y2K being about time, a point in time, or the fixation on the rollover event at midnight December 31, 1999, or even the name `Year 2000' itself, Y2K computer problems will be causing computer system malfunctions and failures for years into the next decade. Y2K is much more about the dates that can span the century boundary represented in data that must be processed by software than it is about any calendar time or clock issues. Because of the vast amounts of these, the complex intertwining among them and our less than complete understanding of the whole, it will take years for the infrastructure to `calm down' after Y2K impacts themselves AND the impacts of the sometimes frantic and misguided changes we have made to it. The current prevention phase is only the beginning.

4.2 Rapid and Effective Organizational Adaptability Will Be a Prime Necessity. They key to an organization's ability to continue to provide the goods and services other organizations and individuals need to continue their operations will be determined by an organization's ability to adapt its practices and policies quickly and effectively in the face of potentially numerous, rapid and unexpected events.

4.3 Lawsuits, Actual or Threatened, Will Divert Requisite Resources. Preventing and minimizing harm to society from Y2K disruption is different than, and at times opposed to, protecting one's organization from legal liability. Addressing lawsuits, and even the threat of a lawsuit, will divert requisite resources, particularly management attention, from an organization's rapid and effective adaptation. This is already happening regarding technical prevention and will get worse the longer such legal threats remain. Organizational management has much more experience dealing with legal threats than they do addressing something as unique and unprecedented as Y2K. Their tendency is to address the familiar at the expense of the novel. They must be allowed to focus on the greater good.

4.4 Judicial System Overload Is Another Danger. Given the great interactive and interdependent complexity of Y2K's impact on the operations of our institutions on a national and global scale, the effort to determine exactly what happened, why it happened and who is legally responsible for each micro-event is itself a huge undertaking requiring the resolution of many questions. For the legal and judicial system to attempt to resolve the legal rights and remedies of affected parties while Y2K impacts are still unfolding will, in any case, threaten to overwhelm the legal and judicial system's capacity to assure justice in the matter, let alone its ability to continue to do its other necessary work. For all of the reasons discussed above, we support limitations on Y2K- related legal liability. Minimizing harm and assessing blame are each formidable and important tasks, but they cannot be done simultaneously without sacrificing one for the other. Minimizing harm is more important and there is an increased threat to our welfare if assessing blame adversely interferes with our ability to minimize harm. The value of incentives at this late date is very small. We trust that the collective wisdom of Congress will find ways to reduce these threats. We have additional background material available. Please contact IEEE staff contact Paula Dunne if you are interested in this material. We have other ideas beyond the scope of this legislation of what the U.S. federal government can do to help minimize harm throughout this crisis. We are ready to help in any way you may deem appropriate.

Respectfully,

The Institute of Electrical and Electronics Engineers ( IEEE ) Technical Activities Board Year 2000 Technical Information Focus Group.



-- R (riversoma@aol.com), July 20, 1999.


Another trigger point recently for me is the answer I received (and posted) from the oil industry analyst concerning crude oil's vulnerability to low temperatures. Even more frightening was the addition and clarification from Robert Cook.

We are told to expect local and regional blackouts of up to three weeks. We are told that neither oil nor chemical plants can safely handle extended "power out" situations.

Folks, to me, that sends the manufacturing AND transportation industries into a tailspin. Loss of or serious degredation of the transportation industry further "challenges" the ability of the electric industry to produce power.

and on, and on, and on

I'm now stocking for 2 years......

-- Jon Williamson (jwilliamson003@sprintmail.com), July 20, 1999.


TEXT: CIA ASSESSES GLOBAL Y2K READINESS (Senate hearing focuses on international Y2K issues) (3670)

"CIA research has identified those areas most likely to affect U.S. interests. They are: foreign nuclear reactors and power grids, military early warning systems, trade, oil and gas sectors, and worldwide shipping and air transport."

-- R (riversoma@aol.com), July 20, 1999.



And I often wonder: WHAT goes through the mind of a pollyanna when they read evidence such as this? (I guess you just have to understand their "memes"....)

-- King of Spain (madrid@aol.com), July 20, 1999.

Official & complete 60 MINUTES Transcript greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

SHOW: 60 MINUTES (7:00 PM ET)

May 23, 1999, Sunday

TYPE: Profile

LENGTH: 2595 words

HEADLINE: Y2K; LOOK AT HOW LOCAL GOVERNMENTS, INCLUDING WASHINGTON, DC, ARE LESS PREPARED FOR A POSSIBLE Y2K CRASH THAN MANY THINK

ANCHORS: STEVE KROFT

BODY: Y2K

STEVE KROFT, co-host: When we did our first story last fall on Y2K, the year 2000 computer glitch that threatens to shut down the world's computers come January 1st next year, a lot of people still thought it was a joke,

(Footage of computer room; computer chips; waterworks; 911 center; welfare office; traffic lights; computer room)

KROFT: (Voiceover) Local governments all across the country have become dependent upon computers and microprocessors to deliver services. They open the valves at the waterworks and handle 911 emergency calls. They send out the tax bills and print the welfare checks. They make the traffic lights turn red and green. And all of those systems are potentially vulnerable to the Y2K computer bug. And no city is more vulnerable than Washington, DC. The federal government's General Accounting Office has warned Congress that the Y2K situation is so bad here that the nation's capital may be unable to effectively ensure public safety, collect revenue, educate students or provide health-care services. (Footage of Mary Ellen Hanley and Kroft talking; business office)

KROFT: (Voiceover) No one is more aware of those problems than Mary Ellen Hanley, a top computer systems specialist who was hired by the District of Columbia to try and fix them. But when she took over last year as Washington's year 2000 program manager, she quickly discovered that there was no program and not much management. Sounds like you expected the worst.

Mr. MARY ELLEN HANLEY: I expected the worst.

(Footage of Hanley and Kroft talking; sign reading District of Columbia Project Year 2000, Y2K Project Office; people using computers; shirt reading Govt. of the District of Columbia Y2K Project 1998-1999) KROFT: (Voiceover) And she wasn't disappointed. Turns out no one even had a complete list of the departments and offices that make up Washington's local government, let alone a list of the computers and software they use. She quickly realized there was simply not enough time to make all the computers Y2K compliant. But you had no illusions that you could fix all of the problems by the year 2000?

Ms. HANLEY: Never, never.

Much thanks to FM the awesome for transcribing the above.

-- R (riversoma@aol.com), July 20, 1999.


Bennett Warns Y2K Bug Threatens Chem Plants BY JOHN HEILPRIN THE SALT LAKE TRIBUNE

Industrial chemical-related accidents could pose a "significant" threat to plant workers and nearby residents because of the Year 2000 computer problem, Sen. Bob Bennett, R-Utah, discloses in a report being released today.



-- R (riversoma@aol.com), July 20, 1999.


NEW POLL REVEALS HALF OF PERSONAL BANK DEPOSITS TO BE WITHDRAWN

Bank run potential approaching dangerous levels

[news]

A new poll from ZDNET reveals, for the first time, that the people polled plan to withdraw nearly half their dollars from the banks. That's a 50% withdrawal demand, with the banks holding only about 2% in cash reserves overall.

..

-- R (riversoma@aol.com), July 20, 1999.


Three things happened.

First, last spring, my girlfiend took a job with Ernst&Young(consultants) to work with CT in Canada to fix their y2k issues. Second, last summer, I was sent to a company meeting(low attendance), where they explained y2k and the potential impact of the problem for our company. Third, The company attached links from our internal web site to "scare" sites so that the employees could become better informed of the possible problems. They also set a facility inspection deadline of 1 month from the day of the meeting.

The third action brought many people in each building into the assesment program so that the budget could be increased for the repairs. Our deadline for repairs was June 99 and the software downloads to desktops started June 25 for everyone in the company. The company has never moved this fast on a project in all of the time that I have been here.

They were very serios about the implementation of this program and allocated enought money to fix the problem withing the time frame.

-- Ned P Zimmer (ned@nednet.com), July 20, 1999.



[ For Educational Purposes Only ]

THE REAL Y2K PROBLEM

By Lee Clarke, 07/20/99

The dreaded Y2K problem could be a disaster or it could be a huge dud. It's hard to tell. We'd better hope it's a dud because nobody really knows what a worst-case scenario would look like and it's hard to prepare for something you can't predict.

We expect cranks to predict doom and gloom. But serious people who have been dealing with the problem for several years acknowledge at least the following:

The Third World is impossibly behind, without any hope of making much progress. Literally billions and billions of lines of computer code in mission-critical systems around the world haven't been fixed. The US government is ahead of most of the world's governments but even many of its agencies haven't completed Y2K assessments.

Even if an individual company is Y2K-compliant, it still won't be safe because its suppliers and customers may not be. Besides, there's no standard for what compliant means - one person's compliance is another person's complacency.

Because of ambiguity in definitions of compliance, and because we don't know what a worst-case scenario is, many Y2K compliance statements and a lot of Y2K contingency plans are fantasy documents. Fantasy documents are based on best-case assumptions, and overstate how much safety they can deliver.

For example, in 1989, in Alaska, the oil industry's contingency plan promised an effective response to an oil spill larger than the one from the Exxon Valdez. It was a fantasy: There has never been a success story for a gigantic oil spill.

One important problem with fantasy documents is that they can lead to a false sense of security, setting the stage for a crisis in confidence when an accident or failure happens. Our interdependent world, which enriches us in so many ways, is the real Y2K problem.

Let's say Corporation X has hired its consultants, fixed its computer systems, and declared to stockholders that it's ready.

Is it?

Imagine the larger system that Corporation X lives in: suppliers, phone companies, electric companies, purchasers, bill collectors, insurance companies, banks, universities. Now think about all of the networks those companies are embedded in. The complexity is mind-boggling. The potential for Y2K catastrophe is not from individual computer chips failing but from the unpredictable interactions of multiple failures.

Managers should be extra careful because the same people who are experts in computer failures may not be experts in organizational failures. Given the urgency of the problem, and a real ignorance of how a lot of systems commingle, we are likely to see a lot of self-proclaimed experts unwittingly over-promising their real capabilities. That tends to happen when there's a lot at stake.

I'm no doom-sayer. I think it is most likely that the relatively rich throughout the world will experience minor disruptions while the relatively poor are at a higher risk for serious suffering.

That's generally how the world works anyway.

But the truth is that for many problems, including the Y2K bug, there is no such thing as adequate preparation because we can't anticipate enough of the important things that can go wrong.

Fantasy documents sometimes lead us to think that we're smarter than we really are. Better to admit the limitations of our knowledge. It's more honest, and it may even be safer.

Lee Clarke is associate professor of sociology at Rutgers University and author of ''Mission Improbable: Using Fantasy Documents to Tame Disaster'' (University of Chicago Press, 1999).
Phone: 732-906-8475;
e- mail:
lclarke@rci.rut gers.edu.

This story ran on page D04 of the Boston Globe on 07/20/99.
) Copyright 1999 Globe Newspaper Company.

---------------------------------------------------------------------- --------
xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxx

-- Ashton & Leska in Cascadia (allaha@earthlink.net), July 20, 1999.


All of the senate hearings on Y2K.

-- ve (tryin@hotmail.com), July 20, 1999.

The American Red Cross preparation guidelines, issued last December. The National Guard Y2k Drills.

Anybody have links to these?

This is a good thread. Keep 'em coming.

:)

-- FM (vidprof@aol.com), July 20, 1999.


Oh, and I forgot the Girl Scouts of America Y2k preparation page.

:)

-- FM (vidprof@aol.com), July 20, 1999.


First major impetus: From spouse, a Y2K glitch in a state agency program checked off as okay, discovered accidentally, coupled with knowledge of bureaucracies and disgruntled employees leaving timebombs in computer programs, added to father's mention of BBC program re Y2K. Almost instant GI.

Second major impetus: Senate Food Supply hearings in January.

There were many other stimuli but those two were key.

-- Old Git (anon@spamproblems.com), July 20, 1999.



ISRAEL ROSENCRANTZ: A year to go before computer disaster

Copyright ) 1999 Nando Media

Copyright ) 1999 American Reporter

Related quotes can be found at the American Reporter Web site, which is www.american-reporter. com

LOS ANGELES (January 4, 1999 3:15 p.m. EST http://www.nandotimes.com) - As you read this article, you are just a year away from what is potentially one of the most dramatic changes any civilization has ever experienced. When you look out the window 12 months from now, the world could be a completely different place.

It was several months ago that my wife, also a computer programmer, asked me what I thought of the "Y2K problem." At the time I didn't know much about it, but suffering from Male-Answer Syndrome, I told her that I wasn't worried and had a very convincing-sounding explanation as to why the matter is well in hand and there is nothing to worry about.

Then she read an article in Wired magazine and showed it to me. The article discussed how there were people panicking about Y2K. The problem was, the people panicking were the people that were supposed to be fixing it. I took another look, and what I found now worries me deeply -- as it also worries hundreds of prominent and powerful Americans, world leaders and distinguished computer experts.

The phrase "Y2K" is computer shorthand for Year 2000 (K is short for kilo, which means thousand). When people talk about "the Y2K problem" they are referring to a specific problem in the design of computer software (and firmware) and the effects that this defect will have in the coming year.

The problem is that we designed computers to store the date using only two digits to designate the year. While this might not be a problem for you when you write the date, for a computer it can be very troublesome.

We told computers that the date "01/23/55" means the 23rd of January 1955. What will the computer assume that "01/01/00" means? It will assume that it means the 1st of January 1900. That is the problem in a nutshell. Computers have no way to tell that the number after 99 should be 00.

So the next question that people ask me is how this will affect them. They tell me that they don't even have a computer, so they have no problems with this date problem. The problem is that our infrastructure does have computers in it that are vulnerable to the Y2K problem.

Our electric power, gas, water, sewage, and telephone all depend on an incredibly intricate network. For example, the power company uses the telephone system to control remote power facilities. The telephone needs the power from the power company to run the telephones.

The infrastructure web is highly interdependent and it is fragile. Without the infrastructure working at 100 percent, we don't have communications, banking, law enforcement, water treatment, hospitals or commerce.

As an example, consider that it takes Chevrolet roughly 20,000 different suppliers to build an automobile. They cannot build a car with 19,000 of their suppliers working: that is the effect of a 5 percent failure.

Consider another example, that bag of potato chips on your shelf. The potatoes were probably grown in South America. They used a tractor to plant the crops. That tractor required a huge number of parts to build, it requires parts when it needs to be repairs, and it needs fuel in order to run.

The potatoes are picked and sent to a warehouse. The farmer that grew the potatoes probably has a computer inventory system for the farm that tells him how much crop he has and where it is. This is an example of an inventory system.

Inventory systems have dates in them so that they know when something is too old, i.e., the product is expired. So any inventory system is at risk for Y2K problems.

The warehouse that received the potatoes also manages its stock with an inventory control system. They ship potatoes to a food plant using a computerized dispatch and order system to get the potatoes to the food plants that use them. The food plants also have warehouses, with their own inventory control systems in them.

The food plant itself has computers controlling the production facility and there is an expiration date stamped on the bag of chips. This bag of chips is then sent to another warehouse, with another inventory control system, on a truck that is dispatched according to another dispatch system.

The product eventually finds its way to the store, where it is controlled by another inventory system and eventually sold to you. The cash register is a computer, and you paid for the food using a credit card or debit card, which has an expiration date and uses the phone lines to verify that you are allowed to make the purchase.

So in order to get that bag of potato chips to you, there were potentially many hundred different computer control systems that all had to work perfectly to get it to you. And since they all have an idea what the date is supposed to be, they are all potentially vulnerable to the Y2K problem.

As if this wasn't enough, it isn't the desktop and mainframe computers that we should be most concerned about, it is the embedded systems. An embedded system is a computer put into some other device. For example, there are embedded systems in gas pumps, copy machines, alarm systems, pacemakers, traffic signals, etc. They are truly ubiquitous.

The problem is that the estimate is that from 1 to 7 percent of them will fail on Jan. 1, 2000. They will simply stop operating because they depend on the date and when the year changes from 99 to 00 they will become hopelessly confused and either fail to work or work in a way that is not at all helpful.

Embedded systems that control production process systems may cause the production to stop or go haywire, which would require that it be stopped. The IEEE report on embedded systems at is a good reference for the extent of our dependence on embedded systems.

You should also take a look at an article in EETimes written from the perspective of a computer user at . For example, an oil drilling rig has over 90 different embedded systems in it in 10,000 separate chips.

So now we can start to see the Y2K problem emerge, the problem is that our infrastructure is supported by a network of computers and embedded systems and that if even a small percentage of these fail, it can cause a complete collapse of the entire infrastructure.

This becomes even more serious because we are used to being able to handle single failures. When a light bulb goes out, you get a new one and replace it. The difference with the Y2K bug is that we are not talking about single failures; there is a great potential for massive simultaneous failures.

Ed Yardeni, chief economist at Deutsche Bank Securities in New York, says that there is a 70 percent chance of a global recession now. In his opinion, "the approach we are using now to fix Y2K guaranteed to create failure."

So why not just fix the problem? The obvious answer is just to "put two more digits in" and then it will be fine. There are several problems with this answer.

The first problem is that finding all the portions of a computer program that use the date isn't easy. Further, once you have found them all, you need to make changes to the program that will eliminate the Y2K bug without creating any new problems.

If you have every worked on a computer program, then you know how hard it is to make any kind of change without creating a new problem somewhere else. So even if we could find all the places that the program uses the date, we are still not guaranteed that the fix we make won't create new problems.

Second, there are lots of computers in mission critical applications everywhere. There are a lot of systems to examine to find all the bugs. To complicate matters, it isn't even just the program itself, it is also the data that the program uses.

If you read the Y2K compliance statements of the major database vendors, they all claim that they are compliant. What they don't tell you is that if you created a database that stored the dates in a non-Y2K compliant fashion, it doesn't matter if the database program is Y2K compliant, your data isn't and your application will fail.

The cost of fixing the programs is tremendous. Estimates are that it costs about $1 per line of code. The number of lines of code is very large. Companies may easily have 50,000-100,000 lines of code that require changing.

It takes a lot of time and a lot of money to find all the bugs, fix them, and then test to see that no new bugs were created. Generally, it takes as long to test as it did to create the fix.

According to Cap Gemini (one of the largest consulting companies for Y2K remediation) the average company takes between 18 and 30 months to fix their problem. The IRS has over 80,000,000 lines of computer code, running in 88,000 programs on 80 mainframe computers and the Social Security Administration has 30,000,000 lines of code to fix.

Four hundred programmers have been working on the problem since 1991, and had only fixed 6 million lines after five years of effort, according to The Washington Post. (Recently, the president announced that the Y2K upgrade at the Social Security Administration is complete.)

Fixing the software in regular computers is simple in comparison to fixing embedded systems. Remember that those systems are everywhere, they are hard to find, and it requires physically pulling chips out and putting new chips in to fix the problems.

Not only must the old chip be taken out, but the new chip that goes in must be programmed to do exactly the same thing as the old one without any new bugs. As already discussed, this is not a simple task. Federal Express started their remediation in 1994, and they think that they might be on target for completion in 1999.

As an analogy, supposed I asked you to polish a box of marbles by next week. Could you do it? Sure, no problem. What if my box is the size of the Grand Canyon -- now can you do it?

On "Talk of the Nation" on July 28, 1997, Ray Suarez interviewed power industry experts. Their comment was that there are not sufficient programmers in the world to fix the power plants in time. Furthermore, there is not enough manufacturing capacity in the chip manufacturing plants to create the new chips that would be needed to fix the problem.

The estimate is that there are 700,000 person-years of work to do to fix the problem. The size of the problem is huge. According to the Garter Group, there are 180 billion lines of software code will have to be screened worldwide.

Thus we now know that there is definitely a problem, that there are mission critical systems all over the world in all industries that will have failures due to the Y2K problem. Furthermore, we know that it is physically impossible to fix all the systems in time.

One thing that people will say to me is that they don't believe this is real because they haven't heard of this before. It is probably true that they haven't heard it. It is easy to dismiss this as being a complete fiction created by conspiracy theorists.

Information about Y2K has appeared on all the major networks and wire services. "60 Minutes" did a story on it in November 1998. The problem that our leaders have is that they don't want to create a panic. If the government announces that there is a chance that there will be a shortage of corn, then everyone runs out and buys corn, which creates a shortage. This phenomena is especially true in banking.

John Koskinen, deputy directory of the Office of Management and Budget and special assistant to the president for Y2K said, "I can't tell you really bad gloom and doom materials because it could create a panic."

Some people will say that they believe that the Y2K issue is a hoax. They feel that it was created by Y2K consultants who stand to make a great deal of money from the work. By now you can probably see that the Y2K problem is real.

Government investigations, industry experts, and businesses agree that there will be a profound impact from Y2K. According to the SEC filings, companies are spending an average of one percent of their total revenue on fixing their Y2K problems. Citicorp is spending $600,000,000 to fix their own systems. This problem is being taken very seriously.

Y2K is a "very very serious problem ... There's no point in sugar coating (it) ..." said an expert from the Internal Revenue Service in an April 1998 interview with the Wall Street Journal's Tom Herman. "If we don't fix the century-date problem, we will have a situation scarier than the average disaster movie you might see on a Sunday night."

The IRS official went on to say that the potential exists for nobody to get a tax return in the year 2000, and for the federal government be unable to collect up to 95 percent of its revenue.

The House Subcommittee on Government, Management, Information and Technology says that one third of government systems will not be ready by the March deadline set by the president to allow for critical testing to take place in time.

Rep. Steve Horn, R-Calif., issued a report card for the government on Nov. 23, 1998 that assigned an overall grade of D-. Some branches of the government indicate that they will be Y2K compliant in the year 2034.

The Center for Strategic and International Studies had a conference on Y2K on June 2, 1998, and another on Oct. 6, 1998. The consensus of the international experts is that there is reason to be concerned. Their findings are that throughout 1998 we should expect to see systems failing and that the sooner a person prepares the better. The Y2K proceedings are available at .

One of the points of contention among the experts on Y2K is the extent of preparation required. Some experts say that they think that the power will only really be out for about two weeks. This is, however, enough disruption to cause many shortages due to the domino effect (as a result of interdependencies).

The way that business operates nowadays is different from just a few years ago. It used to be that businesses would have a storeroom or warehouse where they would store goods before they were used. This is all changed now with a revolutionary idea in process management called "Just In Time" delivery.

The way this works is that the manufacturer or store arranges with its suppliers to deliver the goods at the time that they are needed. This saves time and money in materials handling expenses, but it creates a strong dependency.

For example, at a car assembly plant, the train carrying the supplies pulls up to the factory at the time that those parts are needed on the assembly line. The parts are taken off the train directly to the assembly line.

This is very efficient for both the supplier and the consumer, but it creates a disaster if the train doesn't deliver, as there is very little slack in the system to accommodate problems. Even if the auto manufacturer was prepared for Y2K, they are depending on their 100,000 suppliers and the trucks and trains in order to operate.

Utility companies are one of the most visible companies in Y2K preparation discussions. As Sen. Robert Bennett of Utah put it, "To be blunt, nothing works if you don't have power." The House Subcommittee report found that there were no utility companies that were investigating their vendors.

My local electric company, in their report on Y2K preparations say that they expect to fix all their problems in the first three months of 1999 after spending all of 1998 studying the problem. Remember, it takes at least 18 months for most companies to fix the problem, and my electric company is starting their fixing at the beginning of 1999.

This "three months" figure is difficult to believe, and that they are starting to fix the problem in January 1999 means that they are not likely to finish before Dec. 31, 1999.

Preparing for difficult times is a sensible, prudent thing to do. People that live in earthquake country and hurricane country already have learned this lesson. People that live where there are often big storms also know that their ability to "pick something up at the store" could be delayed for a long time with very little notice.

Not preparing, in the face of overwhelming evidence, because of fear that the preparation might not have been necessary, simply doesn't make sense. Generally when people hear about the full extent of the expected events of Y2K they go through the same reactions that any person would when faced with a catastrophe: denial, panic, anger, and then acceptance.

As a new guide called The Year 2000: Social Chaos of Social Transformation' (available at http://cassandraproject.org ) remarked, "At no other time in history have we been forced to deal with a deadline that is absolutely non- negotiable."

Individual preparedness begins by considering the basics: water, food, heat, sanitation and security. There are many resources for planning your own individual preparedness. The Cassandra Project recommends that people prepare for two months of independent living. They produced an "Individual Preparedness for Y2K" guide that has very realistic goals and guidelines. Other helpful advice can be found on Y2K for Women at .

The Federal Reserve Board also asked the U.S. Treasury to print money that they expect people will want to withdraw from banks in preparation for Y2K. They are printing $50 billion.

But the real solution to the Y2K problem is not going to be individual preparedness; the only way to survive is as a community. As a community, we can meet virtually any challenge, and Y2K presents a great opportunity for building communities.

One important thing you can do is to make sure is that in your community everyone has at least a minimal level of preparedness. We cannot depend solely upon our emergency services agencies to provide the safety net in an event of this size.

When the Red Cross responds to a disaster in some part of the world they always do it with the support of the unaffected portions of the world. This time, there will not be any.

So how should you prepare for Y2K? Take care of your individual preparedness, and talk with your neighbors. Building a community is the only really effective Y2K insurance there is.

Happy New Year!

Israel Rosenkrantz is a computer security consultant based in New Jersey,

where he prepared the original draft of this report for a presentation to his community.

-- R (riversoma@aol.com), July 20, 1999.


The vast majority of people in my experience when told about the expected severity of Y2K do not change their behavior to that which a GI would exhibit. This means that if "building a community" (getting other people to prepare) is the only insurance there can be, that there is no insurance with respect to Y2K, and that there can be none. Move to the boonies, buy all the long-term storage food you can, convert bank accounts/stocks/bonds/401ks/etc. to gold (after other purchases), buy guns, seeds, dogs, tools, antibiotics, matches, and candles, build a fence, get a woodstove & water treatment stuff, etc. THIS you CAN do.

www.y2ksafeminnesota.com

-- MinnesotaSmith (y2ksafeminnesota@hotmail.com), July 20, 1999.


Minnisota Smith,

I agree. The time for building community is way past. Alas.

-- R (riversoma@aol.com), July 20, 1999.


R, I don't think that there ever WAS any chance for community prep. I'm sorry to have to say that, but I tried. I gave TV interviews, I took part in community awareness seminars (watched them dwindle from 450+ to about 15 now, all heavy preparers), talked to people in grocery store lines, and some other stuff that probably was pretty silly.

No luck.

-- Jon Williamson (jwilliamson003@sprintmail.com), July 20, 1999.


Found out that the rumors of Nat Guard activation were true. Heard first hand from a state official that they were pretty sure they would need to activate our units in my homestate. Found out they were planning to requisition tanker trucks to store diesel for tractor trailer sized generators in my home city as a contingency plan.

Talked with a friend of mine who is former Army Ranger, who told me his buddies are bunkering up. His friends that are still active Spec Forces have drilled on shutting down highways.

Attended an API Taskforce 2000 meeting and heard the information first hand. Wasn't encouraged.

-- Gordon (g_gecko_69@hotmail.com), July 20, 1999.


Jon,

I hear you. Went the same road myself. I worked so hard in my community. All for naught. Couldn't understand it till I started doing research into pre Hitler germany. Most people are lemmings. Worse than sheep. At least a sheep will balk when it gets to a ledge.

-- R (riversoma@aol.com), July 20, 1999.


Here's a relatively recent stunner. Please read it slowly, and think about the size of these dominoes . . .

A CAP Gemini study revealed that 22 percent of the Fortune 1000 do not expect to get even their "mission critical" systems fixed by January 1. [New York Times, June, 1999]

-- Faith Weaver (suzsolutions@yahoo.com), July 20, 1999.


Riversoma

You are a freind and asset to all who come to the forum. Thanks

Bob P

-- Bob P (rpilc99206@aol.com), July 20, 1999.


"D.C. Plans to Mobilize Workers for Y2K Backup - City Still Far Behind In Fixing Computers"

http://www.washingtonpost.com/wp-srv/WPcap/1999-06/28/074r-062899- idx.html

-- Linkmeister (link@librarian.edu), July 20, 1999.


What got to me initially was Gary North's Remnant Review. I wasn't even a subscriber but I expect my name showed up on some mailing list he had bought. So I started looking around on the Web. That was in April, 1998. It's been a trip. After a while I realized I had to figure out the difference between the right stuff and bunkum.

For quite a while I felt like Carmichael -- that I was living on two tracks. Actually, I haven't gotten over this entirely. How can this HAPPEN to us? But nothing I've found since persuades me that it can't.

Many of these links are from last year. Most of them address Y2k in systemic terms, and are still pertinent, I think.

Institutions in the Age of Mindcrafting by Dee W. Hock, Founder and CEO Emeritus, VISA USA and VISA International. Presented at the Bionomics Annual Conference, San Francisco, California, October 22, 1994. His discussion of the deadly inertia of management systems is critical.

T om's Take Tom Benjamin, Nanaimo, B.C. This is a cry from the heart. Read it and you start trying very hard to find reasons that it won't happen the way he suggests.

Y2K: Who will do what and when will they do it? Douglass Carmichael. Final version July 1998. Carmichael is one of the few people taking the long view on Y2K. He's not necessarily more encouraging, but at least he shows it's possible to think about this without spazzing out.

DC Y2K Weather Reports Cory Hamasaki. Cory has been called the Hunter Thompson of Y2K. "No one knows what will happen but ... I expect to be very surprised. We, society, are doing a lot of things wrong. This is a singularity, you have to prepare but history is not a guide on this one, fog of war, all battle plans last until the first shot is fired."

The Effect of Change Control on Long-term Large-scale Y2K Software Projects Part I E. L. Core, November 6, 1998. An informed antidote to the claims of successful remediation now being heard.

Y2K and Our Big Bet Larry Shook

A Open Letter to the President of the United States Leon Kappelman, October, 1997

The Year2000 Problem: What systems are at risk? Y2K in maritime environments. A Lloyd's Register website, with a series of documents on different aspects.

The Y2K Crisis: A Global Ticking Time Bomb? Center for Strategic and International Studies, June 2, 1998. Conference Proceedings. A group of heavy hitters talking about this thing. I caught the last hour of C-Span's broadcast of this conference a year ago. That's when I realized I couldn't shuck this off any more.

Statement by KARLA W. CORCORAN, INSPECTOR GENERAL, UNITED STATES POSTAL SERVICE, before the SUBCOMMITTEE ON GOVERNMENT MANAGEMENT, INFORMATION, AND TECHNOLOGY of the COMMITTEE ON GOVERNMENT REFORM AND OVERSIGHT, U.S. HOUSE OF REPRESENTATIVES. February 23, 1999. And you begin to realize the consequences of the Postal Service not working for a while.

Statement of Harris N. Miller, President, Information Technology Association of America Testimony Before the Subcommittee on Oversight of the House Committee on Ways and Means. Hearing on the Year 2000 Computer Problem, May 7, 1998.

"This is not just an information technology challenge. This is a fundamental challenge to the ability of organizations throughout the world to continue to function. And it is a challenge which could have tremendous negative consequences for economies and governments throughout the world if it is not met. [....] "Virtually no one can say that he or she is not aware of the Y2K issue. But on the next stages-commitment to and actually solving the problem-we are very frustrated. The focus of conversation among those best versed in this issue is about how we are going to clean up after what appears now to be an inevitable train wreck. As a society, we are on the point of conceding failure."

Bon voyage...

-- Tom Carey (tomcarey@mindspring.com), July 22, 1999.


Moderation questions? read the FAQ