Gary's doom reviewgreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread |
Subject: The Y2K State of the Union as of July 30, 1999 Comment: It is time to present my summary of what is incontrovertibly true, with only five months to go. I shall low-ball my remarks, making them as close to unchallengeable as I can. These should be the starting points in any discussion of the impact of y2k in 2000, whether national or personal.I hereby grant the right of anyone to reprint all or a part of this list, so long as a link to this document is provided.
1. The number of companies in the world that have reported 100% compliance of all mission-critical systems, and 100% compliance of its vendors and suppliers, is zero. We do not have to raise the two issues of final, integrated testing and third-party verification until one such company appears.
2. Noncompliant data will corrupt compliant data when imported into compliant systems.
3. To screen out bad data, an organization must cut off or filter computerized communications with noncompliant computers. It must know which outside computers are noncompliant. It must presume that all of them are noncompliant until proven otherwise.
4. The larger the number of data exchanges, the greater the likelihood of a major failure (the Beach/Oleson pain index). The Federal Reserve System has 316,862 of these links to the outside.
5. When the cut-off of outside contacts takes place, no industry will remain compliant with all of its present producers. Bankruptcies will escalate.
6. There is no compliant industry today.
7. No major money center bank on earth is compliant.
8. No national government is compliant.
9. Two state governments in the U.S. have claimed compliance.
10. At least 19 of 21 large U.S. cities are noncompliant.
11. There is insufficient time to identify and replace all noncompliant embedded chips. The world has by default adopted "fix on failure."
12. Noncompliant 286 and 386 computers are still in use all over the world, sometimes in control systems.
13. No microcomputer can safely be assumed to be compliant. All of them must be tested. So must their software, especially spreadsheets. This has not been done, and the sale of y2k testing software so far has been minimal.
14. The U.S. train transportation system is not compliant.
15. Very few power generation companies have announced mission-critical compliance.
16. No large telephone company has announced full compliance.
17. Phones and electrical power plants are intertwined; the failure of one will bring down the other.
18. Public water/sewer systems are not compliant, all over the world.
19. The chemical industry is way behind.
20. Chemicals are basic to manufacturing, and also to the treatment of drinking water.
21. Diesel and gasoline are chemicals.
22. No oil exporting country is compliant. The U.S. imports over half of its oil.
23. General Motors has 2 billion lines of code and 100,000 suppliers.
24. If a component is missing on an assembly line, the line must be shut down. (Example: the 1998 strike of GM's 9,200 new parts plant employees, which led to the temporary layoffs of over 100,000 other GM employees.)
25. Parts wear out. This includes turbines in power plants.
26. The typical large city power plant has 5,000 suppliers.
27. If a company sells to noncompliant companies, it will suffer a reduction of orders in 2000.
28. The division of labor is international.
29. Capital flows are computerized.
30. Most of the world's capital is digital.
31. Russia is sitting on top of a huge nuclear arsenal that will become unpredictable on January 1.
32. The health care industry is considered to be very far behind in every nation.
33. Public health systems are today not at the top of most politicians' "must fund" list. These low-visibility programs have no politically significant constituents. It will take a public health disaster to gain such constituents.
34. Although Medicare (HCFA) now claims 100% compliance, none of the 70 companies that provide the HCFA with its administrative services has announced compliance.
35. Although the FAA claims 100% compliance, only one major airport has: Atlanta.
36. If commercial aircraft cannot legally fly, their owners cannot meet their bank payments.
37. The FDIC's bank insurance program is not compliant.
38. The FDIC has $1.40 for every $100 in insured deposits, and 80% of this money is invested in U.S. government debt.
39. If most banks are closed, the U.S. government cannot collect revenues by check to fund this debt, which means the FDIC cannot get paid, which means that the banks will remain closed.
40. The Internal Revenue Service is not compliant.
41. The U.S. Treasury Department is not compliant.
42. The U.S. Department of Defense is not compliant.
43. The U.S. Navy defends Taiwan.
44. Taiwan has just declared unilaterally the end of the 50-year "one China" policy, which is basic to Communist China's foreign policy.
45. We import most of our microcomputer chips from Taiwan.
46. Germany is behind France.
47. Italy? What can I say? It got started on y2k this year.
48. For every $100 in U.S. bank deposits there is less than $1.20 in currency reserves in bank vaults.
49. There is about $6 trillion in electronic U.S. money (M-3).
50. There is about $525 billion in currency outside of banks, of which some two-thirds is believed to be outside the U.S.
51. The Federal Reserve System says it has $150 billion in currency and another $50 billion coming by December. Banks must either sell assets to buy this currency or borrow from the FED, thereby reducing their capital/assets ratio.
52. The Bureau of Engraving and Printing is at maximum capacity now just to replace old currency.
53. The Crane Corp. has had a monopoly on manufacturing paper for U.S. currency since 1879, so no great increase in output can be expected by December.
54. If there are no small bills to make change, the fast food industry will go bankrupt. But to maximize the value of the currency supply, the Federal Reserve System must issue large-denomination bills. It has not said what the ratio is for the newly printed bills' denominations.
55. No major brokerage company has announced compliance.
56. The international bank wire transfer system is not compliant.
Gary North
-- zoobie (zoobiezoob@yahoo.com), July 30, 1999
You forgot to provide the link he requested:
href:http://www.garynorth.com/y2k/detail_.cfm/5614
-- Forrest Covington (theforrest@mindspring.com), July 30, 1999.
For the HTML challenged, how does one turn it into a a 'hotlink'?
-- K. Stevens (kstevens@It's ALL going away in January.com), July 30, 1999.
MORE IMPORTANTLY, can *anyone* refute, reliably, any of his points. please do so, if possible, by point number and with backup data.thank you!
-- Cowardly Lion (cl0001@hotmail.com), July 30, 1999.
is this a reality-check??? if-I SAY IF GOD allows this to happen,what,s the lesson???
-- reality??? (dogs@zianet.com), July 30, 1999.
Back up data?? You mean just like Scary Gary?? I see he backed up his findings real well.........Half of that shit is way off and yall know it.
Just ask me, I'll tell ya.......
Deano
-- Deano (deano@luvthebeach.com), July 30, 1999.
Cowardly Lion, You're on!
#12...286 and 386 based embeddeds...I hold in my hand ( I'm hunting and pecking with my other hand) a 286 based motherboard with TWO (count 'em) REAL TIME CLOCKS! There is NO manufacturer's logo on the board...some of the chips are unmarked. Without that DELTA T PROBE out of England (www.embedded- science.com)i wouldn't stand a prayer of remediating it.
By the way, this motherboard came into my possession as an underground upgrade to a nonworking XT Clone. The hardware wienee who built it for me got it at one of those vast underground grey markets in used computer parts.
One can only speculate what application requires TWO real time clocks...Perhaps where the SCADA system must keep PRECISE records of events and dual time stamps are required for archiving??
-- K. Stevens (kstevens@It's ALL going away in January.com), July 30, 1999.
Al,don't you know that god is a myth made up so you can sleep better at nite?No santa claus,either.
-- mike (mike@wal-mart.com), July 30, 1999.
Computers the final piece of 'forbidden fruit' offered to mankind, to 'make them like God?' An apple with a bite out of it? Eve with her salacious smile. Yes. Yes.
-- John Apple (Landonod@ezra.calm), July 30, 1999.
This is exactly what we've been trying to say. What response to the pollys have?? None.Everythings going down hard, and there's very little possiblity that it will ever come back up. Are you prepared??
-- (its@coming.soon), July 30, 1999.
Yep the pollys are noticably silent on this one. In 154 days we are all going to show up on Gary's doorstep to share recipies, and shoot the pollys, then they will see.
-- Bahahwhawa (hehe@haha.hoho), July 30, 1999.
its@coming.soon says "Everythings going down hard, and there's very little possiblity that it will ever come back up. Are you prepared??"If you... or anyone else that thinks (as I do) that it is going down hard wants a little summer reading to go along with your prep time, may I recommend "Spritwalker...Messages From the Future" by Hank Wesselman. Its not for everyone. I describe it as Carlos Castaneda without drugs. I read it a few years ago and am rereading it in light of Y2K. email me if you want more info.. or I could post it if there is interest.
-- Linda (lwmb@psln.com), July 30, 1999.
href:http:// www.garynorth.com/y2k/detail_.cfm/5614
-- Ct Vronsky (vronsky@anna.com), July 30, 1999.
At the academic institution where I work everyone talks about moving into our newly refurbished offices... Next year. I just nod & think, Will any of it actually happen?With every pessimistic article I read it seems less & less likely that this institute will even be open & operating in 6-7 months. And yet every single person around me is completely, totally oblivious.
This is all so weird. Hey, isn't that Rod Serling over there...?
-- welcome to (the@twilight.zone), July 30, 1999.
http://www.garyno rth.com/y2k/detail_.cfm/5614
-- Ct Vronsky (vronsky@anna.com), July 30, 1999.
-- Bahahwhawa (hehe@haha.hoho commented:"Yep the pollys are noticably silent on this one. In 154 days we are all going to show up on Gary's doorstep to share recipies, and shoot the pollys, then they will see. "
Yes, the intelligent pollies are quiet, but there was ONE DOLT who did respond. Sir, would you care to stand up??
Ray
-- Ray (ray@totacc.com), July 30, 1999.
Linda, PLEASE post the Spiritwalker stuff. I'm interested. Start a new thread & damn the trolls. Thanks in advance.
-- persistant cookie (in@my.browser), July 30, 1999.
K. Stevensare you refuting #12 or agreeing with it? i'm looking for refutation, not the opposite.
-- Cowardly Lion (cl0001@hotmail.com), July 30, 1999.
Too late, Ray. He's left for the beach.
-- King of Spain (madrid@aol.com), July 30, 1999.
Do you really want this taken apart one brick at a time? Or can you spot the overstatements, the logic flaws (proving the negative), etc? I'm already behind on my economics of the Great Depression post. (sigh)Regards,
-- Mr. Decker (kcdecker@worldnet.att.net), July 30, 1999.
And to the dolt,,,,,,,, This info has been gatherd from NEWS reports,,, or the lack there of, it is NOT the PR FLAK you hear everyday.
-- FLAME AWAY (BLehman202@aol.com), July 30, 1999.
Ray sez:Yes, the intelligent pollies are quiet,
Sorry, no such thing as "intelligent pollies"
-- (its@coming.soon), July 30, 1999.
Lion, you said:"MORE IMPORTANTLY, can *anyone* refute, reliably, any of his points. please do so, if possible, by point number and with backup data."
We'll start at the top and work on a few at a time.
"1. The number of companies in the world that have reported 100% compliance of all mission-critical systems, and 100% compliance of its vendors and suppliers, is zero. We do not have to raise the two issues of final, integrated testing and third-party verification until one such company appears. "
Duh! Since no company could claim that all of it's vendors and suppliers are compliant, this statement is nonsense. How can a company reliably claim much of anything about systems not under their control? They can't and even a cursory amount of thought tells you that.
"2. Noncompliant data will corrupt compliant data when imported into compliant systems."
Maybe, but not necessarily. It depends on the format of the data and on the destination system. If my compliant system wants dates formatted with 4-digit centuries and you send me dates with 2-digit centuries, my system will reject your data out of hand based on format. No corruption there.
"3. To screen out bad data, an organization must cut off or filter computerized communications with noncompliant computers. It must know which outside computers are noncompliant. It must presume that all of them are noncompliant until proven otherwise. "
Well, that's the easy way to do it, but there are ways to filter out the bad data without cutting yourself off from the world. For instance, if you are still getting 2-digit dates in your data feed, you can "window" the in-bound data and then do some sort of reasonableness check on the result. If you window the data and you find that all your dates are 99 years in the future, you can reject that information for most applications. Dates falling into the current year might be acceptable.
"4. The larger the number of data exchanges, the greater the likelihood of a major failure (the Beach/Oleson pain index). The Federal Reserve System has 316,862 of these links to the outside."
True, but then the organizations with higher numbers of exchanges are more likely to have higher numbers of people working to solve the problems.
"5. When the cut-off of outside contacts takes place, no industry will remain compliant with all of its present producers. Bankruptcies will escalate. "
Huh? What the hell does "no industry will remain compliant with all of its present producers" mean? It's a nonsensical statement. Also, North assumes that there will be a cut-off of outside data transfers taking place, and that is most certainly not a given. Furthermore, when he starts talking about how an entire industry will or won't be compliant he is really stretching things. Just because my competitior isn't handling things well doens't mean I'm not. If Lubbock Power And Light (the supplier where I grew up) has problems, it doesn't mean that Massachusetts Electirc (my current supplier) isn't on-line and functioning. Get a grip, Gary.
More later.
-- Paul Neuhardt (neuhardt@ultranet.com), July 30, 1999.
Good response there. "Maybe, not necessarily" "It depends". Could you waffle a little more? I'm still hungry.
-- (its@coming.soon), July 30, 1999.
Paul N: Without meaning to, you have essentially VERIFIED every assertion made by North, except for the last. My interpretation is that North is making the case that IN PRACTICE you simply cannot "cut off" your vendors and suppliers, anymore than you can "screen out" bad data from your electronic interfaces. And the reality is that North DOES HAVE a grip, whereas you seem to completely be clueless of the SIGNIFICANCE of it being practically August 1999, and the world so woefully unprepared for what is coming.
Decker: Yes indeedee, we are all very much looking forward to your rebuttal of "a"'s points. LOL (already)!
-- King of Spain (madrid@aol.com), July 30, 1999.
King:"My interpretation is that North is making the case that IN PRACTICE you simply cannot "cut off" your vendors and suppliers, anymore than you can "screen out" bad data from your electronic interfaces."
You only got half of my point. True, you will have a hard time staying in business if you have to cut-off all contact with your suppliers and vendors for very long. However, there are in fact ways to screen out bad data from electronic interfaces. I briefly and overly simplisticly described such a way in my post.
"And the reality is that North DOES HAVE a grip, whereas you seem to completely be clueless of the SIGNIFICANCE of it being practically August 1999, and the world so woefully unprepared for what is coming."
There's that difference of opinion again. I'm not convinced that the world is "woefully unprepared." When you think about it, that's the whole point of this discussion, isn't it? You accept "woefully unprepard" as a given and I do not.
-- Paul Neuhardt (neuhardt@ultranet.com), July 30, 1999.
Wow -- maybe thats why you are a polly and I am a doomer! How wonderful it is to understand our differences....
You CANNOT reliably screen out bad data. You can certainly reject data that fails to satisfy gross validation criteria -- such as a date in the form YYMMDD rather than YYYYDDMM -- but the data that I am talking about (and North too, I would guess) is not so obvious. Take, for instance, the following: 0004980721, which represents $49,807.21. There is NOTHING wrong with the way its formatted. But, unbeknownst to you (and your computer), the computer that generated this value did so ERRONEOUSLY because it has a Y2K bug. The REAL amount should be $79.26. There is NO WAY to screen this out. Obviously!
But I am so glad that we got to talk about our different points of view. I feel so much better for it....
-- King of Spain (madrid@aol.com), July 30, 1999.
King,Thank you for explaining this for the dolts on this forum WHO STILL BELIEVE thet IMPORTED CORRUPT DATA IS A F#$%ING MYTH!!!
Brain dead, the lot of them!
Double-decker, don't worry, we're not holding our breath.
Mr. Neuhardt, you are naieve in the EXTREME sir!
-- Andy (2000EOD@prodigy.net), July 30, 1999.
And BEANO,you continue to prove that your card-carrying cretin status is still intact.
-- Andy (2000EOD@prodigy.net), July 30, 1999.
I'm sure, your Highness merely overlooked explaining exactly how date logic generated $49,807.21 instead of $79.26, all without being caught. Right? You were going to explain this minor detail, for all us slow-thinking polly's. Right?
-- Hoffmeister (hoff_meister@deja.com), July 30, 1999.
Paul Neuhardt apparently doesn't want to deal with the fact that incoming data can be correctly formatted but still be totally erroneous due to y2k problems in the exporting system. The importing system will accept the bad data, not knowing it's corrupt, and start processing it, thereby compounding the errors geometrically. This happens from time to time anyway. The difference with Y2K is that this will happen to thousands of systems simultaneously worldwide, far beyond any workaround capability. This is why Alan Greenspan said the banking system must have 100% compliance; 99% won't do. Of course he forgot to mention the banks in the rest of the world that interchange data with US banks constantly. Things are going to be very different for all of us this time next year.
-- cody varian (cody@y2ksurvive.com), July 30, 1999.
Every survey and/or analysis I've seen (and there are many of them) indicates that the rest of the world is woefully unprepared for y2k, despite Neuhardt's refusal to see the plain truth. Denial is very strong.
-- cody varian (cody@y2ksurvive.com), July 30, 1999.
Hoffy,YOU of all people know damn well how the process would work - cody has explained it in a nutshell...
but just to humour the brewmaster...
"I'm sure, your Highness merely overlooked explaining exactly how date logic generated $49,807.21 instead of $79.26, all without being caught. Right? You were going to explain this minor detail, for all us slow-thinking polly's. Right?"
Faulty date-arithmetic code can have unexpected results, right?
The faulty code for example was supposed to issue a debit or credit, take your pick, of 49 grand.
Instead it generated a debit or credit of just 79 smackeroos, right?
The credit, lets call it a credit shall we Hoff?, sent 79 bucks to make a payment to prevent a house foreclosure. The receiving bank gratefully accepted the funds, after all EDI parameters and checks were passsed with flying colours, SWIFT did it's job (ha!), and all was well with the world.
EXCEPT
The house was foreclosed on - the requisite funds after all didn't make it, right?
Multiply this scenario worldwide, an veritable tsunami of apparently benign (but ultimately fatal) errors that would normally be caught quickly and manually fixed by the back-office staff -
EXCEPT
The volume will be staggering, a bank receiving incoming data will IN NO WAY be able to tell whether the data is accurate or not (providing the EDI protocols and parameters are met) - and will process the invalid data regardless.
Now any moron can grasp the fact that we now have a serious problem here.
Apparently you can't HoffMeister.
So WHY WHY WHY keep asking dumb fucking questions???????
-- Andy (2000EOD@prodigy.net), July 31, 1999.
And before nits are picked Hoff, yes I transposed the amounts - doesn't matter - it will be a shambles at rollover. Of course we can always ISOLATE the 78% of banks worldwide that are self-professedly NONCOMPLIANT.
-- Andy (2000EOD@prodigy.net), July 31, 1999.
"However, there are in fact ways to screen out bad data from electronic interfaces"Hey, I have a question!!! What are we going to do with this "screened out bad data?" Send it back? Print it, and deal with it manually? Throw it out? Save it for later? Maybe we can "window" it?
Come on folks, what is Y2K about?
Duh? <:)=
-- Sysman (y2kboard@yahoo.com), July 31, 1999.
EXACTOMUNDO Sysman!!!Just read this TOSH written by Mr. Neuhardt...
"If my compliant system wants dates formatted with 4-digit centuries and you send me dates with 2-digit centuries, my system will reject your data out of hand based on format. No corruption there.
"3. To screen out bad data, an organization must cut off or filter computerized communications with noncompliant computers. It must know which outside computers are noncompliant. It must presume that all of them are noncompliant until proven otherwise. "
Well, that's the easy way to do it, but there are ways to filter out the bad data without cutting yourself off from the world. For instance, if you are still getting 2-digit dates in your data feed, you can "window" the in-bound data and then do some sort of reasonableness check on the result. . Dates falling into the If you window the data and you find that all your dates are 99 years in the future, you can reject that information for most applicationscurrent year might be acceptable."
Sooooo, according to Mr. Neuhardt, 78% of the worlds banks will be following his expert advice and...
"my system will reject your data out of hand based on format. No corruption there."
and...
"If you window the data and you find that all your dates are 99 years in the future, you can reject that information for most applications..."
Soooo...
WHUP-EEE-DOOOO
we now have 78% of the worlds banks rejecting all and sundry incoming dodgy data...
what does that gives us???
NO BANKING SYSTEM - you cannot have a banking "system" when four fifths of the instituations are constatntly rejecting data and declining transactions...
complete bollocks Mr. Neuhardt!!!
-- Andy (2000EOD@prodigy.net), July 31, 1999.
Andy:Here's what you seem to be saying here (correct me if I'm wrong):
1) If bad data are generated in such as way as to pass all of the many acceptance criteria and get into the system, we have problems.
2) If bad data fail to meet these criteria, but the *rate* at which such bad data are generated is too high (and so the rejection rate is too high), we have problems.
3) Date handling errors will lead to both problems, sometimes generating 'acceptable' bad data, and sometimes garbling so many transactions as to cripple the transaction system itself.
4) It is in the very nature of date bugs that both kinds of errors will naturally result during normal transaction processing (on both ends).
5) The fact that such errors have reportedly NOT shown up despite massive testing of both normal and worst-case data sets can be explained by: (a) Such reports of testing are all (or mostly) lies; (b) Those who created the tests didn't understand what they were doing; (c) The major problems will be caused by those who didn't participate in the tests; (d) The tests actually failed, but we only read about the few that passed; (3) something else.
Is that about right?
----------
Underlying almost all of North's "incontrovertible facts" is the assumption that any noncompliance now will result in total failure and complete inability to function later. In other words, the all-or- nothing position, that anyone not 100% healthy is 100% dead.
Let's say the phone company, because of noncompliance, generates 20% more incorrect bills than normal. This is certainly a "failure". Is it reasonable to conclude that the utilities will be unable to generate and distribute power as a result? North thinks so.
I typically work on projects with one or two other engineers. We are all "nonhealthy" in North's sense. I wear glasses. Another guy is too fat. The third is bald. How does all this "nonhealth" interact to prevent us from doing our job? About the same as how North's "noncompliance" makes systems nonfunctional -- it's irrelevant. Not every "failure" is created equal, but North sets them equal.
North's logic is basically: 5 is a number. 17 is also a number. Therefore they are both numbers. Therefore they are the same. Therefore 5=17. North is relying on people to miss this little error, and several responses here show that North understands the logical skills of his audience.
-- Flint (flintc@mindspring.com), July 31, 1999.
In a nut shell.Y2K is systemic.
Is it malignant?
We shall see. We shall see.
My preps are done.
I am enjoying the rest of the year.
All bets are off for next year.
My level of concern has gone way down. Preps complete.
Polly, do you feel lucky? I sense some creeping anxiety in the polly posts recently.
Just a little nervous about your investments?
Just a twinge of angst?
You pollies have to admit, this event is unprecedented. You have to admit that "the other guys will suffer." We are ok, but Russia, China, Latin America, Eastern Europe, Africa, Middle East, parts of western Europe (i.e. Italy - got olive oil?).
Repeat after me.
Everything is going to be OK
Everything is going to be OK
Everything is going to be OK
Everything is GOING TO BE OK!
-- Y2K-OK (happy@risperdane.com), July 31, 1999.
Hello Flint,I agree. North understands his audience and knows his faithful will not press too hard. One of the most glaring errors--North presupposes the "system" has to work perfectly. Experience tells us businesses fail every year:
"The number of businesses that failed in 1997 increased from 71,931 in 1996 to 83,384 in 1997, an increase of 15.9 percent. Even with this modest increase, the failure rate (failures per 10,000 listed concerns) remained subdued at 88."
http://www.dnbeconomics.com/bfr96_97-text.htm
Now, how can any firm "certify" none of its business partners will fail during a given year? North would have us believe any business that does not claim compliance is, in fact, noncompliant. (Let's skip the whole argument about what compliance is.) If you use North's logic, all the businesses that do not assert they will exist next year will fail. North also ignores the fact errors happen every day in electronic transactions. An error does not necessarily crash the system. If this were the case, nothing would work.
Regards,
-- Mr. Decker (kcdecker@worldnet.att.net), July 31, 1999.
http://year2000.dci.com/Articles/y2k99075.htm"With less than half a year to go, many businesses and organizations are tying up their Y2K compliance programs, and many have already achieved compliance. Unfortunately, there are many more who havent.
Beware of Data Exchanges
Thousands of gigabytes of information flow freely back and forth each minute through cleverly created chains of networked computers that may be located thousands of miles apart. In a matter of seconds, data is [sic]transmitted from one computer to another and if the dreaded Millennium Bug happens to be lurking somewhere inside just one of these computers it will make its way, together with the data, right down the rest of the network. With less than six months to go for the turn of the millennium, many organizations claim to have already attained the Holy Grail of Nineties computing complete Year 2000 compliance. Still more say they are well on their way. So whats the problem? In two words: data exchange. With regard to achieving Y2K compliance, todays technological world is divided into two segments the haves and the have nots. Multiple layers of interdependent systems increases the potential for Y2K glitches. When the clock strikes midnight on 31 December 1999, not all computer systems will have achieved the same compliance standards they will all be stop-clocked at varying levels of preparedness. As they continue to share information in the new millennium, the laggards could pull the leaders down with them. Y2K experts predict that data exchange issues will be a major source of Y2K worry for organizations dealing with the date change. Mary Reynolds, Chief Technology Officer for the state of Illinois, opines that even the best of compliance efforts could be hurt by faulty data or Y2K-related failures in external systems. Some systems are completely dependent on the quality of data they get from other systems, she says. The real issue and real difficulty in predicting the impact of Y2K will really be those [data] exchanges. Take, for example, government information systems. Many of these systems share data across numerous federal and state jurisdictions, including the records that make up our day-to-day dealings with government and affect everyday life. The smooth operation of the many federal programs with which we are all familiar -- Medicare, Medicaid, child support and unemployment insurance, for example -- is dependent on an uninterrupted and accurate electronic exchange of data between states and the federal government. A breakdown anywhere in the system could be disastrous.
An Office of Management and Budget report released earlier this year caught several federal agencies napping, including the Health Care Financing Administration, which provides health coverage for approximately 74 million Americans nationwide. The OMB's latest quarterly report on the Y2K problem says 93 percent of the government's 6,190 most important computers have been repaired, replaced or never were vulnerable. Of the 410 computer systems government-wide that aren't ready, most are being repaired. The report states that 35 computer systems are being replaced and 24 are being scrapped. Only 14 federal agencies were able to say that all of their most important computers were prepared. Analysts warn that these levels of progress could spell trouble. Its no longer somebody elses problem, says Mark Leese, an independent Y2K consultant. Somebody elses problem could soon turn out to be yours. The pollys in this thread are most likely one of the following (98.2% accuracy):
(1) students (or the otherwise underemployed) with too much time and computer access on their hands, living off daddy and mommy (and don't have to meet payroll, much less file a W2);
(2) W-2'ers who never had to meet payroll,otherwise they would know the 10-q and 1099 IRS electronic reporting requirements requirements [you _do_ know what the IRS says about windowing don't you, Big Brain?]
(3) Independent contractors who never had responsibility for the payroll and well-being of their employees (what are the contingency plans for paying one's employees in the first quarter of calendar year 2000?)
(4) Pampered pets (remeber George Bush never seeing a laser reader at a grocery store?) who have never had to swipe a credit card reader for a living, or call a credit card company for confirmation (you _do_ know the readers are _not compliant_ unless upgraded forUS$ (---but of course, _you_ know how much these data exchange upgrades cost, being such Big Brains...).
The other 1.8%? Good luck. Hope you can meet payroll February 29, 2000.
Nelson
-- Nelson Isada (isada@alaska.net), July 31, 1999.
I know, I should expect this by now. But, optimist that I am, I keep expecting that, with all these man-years of programming on this forum, and as often as this topic is brought up, that someone has actually seen an example.Truly, Andy, just what date-arithmetic error is going to change a transfer amount from 49 odd thousand dollars to 79 dollars? And be pervasive enough to overwhelm the system? We can at least start with the first, if you like, then move on to the second.
-- Hoffmeister (hoff_meister@my-deja.com), July 31, 1999.
Thanks Nelson, data exchange appears to be one of the BIG unknows with regard to the seriousness of y2k. You have given it some perspective.Hoff, please take a peek at Nelson's four (4) categories and let us know where you fit in best !!
Ray
-- Ray (ray@totacc.com), July 31, 1999.
Hoffmeister, have you ever heard of a programming condition known as an array overflow? Specifically, if I have an array A[1] .. A[n], and due to an indexing error, end up effectively accessing some element A[k], where k is larger than n, this certainly could result in a very different value than what should be.
Like Andy, I am amazed that this should even be a question as far as its validity as a Y2K concern. Believe me, when it comes to being able to discern "reasonable" values versus "non-reasonable" values, The Computer is very stupid here.
Remember: Y2K will cause failures in "weird and wonderous" ways.
-- Jack (jsprat@eld.net), July 31, 1999.
Mr. Decker writes: "Experience tells us businesses fail every year."This is true and one can wax philosophical and cite statistics of small business failure, unless it's _your_ employer and your children and/or in/significant other is wondering why you are in such a bad mood.
Examining the posts: the flints, maria's, etc are most likely independent contractor-types (type 3); doomers@suck.com is most likely a type 1, possibly living at home or off a student loan cosigned by daddy/mommy; the remainder are type 2 WIMPS (Where Is My Paycheck).
To the type 5's (not classified on previous the post): if you're waiting for the 7 or 8 figure business buyout (we got a 7 figure offer, but were 1.5 million apart with too many strings), will your capital source (undoubtedly backed by Orange County-style derivatives and heavily leveraged a la LTCM) still have equity to make you a cash offer next year?
Nelson
-- Nelson Isada (isada@alaska.net), July 31, 1999.
Jack, invalid data is always a concern. And it happens all the time.No, the point is just how does date-arithmetic expand these to the point of collapsing the system?
Also, per your example, most languages and systems I've dealt with will abend on the condition you describe above. My COBOL is old, but I believe it does as well. I seem to remember older versions of COBOL accepting an array pointer of -1, but I think that went away as well.
-- Hoffmeister (hoff_meister@my-deja.com), July 31, 1999.
"invalid data is always a concern. And it happens all the time."Get serious will ya Hoff. Yes, that's why we write "edit" programs, to do things like validate dates, make sure numeric fields really have numbers, verify that Y or N type fields dont have an X, and usually do some kind of "batch balance" for financial type transactions. And yes, some transactions are rejected all the time.
But if you're doing alot of EDI with your vendors and suppliers, what happens when you start kicking out ALL the transactions from a vendor, or 3 vendors, or 10 vendors? Do you wait for them to fix it? Do you "fix" your edit program?
It doesn't matter if you have a perfect edit program, that lets only perfect data into "your" system. What are you going to do with the "bad" data? How much can you deal with, and how are you going to deal with it?
Boy, I sure hope everyone is testing really hard... <:)=
-- Sysman (y2kboard@yahoo.com), July 31, 1999.
orget it Sysman, with Hoff and Co. it's like talking to , well, Hoff and Co. :)Flint,
"5) The fact that such errors have reportedly NOT shown up despite massive testing of both normal and worst-case data sets can be explained by: (a) Such reports of testing are all (or mostly) lies; (b) Those who created the tests didn't understand what they were doing; (c) The major problems will be caused by those who didn't participate in the tests; (d) The tests actually failed, but we only read about the few that passed; (3) something else.
Is that about right?"
The banking system has NEVER been tested.
It WILL be tested at rollover.
78% of banks worldwide are not compliant.
22% self-report that they are (!).
Work it out for yourself, this IS GETTING REALLY OLD.
Thanks jack and Nelson for your perspectives - I give up with Hoff, he's still convinced that date-arithmetic code will work like clockwork, WORLDWIDE, in EVERY BANK, at rollover.
Dear oh fucking dear.
-- Andy (2000EOD@prodigy.net), July 31, 1999.
Sysman:I don't think anyone questions that IF the incidence of 'bad' data becomes high enough, the system is crippled whether or not these bad data are trapped properly. Granted, the *symptoms* change depending on the quality of the data filters, but in both cases we have business far from usual.
Hoffmeister's question is, *how* will date bugs act to generate these bad data? Thus far, testing has failed to unearth any systemic mechanism(s) to cause this. For this, we need real-life examples, not largely speculative possibilities like invalid array processing. Have you seen (in your experience) errors that (1) are likely to cause wholesale bad data to be transmitted; (2) won't cause the error- generating systems to crash first; and (3) cannot be tracked down and fixed (i.e. design issues) within a reasonable amount of time? Real code samples would be very helpful here.
I admit my concern is at a more abstract level. My concern is, will such problems (if they exist) be common enough to cause domino-type interactions? Surely we have by now moved past dire speculations as to what might happen, and have reached the point where we can point to cases that will happen?
Gary North is still producing laundry lists of organizations that have not yet declared themselves compliant (whatever 'compliant' means, and whatever such declarations mean). Fine, I concede that nobody is (or will be) fully compliant, declaration or not. The important question is, what will be the impact of these noncompliances? We can all have fun concocting scenarios based on the assumptions that organization X vanishes from the face of the Earth, and cannot be functionally replaced before it's too late. But fun or not, such worst-case assumptions aren't realistic (much as North implies otherwise).
-- Flint (flintc@mindspring.com), July 31, 1999.
Hoffmeister, there is a lot of old, old code out there. Much of it was written when the God Of Efficiency ruled, and run-time checking of array bounds was a luxury that could not be afforded -- the code to perform such run-time checking was never generated by the compilers. (Well, "table" bounds, if you are a COBOLer.) Indeed, accessing storage with a bad index may result in an immediate abend, if for instance the value is not legit for the instruction (e.g., you try to manipulate a floating-point representation as some other entity); or, it may simply cause the program to produce results that are weird and wonderous. Which is why I don't believe that King of Spain's example above is at all implausible.
Are we at least now in agreement that bad data can "infect" good systems, with "data screening" not possible? In which case, can we agree that the issues now boil down to the likelihood and frequency of occurrence that Y2K will bring for these problems?
-- Jack (jsprat@eld.net), July 31, 1999.
Well, Jack, I'd take issue with your choice of terms, like "infect". There also seems to be a misconception that this "infection" somehow spreads, like a computer virus. This especially, has not been demonstrated.But, I've always agreed that bad data can be transmitted. This was never the issue. Data screening takes many forms, up to and including human review of transactions. But yes, invalid data is passed. The question is, what types of date-related failures would cause such a large increase in occurrence, to overwhelm the existing mechanisms and systems.
-- Hoffmeister (hoff_meister@my-deja.com), July 31, 1999.