>>Our findings in our Reality Glitch Algorithm, and the understanding-intelligence under the hood, allows us to confidently suggest a massive onslaught of data-related Y2K problems to occur beginning January 28th through February 4th of this year. The ability to effectively collect and analyze Y2k problems may be compromised due to the shear volume of global events. (note: one of our analysts repeatedly uses the phrase "biblical proportions"... we'll see)<<

[Comment: The idea is that, according to their chart based upon the number and severity of glitches thus far (and upon a compounding or snowballing effect), the time frame indicated would be when a crescendo or critical mass is projected to occur. Most information now, seems to say the same. But this is the only attempt to take raw data and crunch the numbers, past and present, to arrive at some kind of plain, observable conclusion.]

[Go to this sight for chart and some further explanation: http://www.ciaosystems.com/glitchcentral.htm]

[This is the main site this originated from. An excellent source of current glitch information: http://www.wild2k.com/]

-- Patrick Lastella (Lastella1@aol.com), January 12, 2000

Answers

It's yibble. Glitches? What information seems missing? The denominator, for one thing. How many "systems" are there that could potentially "fail"? No good reporting failures if you have no idea what these are a sample of. Also no idea what the baseline failure rate is. And these things are all reported by various interested parties in a more or less nonstandardized way. The evidentiary value of the glitch site is not large; it is compromised further because it is _another_ doom prediction. There's not much of a market for Y2K doom predictions nowdays. Why not disregard it?

-- Travis Porco (tcporco@transbay.net), January 12, 2000.

Statistical analysis was never my strong suit, but maybe the author of this graph could share a little more data that leads to this conclusion.

-- snooze button (alarmclock_2000@yahoo.com), January 13, 2000.

I don't think you need an algorithm or statistical analysis to know that there will be a lot of errors popping up at the end of the month. That time period is when a lot of payments come due, and new calculations are processed. It could get worse at the end of each passing month too, as previous errors get incorporated into new calculations. Some organizations might be able to stay ahead of it, but there will be some who will get caught playing a game of catch up that might never get out of it.

-- Hawk (flyin@high.again), January 13, 2000.

I'm not getting rude here, but does anyone remember that ancient old acronym, GIGO ? (garbage in garbage out)

How do we know where the raw stuff came from? "....findings...Allow you to confidently suggest...massive onslaught, biblical proportions..."

and the very word ciao means hello/goodbye - ? which are we bidding our systems? (Man! I just ate another can of my special Y2K Progresso Lentil soup today - really!!!)

You gotta' admit, though, Reality Glitch Algorithm would be a great name for a kid...hahaha

-- Ric (ice163@worldnet.att.net), January 13, 2000.

>>Our findings in our Reality Glitch Algorithm>>

And what, exactly, is this algorithm? The chart appears to show over 800 "events" and his list has fewer than 100. I'm more than a little sceptical.

Jim

-- Jim Cooke (JJCooke@yahoo.com), January 13, 2000.

I think the best approach is for everyone on this forum to post every glitch of which they know, large or small, so we can get a sense of the denominator, and also decide for ourselves what is and is not Y2K. Keep those glitch posts coming!!

-- Imso (happy@prepped.com), January 13, 2000.

You gotta' admit, though, Reality Glitch Algorithm would be a great name for a kid...hahaha

Ric,

lol, Reality Glitch Algorithm maybe, FRED no way!

;-)

-- Deborah (infowars@yahoo.com), January 13, 2000.

Glitch posts alone aren't enough. You need to know how many systems *aren't* having glitches; monitoring a representative cross-sectional sample (good luck finding one) of "systems" would be a start. You also need _clearly defined_ criteria (defined in _advance_) of what constitutes a "y2k glitch". And an idea of the base rates. Otherwise this is all self-selected, self-fulfilling prophecy, autocatalytic stuff that does not help.
As an example of what the problem is, consider this: What good would it do to say that there were "dozens of cases" of cancer during a certain year? In a town of 100 people this is a big deal; in a large nation this would constitute an infinitesimal fraction of the total. Then what kind of cancer is it, and what is the base rate, say over the last few years?
Now suppose instead of "cancer" being reported say, you have cases of "illness" being reported by various interested parties, with no clear definition of illness. (Give people a placebo, and a surprisingly large fraction will report all kinds of side effects. Sometimes we just don't feel good.) Then add in a panic of some kind, and a self-reinforcing panic frenzy results as surely as night follows day.
Of course, merely being poorly documented and unconvincing alone does not prove there is no problem. However, the sort of thing I saw at the glitch site is completely unconvincing, especially bearing in mind that a series of Y2K disaster predictions have gone unfulfilled--leading to a critical loss of credibility in classic "boy who cried 'wolf'" style.

-- Travis Porco (tcporco@transbay.net), January 13, 2000.

I won't speculate about embedded chip problems because there are too many unknowns to predict the kind of random failures that could occur. But with respect to software systems, here is one of the very real dangers that could occur with data corruption. I think it is safe to assume that some organizations utilize data processes which produce two or more pieces of data from any one original data record. Given the possibility that an error can be generated in any original data record, the subsequent data then becomes corrupted at an exponential rate (1, 2, 4, 8, 16, 32, 64,...), as seen here...



The time frame and the amount of data that becomes junk is of course dependent on the rate and type of processes the organization is performing, but it is clear that large databases could go from functional to trash quite rapidly if errors go undetected.

-- Hawk (flyin@high.again), January 13, 2000.

They can only chart the ones that end up reported, and only those reported on the Net to boot. This is probably as good a filter as any, since problems that don't cause enough trouble to be reported are not as likely to be serious anyway.

-- Forrest Covington (theforrest@mindspring.com), January 13, 2000.

Not only should we all expect many more Y2K glitches to arise by the end of the month (for obvious reasons Hawk already pointed out).

In the same time frame we should also find ourselves with the flu epidemic in full force, both in the US and Western Europe, which definetly affects the IT staff's capacity to cope with the increasing Y2K problems.

Please see about a dozen threads above:

" (oo)++(~~) = Y2K & the flu (oo)++(~~)

Please input comments.

Take care

-- George (jvilches@sminter.com.ar), January 13, 2000.

First, I have a hard time with the graph, simply because it doesn't tell me if the y or vertical axis refers to total "glitches" reported, or to daily reports. I suspect it is the total because of the scale.

It doesn't matter if 20 problems occur today if all 20 are rapidly fixed. It begins to matter if 20 are reported today, they are not fixed, and another 20 occur tomorrow.

The graph is only valid if it shows the number of systems for which no fix exists, and if that number is increasing.......if we have 20 today, 20 yesterday, 20 the day before that eventually we hit a threshold in which the sheer number of problems becomes overwhelming.

Somewhere out there is a threshold. Somewhere there is a breaking point. When that is exceeded we will have lost the capability of keeping up with the problems. The data provided on this site gives us no hint of either an increase in the number of systems that retain faults nor the threshold that we have to hit before the entire system gets sticky. [By the way, this would be soft threshold, not like falling off a cliff.]

I disagree with Travis.......we don't need to know how many systems are not being impacted by all of this, nor how many systems we have. The real criterion is simply, "How many failures can we tolerate before they cascade?"

We'll never know until (if) it happens.

But, George does make a valid point.......the number of systems that can be impacted before things get ugly is far fewer if the remediation staff is sick at home or gagging and coughing than if they're bright eyed and bushy tailed.

-- (4@5.6), January 13, 2000.

4@5.6, I couldn't have said it any better. I bet you would even pass the "Flint" test guy.

Take care

-- George (jvilches@sminter.com.ar), January 13, 2000.

You could make this chart, or something like it, for any time period in any year. If there's only one bug in an accounting program today, but it seeds two bugs, and they seed two bugs...and so on, and so on, it's very easy to "prove" that the problem will get out of hand in startlingly finite time. And that's true whether the first bug comes in 1980, 1990 or 2000. (Remember the story about putting one grain of rice on the first square of a chess board, two on the second, four on the fourth, etc.? )

If we never found and fixed problems, all of our systems would fall apart. Example one is my house. But we do, generally, find and fix problems.

I have seen no evidence to date which would suggest that Y2K-related problems are developing at a rate faster than our ability to repair them. Air traffic, power generation, banking...all have experienced limited, localized failures. But those failures have been contained.

-- Craig Kenneth Bryant (ckbryant@mindspring.com), January 13, 2000.

Below is a URL for tracking the flu epidemic. http://www.cdc.gov/ncidod/diseases/flu/weekly.htm It is interesting that the overwhelming majority who are tested have something other than the flu. However, if they feel like they have the flu, they are not going to get much work done, regardless of what the test shows.

-- Dave (dannco@hotmail.com), January 13, 2000.

Okay, without giving actual company names:

My current place of employment (hospital), can't issue anyone's W2's yet because they cannot get their corporate system (s) to go past period-end data.

My FORMER place of employment (large health-care related-VERY large) can't issue anyone's W2's either - they have ALSO been stuck in period-end paradise since rollover.

This is not a little thing - and it's too much of a coincidence that my former co-worker shared this story with me today over lunch and as he was telling me, I was like "No Way!" Too much of a coincidence...

Maybe when enough employees start stomping their feet about where their tax info is, the "rest of the story" will emerge as to how many of these "little" glitches are out there.

I, for one, usually do our taxes early - but not this year, I'm afraid.

Ric "Alogrithm" Glitch, III

-- Ric (ice163@worldnet.att.net), January 13, 2000.

Talking about trends

(1) As of Jan. 14 the "flu" (or whatever 'this' is) is getting even worse both here and in Europe, has spread to more countries and states, and has affected wider age groups. Symptoms go by un- mitigated and public health authorities and doctors here and in Europe are several steps behind reality on this one. They don't seem to have a clue about what's really going on. Antibiotics don't help any and people seem to cure all by themselves after 15 days or so.

(2) Y2K "glitches" are alive and kicking too, and are expected to increase considerably during the Jan-Feb time window.

So the question is: how negatively will the 'flu' impact badly needed IT staff availability/performance during the Jan-Feb time frame.

Take care.

-- George (jvilches@sminter.com.ar), January 14, 2000.