CAN ANYONE REFUTE THIS ? A SMART POLLY PUT THIS OUT - REFUTALS ARE SO FAR INADEQUATE.. HAMASAKI - MILNE - NORTH- YOURDON ANYONE CAN YOU REFUTE? A SMART POLLY PUT THIS OUT - REFUTALS ARE SO FAR INADEQUATE.. HAMASAKI - MILNE - NORTH- YOURDON ANYOgreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread |
"The possibility of infrastructure rupture is NEVER too remote to ignore, but it is no more a possibility on 1/1/2000 than any other day." This is the last 2 lines of an argument. I put it here so that you may know a little to start of what this discussion is about. (From the Civic Preparedness discussion list. - civicprep@4hlists.org.)QUESTION I ask that you either agree or refute the simple logical conclusion I sent you below. If the following is wrong, then I may be wasting my time, I would hope that you would show me what I am missing.
Assumption 1: All computers and embedded chips will not be fixed by 1/1/2000. Assumption 2: No one can know what percent of non-compliancy it would take to set off some form of collapse of the infrastructure.
Conclusion: The possibility of infrastructure rupture is not remote enough to ignore.
ANSWER:
Assumption #1 is correct. All computers will not be fixed on time. However, from there the logic breaks down, although I can understand why people who aren't involved with computers might think that #2 and #3 would be true.
There are 3 misconceptions that people have about the Y2K problem that make it seem as if your assumptions would be logical:
1) That all computers and embedded chips are vulnerable to the Y2K bug because they all have internal clocks, 2) that many computerized systems no longer have manual backup procedures, and 3) that if a computer with a Y2K problem has not been fixed, it will fail or crash altogether.
All three of the above statements are false under the circumstances we're discussing - that is, critical infrastructure like the power and water grid, train systems, medical equipment, communications satellites, etc.
First let's look at myth #1. It's true that all computer systems have internal clocks, and those clocks are capable of tracking the date. However, a programmer has to go out of his way to make a computer aware of the date. All a computer's clock does is measure sequential time in milliseconds. It does math based on that. For example if a pacemaker has to give your heart a jolt of electricity every 3 seconds, it just counts out 3000 pulses of the clock, does its task, then starts again for another 3000. It has no clue what the time or date is. The programmer would never have a reason to give it that information.
If an application DOES have to keep track of the date, a day is likewise however many milliseconds equal a day. At that point the computer's clock increments the date. This is called a "Julian Day Number". Just as an example, most personal computers use January 1, 1900 as the beginning of the Julian calendar - day number 00000 (they decided in the case of PC's to standardize on 5 digit Julian dates). So at the end of each 24 hours the clock just increments another number. Under that scenario, December 31, 1999 is day number 36525, and January 1, 2000 is day number 36526. Nothing special. Just another day. A computer may *display* a date in the format MM/DD/YY, but in the types of applications we are talking about (infrastructure), very few store their dates that way internally, which is what would cause a problem on 1/1/2000. Satellites, power plants, train systems, and the like use this Julian calendar, not the Gregorian calendar that we are used to thinking of, which is the only type of system that would be affected.
The types of computer systems that do use Gregorian calendars are *business* applications. Your power company's billing department might have some old systems with Y2K problems. In that case, you might get a bill saying you are 100 years overdue! But this is obviously an error and will not cause system rupture - just headaches for the poor folks who have to straighten out the billing problem. Businesses may lose money because their reporting or billing is inaccurate, but that's hardly the end of the world.
Now let's look at myth #2. Most people think that many infrastructure systems that are computerized have no manual backup. People like Gary North have really worked hard to scare people by telling them things like the trains will stop running because train systems are computerized and there are no longer any manual switches on many lines. This is completely false. Talk to any actual railroad line foreman and they will tell you there are manual switches and they have to use them all the time. Nobody builds critical systems like these without manual backup, for the simple reason that (like I said earlier) computer systems crash *every day.* Some of the problems with them are harder to find and fix than Y2K. Right now, I'll bet there's at least one embedded chip or system down somewhere in your power grid and you'll never know it. ALL critical systems have manual backup. Again, the people who will be affected by the problem are mostly businesses who are running non-critical systems. If somebody's online store crashes, it might be disastrous for their business but not for the world at large.
Now we'll talk about the last myth: that "non-compliance" equals complete failure. It doesn't. All a Y2K bug means is that the system doesn't know the correct date. This could be a drag in the case of something like your bank, which might calculate the interest wrong on your mortgage. But the computer won't lose your balance or any other data. The only thing it will lose is the ability to do date related calculations correctly. In any case, banking systems have been compliant for a long time because they've had to deal with loans that won't expire till after 2000 ever since 1970. Social Security and Medicare have to deal with beneficiaries born in the 1800's, so they've had 4 digits in their dates too.
So, to figure out whether Y2K is going to cause major infrastructure rupture, the questions need to be asked really are:
1) What percentage of computers are running critical infrastructure? 2) Of that percentage, how many use the Gregorian date system? 3) Of that percentage, how many will fail if they don't know what day it is? 4) Of *that* percentage, how many do not have manual backup procedures?
Based on what I've told you, I hope you can see that the final number you would arrive at is infinitessimally small. In fact, just as big on that day as any other day. A Julian clock is like an odometer on your car - when it will become inaccurate depends on when it was set, how much you drive your car and how many digits the odometer has. Lots of Julian clocks on older systems have already rolled over, and that can happen on any day.
Even the financial systems that some people have worried about are not having many problems. You know, the fiscal year 2000 started on July 1 of this year. Lots of wags predicted major losses for banks and other economic problems on that day. Nothing happened that anybody noticed. The next day that people worry about will be September 9th, because a lot of programmers used to enter 9/9/99 as an indicator that a process should continue forever - not realizing that some of their systems would still be in operation on that day! I'll wager nothing much will happen on that day either, at least that you or I will be able to discern. Sure, there'll be some frantic programmers working overtime to fix it. There may be some hassles and headaches, some lost business, some lawsuits. But Armaggedon? Hardly.
The possibility of infrastructure rupture is NEVER too remote to ignore, but it is no more a possibility on 1/1/2000 than any other day.
-- Z (Z@ZZZ.net), August 10, 1999
BS!! There have been several replies of high quality refuting this essay.
-- Mitchell Barnes (spanda@inreach.com), August 10, 1999.
The term "infrastructure rupture" could mean many different things. Regardless of its meaning, Washington D.C. is making major contingency plans for early next year. Having extra water and food on hand as well as a way to stay warm is not a bad idea.[Fair Use: For Educational/Research Purposes Only]
District Prepares for Y2K System Failures
By Eric Lipton
Washington Post Staff Writer
Monday, June 28, 1999; Page A1
The District government, recognizing that its year 2000 repair program likely will not be completed on time, is planning a massive New Year's Eve mobilization of emergency personnel and other staff to ensure that critical city services are not interrupted if computer systems fail.
Police will be stationed at more than 120 locations across the city, working 12-hour shifts, to take walk-in requests for emergency services. Twenty-one "warming centers," each supplied with food, water and cots, will open. School crossing guards will be on call, ready to replace traffic lights at major intersections. And D.C. General Hospital will have extra staff members as many as 175 on site.
These are just a few of the 88 contingency and emergency plans the District is feverishly working to put in place by the end of the year. Similar efforts are underway across the United States among governments and private companies, but in the District, officials have acknowledged the city is so far behind on its Y2K fix that it may have to rely on some of these "work-around" techniques.
"Because we began late, there may be things that suffer an interruption that we did not completely get to," said D.C. Chief Technology Officer Suzanne J. Peck. "Within our agencies ... in some function, a handful may fail temporarily."
Officials are confident that most of these plans even those that will be put into effect regardless of any system failure will not be needed, and that even in the District, Y2K will be one of the century's most hyped nonevents.
City officials want to convince the public that the new year will begin in the nation's capital without chaos no matter what happens with D.C. operations or outside services such as telephone, gas and electricity.
"Our intent is not to alarm people, but put people at ease that things are under control," Mayor Anthony A. Williams (D) said yesterday. "We are going to have this city work for people."
Added Cmdr. David B. McDonald, the supervisor of police Y2K planning: "We want to reassure the residents and visitors to the District that even if Armageddon comes, we will assist and protect the public."
The D.C. Council will be briefed on the public safety contingency plans at an oversight hearing this morning.
The District's own assessment of its progress in making year 2000 fixes demonstrates the need for such planning: With six months left in the year, only 41 percent of the District's 336 major computer systems have been fixed. The rest are scheduled to be repaired and tested by the end of October.
Of the city's 73 agencies, 19 including key departments such as Health, Housing and Community Development; Tax and Revenue; Child and Family Services; and Public Works are not even halfway done with their year 2000 repairs and planning.
Williams said he is "not at all surprised" that so much work remains, given the city's late start on addressing the Y2K problem. But he added that he is reasonably comfortable with the status of the city's Y2K repair efforts and has the impression that the District is about even with other major cities, saying the city may be understating its "readiness."
Virginia and Maryland, by comparison, say their government systems are virtually Y2K-proof, and while they also have contingency plans, they are more confident that they won't have to use them.
The year 2000 computer glitch, popularly known as Y2K, stems from the use in many computer systems of two-digit date fields, leading many machines to interpret "00" as 1900, not 2000. This could cause systems to transmit bad data, malfunction or crash.
The District's late start is largely to blame for its lagging effort. While Maryland and Virginia began working on the problem several years ago, the District waited until last summer. Recognizing the danger of a catastrophic failure in the city, Congress gave the District $62 million in emergency funding this year to accelerate the work. But even with an army of more than 300 consultants at work most under a $76 million contract with IBM Corp. success is far from assured.
The struggle at D.C. General Hospital illustrates the challenge. D.C. General and its related health care divisions are about 48 percent "ready," according to ratings released Wednesday by the District's year 2000 program.
The hospital's mainframe computer system which handles medical records, patient accounts, budgeting, laboratory data, patient registration and other hospital operations will falter at year's end unless several million dollars in repairs are made.
The city is rushing to install a new computer system, but the first phase is not scheduled to be operating until mid-September. Officials are debating whether to repair the old computer in case the new one is not ready.
And that is only the beginning.
An estimated 80 percent of the 1,000 pagers assigned to staff at D.C. General and other divisions of the city's hospital and health care network are not Y2K compatible. At the start of June, the city had not issued a purchase order to buy replacements.
Each of the hospital's four ultrasound machines and 21 defibrillators used to reestablish a regular heartbeat-is not Y2K compliant, although replacements are on order. And the critical-care monitoring system in the intensive-care unit also must be replaced.
"You can't have an emergency room without a defibrillator. You can't have an intensive-care unit without monitors," said William D. Wild, senior vice president for compliance at D.C. General.
Given all this uncertainty and fewer than 190 days before the end of the year D.C. General administrators and staff members are spending hundreds of hours preparing backup plans.
The 250-bed hospital, which served 51,237 in its emergency room last year and 80,000 in its hospital clinics, is arranging to have 50 temporary workers available to hand-process records and other tasks if computers fail. As many as 124 employees including nurses, doctors and financial staff members may be asked to stay overnight on New Year's Eve, Wild said.
An extra 30 to 60 days' worth of pharmaceuticals is being ordered, and up to 90 days' worth of other basic supplies from bottled water to bandages is being purchased. The cost to the city just for the contingency planning, excluding the basic Y2K repairs, is about $4 million.
Even at agencies where year 2000 repairs are farther along, extensive contingency planning is underway. The broadest effort involves emergency services, where the plans are largely directed at anticipating failure of outside utilities such as electricity and telephone all extremely unlikely.
"The phone company says they are 98 percent certain it won't go down. The power companies say they are 99 percent certain everything will work," McDonald said. "But if that 2 percent and 1 percent cross, we need to be prepared."
Every officer in the city's 3,600-person police force will work 12- hour shifts during the New Year's weekend. Starting about 10:30 p.m. on New Year's Eve, the police department will deploy two-person teams to 120 locations across the District, including fire stations, convenience stores and fast-food restaurants.
Each officer will have a radio, and each of the 10 antenna sites for the radio system will have a backup generator. The city's 150 school crossing guards will learn how to handle traffic if lights go out. Staff is prepared to process crime reports and bookings by hand.
"We can't say, 'Sorry, Mr. Burglar, we can't book you today. Why don't you come back tomorrow?' " McDonald said.
At the Fire and Emergency Medical Services Department, leave time is being restricted for the 1,763-member staff between Dec. 15 and Jan. 15. Crews on the 16 ladder trucks are being given the tools and training to perform elevator rescues, supplementing the city's three regular rescue squads.
Backup to the city's computer-aided dispatch system is ready: thousands of 3-by-5 cards detailing which trucks to send depending on the address of a call. Fire trucks and ambulances already have been checked.
The city's Emergency Operations Center will be in gear before New Year's Eve, staffed by the public-safety-related agencies, including the Red Cross and the National Guard. All 21 warming centers, most at city schools, will be open New Year's Eve.
"If need be, people who go to these centers will be warm. They will have somewhere to sleep and something to eat," Emergency Management Program Officer Barbara Childs said.
The contingency planning extends far beyond the central emergency agencies.
The D.C. Water and Sewer Authority, for example, will spend more than $1 million to rent several locomotive-size generators to ensure that water will flow if the electricity goes out.
The Public Works Department will ensure that the city has 87,000 gallons of vehicle fuel available, double the normal supply. Extra truck parts, backup generators and other supplies also are on order. Plans have even been made for trash collection crews (they would work day and night), tree maintenance (complaints would be taken at the Reeves Municipal Center on 14th Street NW) and rat patrol (private exterminators would be used).
Officials are urging residents to prepare for the new year as well, stocking up on food, fuel, bottled water and other supplies as they would for a winter storm.
Jack L. Brock Jr., a U.S. General Accounting Office computer expert who described the city's Y2K outlook in February as "bleak," said last week that while he is reassured the city is making contingency plans, it must be able to implement them.
"They can't just be paper plans," said Brock, whose office is about to start another review of the District's Y2K status for Congress. "They have to do enough testing and validation to be confident that they will work."
Interim City Administrator Norman Dong said Williams is committed to ensuring that the plans work. To date, 38 of the 88 contingency plans are in draft or final form. From July until September, 23 mission- critical city agencies will hold mock drills.
"Our hope and expectation is that it will be business as usual," Dong said. "But we are taking nothing for granted. We want to make sure we are covered, that no matter what happens, we are prepared."
) 1999 The Washington Post Company
----------------------------------------------------------------------
-- Linkmeister (link@librarian.edu), August 10, 1999.
From http://www .senate.gov/~y2k/hearings/990715/speck.htmTESTIMONY OF
SUZANNE J. PECK
CHIEF TECHNOLOGY OFFICER
GOVERNMENT OF THE DISTRICT OF COLUMBIA
BEFORE THE
SENATE SPECIAL COMMITTEE ON THE
YEAR 2000 TECHNOLOGY PROBLEM
JULY 15, 1999
....(snip).....
There seems to be a degree of misunderstanding about contingency planning as integral to the District's Year 2000 efforts - especially as it has been represented in the media. The development of contingency plans does not translate into an expectation that the plans will be executed. Any well-managed business enterprise has - or should have - contingency or back-up plans to deal with unanticipated service interruptions. In contingency planning "the best contingency plans are ones that never get used." But they always need to be there, meticulous and tested. Ours will be.
-- Hoffmeister (hoff_meister@my-deja.com), August 10, 1999.
yor'in handel sez it ahl...zzzzzzzzzjefro
-- jefro (jefro@going.fishen), August 10, 1999.
The bottom line claim that the possibility of an infrastructure collapse on Jan 1 has no more probability that that of any other day -- even though acknowledging that a significant number of computers and embedded systems will experience Y2K problems, thoughout many diverse industries, simultaneously -- essentially implies the following: Y2K COMPUTER PROBLEMS ARE TRIVIAL, AND WE NEED NOT REALLY BE CONCERNED.
This is nothing more than what I have called "The Last Pollyanna Defense". And I would then ask: Why then do we have claims that foreign nations (i.e., "those other guys") are going to suffer MAJOR disruptions, including power blackouts? Why does the American Red Cross have a preparedness list for Y2K DISRUPTIONS, if indeed there is nothing really "special" about the year 2000 computer problem.
This is not the work of a "smart" polly, this is the work of a "desperate" polly....
-- King of Spain (madrid@aol.com), August 10, 1999.
Has anyone been invited to sleep over in Clinton's Y2K bunker?
-- ~~~~ (~~~@~~~.com), August 10, 1999.
Gee whiz guy/gal, I nearly missed your header on the "New Questions" page. In order that we may be alerted to future new threads started by yourself, perhaps you could type in a three or four line header so that it really stands out from the rest.Oh, you did type FOUR lines of header. My mistake.
Perhaps, so that your fine piece doesn't get lost in the dross, you could type your header IN ALL CAPS LIKE THIS. Three or four lines of header in all caps would really be great.
Oh, you did type your header IN ALL CAPS.
Looks like you're ahead of the game. Can't wait to read your next straw man in the guise of an expose`.
Best Wishes,
-- Bingo1 (howe9@pop.shentel.net), August 10, 1999.
Contingency planning for families:http://www.fema.gov/library/emfdwtr.htm
[snip]
Emergency Food and Water Supplies
If an earthquake, hurricane, winter storm or other disaster ever strikes your community, you might not have access to food, water and electricity for days, or even weeks. By taking a little time now to store emergency food and water supplies, you can provide for your entire family.
This brochure was developed by the Federal Emergency Management Agency's Community and Family Preparedness Programs which provides information to help families prepare for all types of disasters.
[snip]
-- Linkmeister (link@librarian.edu), August 10, 1999.
Your title is a bit redundant there....odd question: the first string of statements is generically true - but then you draw the wrong conclusion from it in your haste to convert me to your cause.We don't know what will happen, nor how long. The Navy War College uses Oct to March, 2000. I'd personally go at least to mid-summer (2nd quarter 2000) to flag IRS and the potential "tax revolt" as people realize that the government is having more troubles finding tax cheats thtn they are letting on...but I digress. Let us assume that there may be problems in the vicinity of year 2000.
There is a chance that nothing will happen through the whole year 2000 troubled zone. This is perhaps a 0.5% chance, perhaps smaller. No one can give any evidence that "nothing will fail" nor can anybosy give any test results (since no unrepaired infrastructure and economic system has been tested) to show that the troubles will be minor. Now, what nobody can say either is what constitutes a "bump in the road" nor how long the "bump" will last - this certainly leaves a way to claim anything.
There is a chance that we may see a long period of great disruption - North and "Infomagic" use more time discussing this theory than I do, but each to his own - as long as he is spending his money - who cares? And I do not see North spending my money - but I do see Clinton spending/wasting my money...This long-term disaster may be as much as a 5% or 10% chance, or as little as a 0.5% chance. Nobody can tell - we are approaching the first such test though at 60 seconds per minute.
Perhaps the most telling way to predict recovery - even from dire straits - is the population's resiliancy and determination to help themselves - the evidence that we (collectively) are able to do this in today's society is slight, and getting farther between any positive signs.
Finally, there is a chance that we will see an irregular and unpredictable period of irregular and unpredictable disruptions affecting irregular and unpredictable systems and things in irregular and unpredictable ways with irregular and unpredictable results. People will react to these disruptions in irregular and unpredictable ways - many of these reactions are likely to be anti-social and "unfriendly" based on past period of losses. We are also approaching this test.
If the others are so low a probability - this then may be 99% to 95% likely. Preparing adequately for various uncertainities is a good way to mentally get ready for what really might happen - and I'm willing to bet that most people are going to be faced with troubles that NOBODY has predicted.
Since there are only three possible outcomes to the year 2000 troubles, all must chose one of the three. (You cannot safely leave this world to seek another with a different clock. If you choose to leave, you cannot reliably return - the last such return was approximately 1967 +/- 4 years ago.) Once such a decision is made, each person will base his or her actions on his or her decision.
If there were any evidence that this would be only minor troubles - the administration's fabled bump-in-the road - I have not seen it. Every press release, every test to date, and every story that includes any form of background data about what the "headline" is based on can be (has been) shredded by analyzing just the first-level affects of potential year 2000 disruptions.
If tertiary (world-wide) effects are included - the picture gets much more gloomy. There simply is no good news - there is a very bright light - as bright as possible is being shown by our dear administration - but this is simply a very large amount of frosting and many birthday candles.
___
Repeatedly though - the forum is challenged to "prove" something from a battery of disgruntled people such as CPR and ZZZ (above) - their zeal and religious fervor must have a source - to date, the real drive (reason) of his campaign is unknown, but something is feeding his anger and frustration and bitterness.
But the actual question lies in the assumption made in ZZZ's conclusion - I don't need anybody to convince me that there is a very real potential for significant troubles coming - I've seen enough of them trying to test and eliminate bugs in my company's own programs. I know absolutely how hard it is to get the things running correctly in the first place - thus, I am pleased when 99.9999999999% of all programs in the world run perfectly all at the same time.
What ZZZ must answer is: what happens when only 99.9999 percent of this world's program work? 99.99%? 98% 95% 90% 70%? .....
____
Now, what the poster (ZZZ) must do is simply convice me he knows exactly what will fail, and where, and for how long. Then I will make accurate preparations for that failure. All I am doing is preparing for the most likely failures and some reasonable time frame before things get fixed back to normal, and all the ahile hoping that no significant troubles will occur.
__
Birthday candles burn bright, but burn quick. They can light a room - for only a few minutes. What Clinton and ZZZ don't realize is that the birthday candles, the bright light they show now has no basis - and that it may become very dark. The deadline approaches - and they have convinced most people NOT to prepare. But the computer doesn't care what any polls say - computers don't listen to polls.
They just fail. Or they just keep on working. But they don't listen to politicians spinning reports from other managers who wrote a report to spin a report.
____
The frustrating part of his essay is in his zealous determination to tell me what to do with my money and my time. See he cannot tell you, me, or anybody else what will happen, but demands the right to tell listeners that they are wrong for trying to prevent problems. Why?
And that, my dear listeners, is wrong.
-- Robert A. Cook, PE (Kennesaw, GA) (cook.r@csaatl.com), August 10, 1999.
The essay isn't worth refuting!For instance, no-one but a polly would claim ALL computers MUST fail if their Y2K "problems" aren't fixed.
To many errors to contiue wasting time.............
-- Jon Johnson (narnia4@usa.net), August 10, 1999.
Kind of an interesting illustration of techniques here.If you're trying to make a point, you get in, make the point, and get out like Hoffmeister.
If you're trying to KILL a good point by the 'enemy', you just paste in the whole damn newspaper like Kevin.
Hoff's point: Contingency plans are NEITHER guarantees nor expectations of specific problems. They are efforts to be able to respond effectively even to the vanishingly unlikely.
Kevin's point: MIT has some BIG hard drives.
-- Flint (flintc@mindspring.com), August 10, 1999.
Still smoke-free Flint?
-- Bingo1 (howe9@pop.shentel.net), August 10, 1999.
ZZZ,Before answering this, let me begin by saying that I AM NOT any kind of computer expert, nor do I claim any technical wizardry of any sort. I do however, posess a 'logical" mind, and there are several "holes" in your rebuttal. The first problem is that there is no need to assume that "all computers will break down at once" or that "all embedded chips contain clocks." The problem lies with the computers that are not repaired, remediated, or replaced. On top of this problem, your rebuttal further assumes that all software used to fix the problem is "ok," and further assume that each program can then "converse" with other programs, and even further assume that there wll be enough computer programmers around to repair what is broken, or has yet been fixed. The second problem exists within your rebuttal is the fact that your "time logic" only deals with the time problem on two levels......the hardware and the BIOS system. It fails to address software and stored data which are by far the most difficult to fix. I am in total agreement that we'll see computers for the most part "up and running" to bring in the new year, but EVENTUALLY all the corrupted data, software and the means to repair those systems will EVENTUALLY overwhelm the computers, the operators, the customers,the vendors, and of course the men and women "in the trenches" trying their level best to keep us in a world we're all familiar with.( to whom I remove my hat, and offer thanks for their valiant effort!) Y2K will defy a great deal of logical thinking, and short-term "rear-view-mirrors" that assume "all is well"...
Just a dumb consumer, Mark
-- mark (marklin333@yahoo.com), August 10, 1999.
Just curious, Mark.Why do you think these errors will overwhelm the system, when they are not today?
-- Hoffmeister (hoff_meister@my-deja.com), August 10, 1999.
Duhhh. Maybe because TODAY isn't January 1, 2000???
Oh, shoot, I see that you asked Mark. Sorry.
-- King of Spain (madrid@aol.com), August 10, 1999.
Flint, you and Hoff just refuted the ZZZZ's post, and aren't even aware of it.If there is "No greater chance of infrastructure failure on 1/1/2000 than any other day", why make contingency plans at all, let alone the LOCOMOTIVE SIZED GENERATORS, CORPORATE & GOVT WAR ROOMS, HOSPITALS STORING 90 DAYS OF WATER, etc etc.
Oh that's right - cause us damn doomers are "forcing unnecessary measures like contingency plans, live testing and independent verification" as Maria says.
-- a (a@a.a), August 10, 1999.
ZZZZZZZ, Your irrefutable argument is putting me to sleep. If Julian calendars and billing errors were all there was to Y2K, governments and corporations would not be stockpiling fuel, supplies, and other necessities. And the CIA would not be reporting that many exporting countries will be toast next year. And police departments, Feds, et al, would not be cancelling leave in December. And billions of dollars would not have been spent in an attempt to solve such a trivial problem.While you only address major infrastructure, the topic cannot be discussed in such narrow terms. Will pollys be happy if the power stays on but goods, services, and petroleum products are scarce at best? It is the big picture that is missing from your argument.
I am not a polly nor a doomer. I admit that I do not know what will happen. And neither do you. But I do know that there is a threat worth taking seriously. I am making preparations for my family for the same reason I buy insurance: Just in case. And I hope you do to.
Good luck in 2K.
-- Jack Binns (pollys@makeme.sleepy), August 10, 1999.
Z,I do not think you are a good programmer, though you might like others to believe so. To a COBOL programmer, a Gregorian date is a structured number of three parts - month, day, and year (in some sequence usually defined by the programmer). A Julian date is a structured number of two parts - year and day of the year (always in that order). Julian was/is used to conserve space and to decrease the number of steps required to subtract or add two or more dates.
December 31, 1999 is not your Julian '36525', rather it is '99365'. January 1, 2000 is likewise '00001'. Therein lies the problem. Neither Julian nor Gregorian dates permit simple math using a two digit year.
Now, some applications do use a weird date and count the number of days since the arbitrary date. These applciations are resonably rare and were most often developed by long forgotten vendors with lots of programmers trying to earn their daily wage proving they could write obscure code.
More recently, IBM implemented the Lillian date (?) in one of their latest COBOL incantations (CII, C/MVS, C/OS390, ?). This date is similar to your's in concept, but I have never seen it used in any mortally written code.
I think your entire analysis falls apart from simple lack of programming experience. Your points are based upon a woefully incorrect understanding of how mainframe programmers use dates.
Yours in COBOL,
-- Uhmm.. (jfcp81a@prodigy.com), August 10, 1999.
Z,I just noticed that you also advanced the 9/9/99 straw man. To a COBOL programmer, a Gregorian date is of fixed length. September 9, 1999 might look like this - '090999' or mmddyy. Now, while a programmer might spike a date field with '999999' to indicate end-of-process, few would use an actual date like you seem to think. I believe there will be few computer problems on September ninth, because 090999 IS NOT EQUAL TO 999999.
On the other hand, many programmers (and some mainframe tape managment systems) used the Julian date '99365' to indicate a computer data tape should never expire. Surprise! Could all of these tapes be erased the day after December 31, 1999? (Well, probably not, but I hope you see my point).
Sincerely,
-- Uhmm.. (jfcp81a@prodigy.com), August 10, 1999.
Thanks folks, for proving that you CAN do it with decorum. Keep this up and LOTS of people will wonder what ever happened to us.chuck
-- Chuck, a night driver (rienzoo@en.com), August 10, 1999.
If one error can do this, than we are in a world of HURT.....Bringing a phone system down with one stroke
-- PJC (paulchri@msn.com), August 10, 1999.
Z,OK, I promise I will not re-read your post even one more time - after this. But here it is... You seem to think that personal computers use some form of day counter based upon an arbirtary start date of January 1, 1900. Actually, different mainframe computers assume different dates upon first boot. Almost all personal computers, however, assume a date in the 1980's (couldn't be 1984, could it? Nawww... probably 1982). This was the first date programmed into the original IBM/Intel chip/BIOS/DOS (?), and the tradition has been LARGELY carried forward so far as I know until quite recent times.
Yours in ancient BIOS lore,
-- Uhmm.. (jfcp81a@prodigy.com), August 10, 1999.
What does refute mean?
-- Maria (anon@ymous.com), August 10, 1999.
Problem Solved...
-- PJC (paulchri@msn.com), August 10, 1999.
No one claims that ALL computers will have problems. Most people claim that only a small fraction of computers will have problems. But a small fraction of a very large number is still a significant number!
-- biker (y2kbiker@worldnet.att.net), August 11, 1999.
More to the point: what does "refutal" mean? It looks a bit like a pharmaceutical name, perhaps a sedative or muscle relaxant. "New REFUTAL -- when morphine isn't quite enough."
-- Mac (sneak@lurk.hid), August 11, 1999.
What does refute mean?-- Maria (anon@ymous.com), August 10, 1999.
You can't be serious,,,,
-- Brian (imager@home.com), August 11, 1999.
Thank you everyone. Please note the post was not mine. I found same on. ( the Civic Preparedness discussion list. - civicprep@4hlists.org.)I apologize for the big headline, but it came up twice accidentally.
The response is adequate now. Refute is in the dictionary, Maria, look it up.
Z
-- Z (Z@ZZZ.net), August 11, 1999.
>>>Just as an example, most personal computers use January 1, 1900 as the beginning of the Julian calendar - day number 00000 (they decided in the case of PC's to standardize on 5 digit Julian dates). So at the end of each 24 hours the clock just increments another number. Under that scenario, December 31, 1999 is day number 36525, and January 1, 2000 is day number 36526. Nothing special. Just another day. A computer may *display* a date in the format MM/DD/YY, but in the types of applications we are talking about (infrastructure), very few store their dates that way internally, which is what would cause a problem on 1/1/2000. Satellites, power plants, train systems, and the like use this Julian calendar, not the Gregorian calendar that we are used to thinking of, which is the only type of system that would be affected.Somebody should have told Julius Caesar he was making a big mistake. No one would be able to use his Julian calendar until 1950 years after his death. And this despite the fact that most western lands have been off the Julian and on the Gregorian calendar for at least the last few hundred years. And to think that computers still run on the old system, with its embarassing leftover minutes every year. That's what you get for not upgrading those damn mainframes in the last 200 years. Makes you wonder how they ever handled the rollover from 1899 to 1900. http://www.magnet.ch/serendipity/hermetic/cal_stud/cal_art.htm#Julian_ Calendar
-- Spanky (nospam@spamfree.ent), August 11, 1999.
Dino:Thanks for being the first to point out that the description of Julian date is totally incorrect. The other blatant error was the "We started fiscal year 2000 in July of 1999." WE did? I would think anyone who's been following Y2k knows that many firms started fiscal year 2000 in January of 1999, some in February, etc. There's no magic number for fiscal years applying across all boards. The federal government hasn't started fiscal year 2000 yet.
IMO, this was just another case of using bad input to draw a conclusion. I sure wouldn't agree with the conclusion based on THIS data.
-- Anita (spoonera@msn.com), August 11, 1999.
Just for the record, that wasn't my post above. The Maria imposter posts quite a bit. I think this person is very childish but not much I can do about it. I guess I am getting on this person enough for him or her to behave this way. Knock yourself out kid.a, do you know anything, anything at all about testing? If you don't then ask me about it. I'll tell you how it's done and how it's not done. But don't misquote me. I don't think anyone is doing live testing no matter how much the doomers chant it must be done. It can't be done period. The contingency planning and the independent verification is being done because of the doomer chant.
-- Maria (anon@ymous.com), August 11, 1999.
Maria, is it then a fair statement that the "100% remediation completed by 12/31/98 with a FULL YEAR for testing" fantasy was, then, utter hogwash? I mean, I was always under the impression that it COULD have been done IF the remediation work had by some miracle been able to be completed last year. But you are telling us, based on your wealth of experience and superior logical reasoning that we are always in awe of, that in fact even if remediation had completed in, say, 1995, we would still be entering 2000 with complete wonderment as to what will happen????
Somehow, that makes no sense whatsoever to me. Of course, I don't know much about satellites, either....
-- King of Spain (madrid@aol.com), August 11, 1999.
This one is all too easy to refute, but I'd love to see Yourdon, Hamasaki, etc. spike it. Ummm... has already done an excellent job refuting some of the clock issues (PC Julian dates starting in 1/1/1900 - give me a break), etc., etc.Let's look at some other points:
However, a programmer has to go out of his way to make a computer aware of the date. False. Just use the system date - probably every program does this if nothing else than to print the date on a heading of a report. I know this would absolutely not cause a failure - it would diplay the wrong date. But programmer's can easily use the date. And all computers are "aware" of the date - it's built into the OS.
The programmer would never have a reason to give it that information. False. Never assume what a programmer would logically do. All of us in the "biz" have seen horrendous coding that makes no sense. If it can be done then somewhere it has been done. Nevermind if it makes sense or not.
Businesses may lose money because their reporting or billing is inaccurate, but that's hardly the end of the world. Here you again fail to see the big picture - the domino effect. If failures are widespread, it affects cash flow, which affects jobs, purchases, loan payments, etc., etc. cascading through the economy. It may not be the end of the world, but can pose serious long-term consequences.
Nobody builds critical systems like these without manual backup, for the simple reason that (like I said earlier) computer systems crash *every day.* True, but again it's a size and scope problem. How many and how intense and how frequent do these failures become in order to overwhelm the manual backup procedures? And don't try to pretend that these manual backups work flawlessly. They're out of practice and may not even be feasible depending on how out of date they are. We've all seen plenty of stories recently about situations (Y2K related or not) where the manual procedures were either not "doable" or took muck longer than planned. And what about manpower?
In any case, banking systems have been compliant for a long time because they've had to deal with loans that won't expire till after 2000 ever since 1970. Ironically, this is one fact that has always puzzled me. I'm not talking about this direct quote - we all know that's bogus (already compliant - then why are they spending $10 billion or whatever to fix it in 1995-1999). Anyway, I wonder wht they didn't "get it" and really do it long ago: 1970: "(IT staff) uhh, our 30 year mortgage program just blew up." "(Manager) well then fix it!" 1980: "uhh, our 20 year mortgage program blew up." "well then fix it!" 1985: "uhh, our 15 year mortgage program blew up." "well then fix it!" 1990: "uhh, our 10 year mortgage program blew up." "well then fix it!" "oh this looks like a regularly occurring thing. I mean I guess It'll keep happening every year." "(IT staff)uhh, yes it will" "well, we might as well fix everything since we'll need to do it over the next 10 years anyway."
Well, obviously that DID NOT happen, but for the life of me I can't figure out why. You'd think if any sector had advance warning it was the banking/finance sector, but they buried their heads in the sand like everyone else.
Anyway, back to the main point - the point that "Z" brought up is valid: What is the fault tolerence of the world system? And yes, it will be strained more than usual come 2000.
-- Jim (x@x.x), August 11, 1999.
King of Spain:I know that your question was addressed to Maria, but may I interject a few comments here?
You said: "Maria, is it then a fair statement that the "100% remediation completed by 12/31/98 with a FULL YEAR for testing" fantasy was, then, utter hogwash? I mean, I was always under the impression that it COULD have been done IF the remediation work had by some miracle been able to be completed last year."
First, I'll preface this "100% remediation completed" with my thoughts that just because one slapped the last of the fixes in doesn't constitute remediation complete. I suppose for some that definition was sufficient, but I assure you that definition does not "fly" for most companies. I'll also repeat something that I've posted elsewhere in time and space on this forum. Most companies are completing Y2k remediation piecemeal. It's simply NOT a "wait for it all to be done before installation" type of thing. We also have no idea how many programs remained unremediated at the end of 1998. It could be one, or it could be thousands, or it could be none. It could be that 99% of programs were remediated, tested, and moved into production, and there's something tricky about that last 1% that is holding up the "complete" status. We simply don't know.
I really don't know where Maria stated that systems completed in, say, 1995, would still be entering 2000 with complete wonderment as to what will happen. Did she say this? I know that I've seen systems remediated LONG before 1995 as part of other system changes. These programs are currently in production, but, despite extensive testing of the year 2000, I suppose there IS a chance that something was missed. Is this to what you referred?
You then said: "Somehow, that makes no sense whatsoever to me. Of course, I don't know much about satellites, either...."
I'm with you on the satellites, but I've researched them enough to know that either satellites are currently compliant or are due for a switch-out of one that is. The problem doesn't lie with the birds in the sky, but the systems on the ground to which they communicate.
-- Anita (spoonera@msn.com), August 11, 1999.
Anita, King, etc.<< But you are telling us ... that in fact even if remediation had completed in, say, 1995, we would still be entering 2000 with complete wonderment as to what will happen?>>
Well - yes, to a certain degree we would still be uncertain. BUT - there would be major differences: Let's pretend that today (Aug 1999) was August 1998 (or earlier) and that the paniced last minute re-programming efforts now going on were to just meet some bureacratic deadline - maybe the federal government said that every company had to be compliant or their contracts would be cancelled....
Therefore, there is no physical reason to expect anything to happen on Jan 01 1999 (today plus 5 months) - but the programs would still have to be fixed. Okay - the whole infrastucture impact is removed - that's one big plus. The "minor" troubles (subways, water, gas, overseas suppliers, elevators, switches, HVAC controllers, etc.) that are likely to be impacting recovery (fix-it) efforts next January and Feb. are eliminated.
Every remediated program would then have at _least_ 1 year (4 quarters) of regular routine operations during "1999" to work out errors and minor troubles. Every replaced program would have regular backups and regular sequencing of repair/maintenance/backup servicing using current files. All current files (pre-y2k-use into post-y2k-use) would have had a full year of outside agency data exchange; plus, every exchange would be "sloped" out over time with other customers to make errors easier to eliminate before "everything" got exchanged all-at-once.
So the programs would be tested in use, would be actually implemented into current and converted databases and used before the actual critical dates were ever met, and the search-and-eliminate function that is typical of process controls could be continued in running (installed) systems - so problems could be eliminated.
Now, all this assumes we would have 5 months to fix problems (Aug 1998-Dec 1998), then one year to use the changes and new systems (Jan 1999-Dec 1999), then get "tested" on the "real" date (Jan-Feb 2000) using new programs and systems that have been run successfully and are executing correctly on converted datasbases that have been verified (through use) as compatible with ALL client and government and vender databases.
___
Would this eliminate all troubles - no, not really. But it would be a hell of a lot simpler than what we have now. The y2k impact under that circumstance would actually be a 90% or 95% chance of being a mere "bump-in-the-road."
___
Instead - little has been tested, almost none exchanged with other databases (HCFA said less than 0.4% (4 out 1000!) medical services companies they are responsible for have tested their new records. And of those that did check their revisions, half had errors.
Everything will break (or not break) all at the same time - not a good time to troubleshoot and repair. Which increases the likelihood of errors.....
-- Robert A. Cook, PE (Kennesaw, GA) (cook.r@csaatl.com), August 11, 1999.
Robert:If you are not careful, you're going to start sounding as pessimistic as me. And you've got more professional experience to base it on.
Come on, guy. Can't we just borrow 100K from the bank or against our house, put it into internet stocks, and retire in December? We should have no worries then, right??? [G]
*sigh*
-- Jon Williamson (jwilliamson003@sprintmail.com), August 11, 1999.
Your highness, I never really address your questions but I'll say one thing. Look at the SEC report filed last year. Tell me how many companies said they would be finished 12/98. Further tell me how many said that they would be 100% complete by 12/98. The only reason I ask this is that I've seen you doomers make these statements (once again) based non-facts. As I recall, there were only a handful of companies stating 100% complete by 12/98. As I recall, the remaining companies stated completion by 6/99. But go find out the FACTS for yourself.
-- Maria (anon@ymous.com), August 11, 1999.
Maria,
By the time I got to your indignant denial of the authenticity of the "What does refute mean" post, I had already forgotten the chuckle I got out of said post. Now, I will forever wonder if someone named Maria really had her intellectual reputation compromised by a mischievious post, or did she, in fact, not know the definition of a simple word and upon seeing Brian post become embarrassed and fabricate a refutal (refutation, refutence...where's that dictionary!), as will everyone else who followed this entire thread.I just thought you should know.
-- Bokonon (bokonon@my-deja.com), August 12, 1999.