Critique of Latimer's Essay - contributions welcomed (VERY long post) : LUSENET : TimeBomb 2000 (Y2000) : One Thread

[My comments are in brackets. Latimer reads this forum, so he'll see what you write. I'm sure I've got some things wrong here somewhere...]

There is a problem with computers that has been increasing in public awareness for some time. Known as the Year 2000 Bug, Millennium Bug, or Y2K problem, it addresses the inability of some computers to read four-digit dates for years. The results can be confusing or inaccurate to a computer; a persons age may be inaccurately calculated to be a negative number, or other problems can crop up. This may be a serious Information Technology matter, not only because many of the most powerful computers use date fields like this, but also because of the problem being so widespread. This glitch can appear in all sorts of software doing all sorts of things, so locating so many different little problems is a time-consuming task. It is extremely likely that not every Y2K problem will be addressed before the year 2000 arrives.

[OK, background boilerplate.]

What, exactly, does this mean?

Some have predicted that because of this problem fuel will stop pumping, airplanes will (catastrophically) stop flying, automobiles will not function, banks will collapse, elevators will plummet, hospitals will become death zones, governments will fail, and that there wont be electricity available for years.

[Well, I know of several embedded systems (this is my field) that will lock up solid, no recovery. The device will become a doorstop! I know of other devices that will continue to operate but will lose some functionality, much like a VCR that will still record and play back, but can no longer be set to record unattended. Now, none of the devices I'm familiar with will cause any great public distress, but then again, my direct knowledge is limited. The *possibility* of serious problems due to such problems in critical infrastructure systems cannot be entirely ruled out. I am encouraged that as we get deep into investigation we aren't finding many. I stand by my prediction that the rate at which various facilities go BOOM will rise above the usual noise level. I expect more cases like those New Zealand smelting plants.]

I disagree with those predictions. There may be widespread inconveniences. I believe there will be frustrations galore in January of 2000. But I also believe there is quite a bit that you, the reader, can easily do to protect yourself and your family from the most likely problems that Y2K can cause.

You can skip to that part of this article if youd like, down where it says What to Do? For those interested, the majority of this article deals with Y2K problems, industry by industry, as well as many places to get further analysis and information on any one of them.

The Odometer Effect

The Y2K problem has been bandied about by many here in Hawaii and elsewhere. It will be inconvenient. It will cause problems. It will not bring about the end of civilization.

The timing of the problem seems to be the main thing that gets people up in arms. If this were the "1987 computer bug" I don't think it would be getting nearly as much press Humans put a lot of stock into numbers with a lot of zeroes. Did you ever have a car that made it to 100,000 miles? Which interested you more--when it got to 99,997 or 100,000? With only a three mile difference, the answer is obvious. Zeroes interest us. I call it the odometer effect, but others call it many other things. There is a curious psychology behind that, as well as a useful way to describe how problems like the Y2K bug are so easy to spin up into apocalyptic visions of the future.

See: about the psychology of Y2K and a model of how ideas like this spread.

[This, I admit, rubs me the wrong way. OK, I grant there are people here and there who become to one degree or another irrational when they see all those zeroes. The problem you are addressing is entirely unrelated. I wouldn't even begin to make the argument that if computers had been systemically programmed to fail in 1987, the problem would get any less attention, or would present any less danger. People get upset (and work overtime) whenever code breaks or computers crash. y2k bugs are very real, and exist regardless of anyone's psychological response to round decimal numbers. The computer could not care less about your religion]


To trace the roots of the problem, you must go back to the days of the early mainframe computers. The Information age was just starting with huge, room-sized computers processing information at speeds a tiny fraction of what desktop computers are capable of today. Everything that had anything to do with the new technology was prohibitively expensive; memory cost thousands of dollars per byte. In the truest sense of the phrase, every bit counted.

Punch cards were used at that time to move information from place to place. Each punch card, however, only had eighty spots to punchand once punched, that information was permanent. Wasting those spots on something as trivial as the 19 in 1965 seemed costly and inefficient. So it was decided that the 19 could be dropped to save the memory.

Harry White, a data code specialist, argued against this measure. Having had experience with one-digit date problems, White could "see many applicationsneeding a four digit date." The problem could have been solved right then. Instead, the Pentagon urged the first federal data processing standard for calendar years be only a two-digit year. Thousands of dollars would be saved.Who could predict, thirty years later, millions would be needed to repair the results of this poor decision?

In 1979 Bob Bemer, the man credited with the creation of ASCII and coining the word "Cobol", wrote an article warning of potential difficulties resulting from the omission of the 19. The article "Time and the Computer" appeared in an issue of Interface Age.

Managers essentially ignored the ideas of White and Bemer, thinking there was no way they would be using the same systems 20 years from then. The managers were wrong.

The Federal Standard for Calendar Dates was issued on November 1, 1968, and took effect January 1, 1970. Again, it called for a two-digit year field. "You couldnt go forth with a federal standard if you did not have approval or agreement from the Department of Defense," says White.

Bemer and White continued arguing for a four digit standard date. Finally, in 1971, the standards subcommittee came up with the standard for calendar years: four digits were preferred, but programmers could drop two if they needed to or wished to. In Geneva, too, the International Organization of Standardization also adopted a two-digit field to represent years.

[In fact, systems were built using ONE-digit years to save even more space. Evidence suggests that the cost of repairing this shortsightedness was a material factor in the demise of several companies that pulled this stunt. You cite one case below.]

The computer industry continued to play fast and loose with standards, many fearing that if standards were too rigid that creativity would be stifled. So the problem remained. Through the 80s the problem was addressed by many, but they were mostly ignored. Even the National Institute of Standards and Technology changed the standard in 1988, saying in part that a four digit year is highly recommended. In 1997, ANSI called for a four-digit year. As usual, compliance is voluntary.

[Uh, maybe not. Standards are indeed a double-edged sword. If too loose, we can't communicate. If too rigid, technological development is stifled. Look at the problems Windows has trying to run all those old ill-behaved DOS applications. But this has nothing to do with the 'creativity' of, (to cite a few examples) naming date fields after your girlfriend, or finding non-obvious ways to do date format conversion because you're bored.

I'm not up for writing long essays about the power of protocols here. I will say that large computer systems have grown by accretion. Fairly early on, it became cheaper to fit new code to the existing system rather than change the system to fit the new code. As systems grew, this cost discrepancy grew. By the time it became obvious that the entire system *had* to change, the cost had become immense. Sure, it would have been a lot cheaper to nip it in the bud. But it was never worth the *incremental* cost to do so.]

See: the article entitled "Lost Chances litter Year 2000 bugs path" by Jim Landers/Washington Bureau of the Dallas Morning News, published 10-04-1998 (The link costs $2.00)

See: for information about Bob Bemer, now president of the company BMR Software, which specializes in technology driven solutions for Year 2000 Compliance

The Meat about the Bug

[I guess I need to address this line by line to start with]

From CNET: "Some of the stories about the millennium bug would have you believe that it will cause airplanes to fall from the sky, ATMs to shut down, and Social Security checks to bounce."

[In fact, some ATMs have shut down. Whether Social Security checks will bounce, or be issued, or arrive late, or be of wrong amounts, or whether the system can accept new applicants, remains to be seen. This 'would have you believe' phraseology implies that someone is out to trick you. This is misleading at best. The path between valid possibilities on the one side, and speculative ramifications on the other, is very narrow. Especially when (as now) the probabilities are unquantifiable.]

"But while the Y2K bug is real and the risks of inaction are considerable, people who are actually working on the problem say that the myths and exaggerations about Y2K have overshadowed the reality."

[People actually working on the problem also say exactly the opposite! It depends on who you're talking to. Remediation projects range from trivial to massive, and the prognoses for these projects range from finished to hopeless. Nobody can possibly evaluate the daily status of each of the millions of remediation projects now going on, integrate all the results, weight each project (and each element of each project) by its projected importance or impact, and derive a meaningful conclusion.]

In fact, computer bugs like Y2K happen all the time.

[No they don't, really. There are two differences -- qualitative and quantitative. Qualitatively, what sets y2k bugs apart is that they live in mainline code. Most errors that crop up all the time result from rarely-executed code, rarely-encountered special data values, low-probability asynchronicities in the system, hardware failures, etc. The howling blunders were scrubbed out before the code ever went live. Y2K bugs are mainline - they get hit by *every single record* the system processes. Yes, this makes them easy to find. It also means that if you miss fixing one, you're dead in the water and your data are suspect.

The quantitative issue is even more serious. Estimates are that we currently have the capacity to handle at most two or three times the error rate we currently experience (and only in full buckwheat mode. After enough consecutive 24-hour workdays, the geeks will drop in harness). And this safety factor has diminished as we've cut costs and downsized to remain competetive. The delta increase in error rate (and an increase is not denied anywhere) is critical. You can safely bet there will be triage in the maintenance department just as there is now triage in the remediation. Our ability to *deal with* this increased rate lies at the heart of the debate.]

Excerpts from the Year2000 FAQ:

3.2 Has mankind ever had to deal with this kind of problem before? -Many years ago when I was in the Air Force, we had a major system balk at going from 1979 to 1980 because of a 1-position year setup. Daniel A. McLaughlin ***

[ A 'major system balk'. Interesting. Maybe we were fortunate the Air Force didn't need that particular system for a while. Now we're talking about the possibility literally millions of 'major system balks.' And we rely on these systems continuously. Best we pray that the remediators will take one hell of a bite out of this condition before we reach the relevant pay-the-consequences dates.]

-It's happened before! Being a graybeard in computing, I'm a bit surprised that this problem is only now being recognized, since it's happened before. This is a favorite thing of mine to mention in classes. Normally I say something like:

"Why were a BUNCH of programmers called into work on an emergency basis shortly after New Years, 1969?" - My students (who are most 22 or so years old (sigh)) generally don't have a clue.

The answer is that programs dealing with long term financial instruments (30 yrs) all of a sudden had ABENDs (as we called them then) when maturity dates computed from 1970 started producing zeros - mostly mortgages and long bonds. Bob Wier ***

[OK, bear with me. The mortgage problems are a marvelous case study. To calculate a mortgage, you need three parameters - the principal, the period, and the interest rate. No dates involved! So why were there ABENDs? Because amortization schedules use dates, and the amortization programs croaked. NOW, you got two choices here: You can clean the date bugs out of ALL your code and expand to full 4-digit years across the board (VERY expensive and excruciatingly slow and difficult, not to mention the problem of newly introduced bugs), OR, you can hardwire a '20' into the amortization code itself if the year is <70! And you need to patch this thing RIGHT NOW, the lines are growing as we speak. OK, which one do you choose?

But wait a minute! How about all those other things that use dates, like payment date, due date, overdue date, retirement date, notification date, there's a hundred of them and they're all wrong!

Simple. We'll worry about those when the time comes. If it ain't broke, don't fix it.]

See: for Peter De Jagers 2000 FAQ.

If you check out CNET's Y2K articles, you will find this: "The Y2K problem is unusual because it affects so many computers. However, it is neither particularly complex nor is it unprecedented in the history of computing."

[Not sure what 'unprecedented' means, unless you're talking about the 1-digit-year systems that died. There weren't many of those. In any case, the complexity is highly variable. My reading is that the vast majority of repairs are dumbingly simple. And a few of the requirements and repairs are not. It took Mastercard six months just to set up and validate their time machine, even before any code was tested at all. Not trivial.

The degree to which the problem is widespread *is* unprecedented. So is the narrow time frame in which the bugs crop up. Anyone who says "yawn. been there before" is putting you on.]

See CNET continues with details about the bug:

"Nicholas Zvegintzov has studied computer science and artificial intelligence since the 1960s and has been a software consultant for nearly 20 years. While he acknowledges that there is a real Y2K problem, he dismisses most of the horror stories as the tales of the inexperienced. 'As a thing to do with code, it's not especially complex. It's actually a very clean problem; you can throw some clean techniques and clean tools at it.'

He calls the Y2K bug fix 'an exercise for the software novice' and predicts that business will continue more or less as usual when the millennium rolls around."

[At best, this is selective to the point of dishonest. My best guess is that Zvegintzov is an ivory-tower theorist who has never had occasion to look at critical enterprise code which has been massaged by barely-competetent (and less) programmers for a generation, patched and kludged under time pressure, undocumented, not archived, etc. I can just picture Zvegintzov looking at some of this spaghetti and sputtering "but this is wrong! This is incompetent! This is poor management! This should not have been done this way!" Yeah, Nick, you're absolutely right. Welcome to the real world.

But like any good academician, he guards his rear quarters well. "More or less" as usual, eh? Well, if it turns out to be 'less', he's still right.]

"Zvegintzov characterizes the Y2K problem as one of bounded storage, which simply means that hardware has limited storage capabilities. For example, according to the Year 2000 FAQ, storage space was so tight in the past that one-digit dates were occasionally used. If you counted down through the 1970s with a one-digit date field, you had the same problem when the date ticked around to 1980.

[as I said, this technique was rarely employed, and always with ill effects.]

Other examples of bounded storage also occur when users demand more features in a software application or when an area code fills up with phone numbers. These problems are similar to the Y2K bug and are the kinds of issues that software engineers deal with all the time."

[ARRGH! This is a false similarity. If I hit you with a straw or a baseball bat, these are the 'same kind of' attack. All I can do is reference my discussion above as to why these issues are both qualitatively and quantitatively different. Yes, we deal with bounded storage problems all the time in countless ways. The prospect of dealing with many serious problems essentially simultaneously is something else again, and should not yet be dismissed lightly.]

"One person who programmed COBOL for the US Air Force in the 1970s jokes, 'I honestly don't see what the Y2K fuss is about. The computing world ended a long time ago. In fact, the computing world ended eight or nine times already.'"

See for more history and Y2K myths.

[Be very careful about what's really a myth. An ex-USAF COBOL programmer may contribute a comforting sound bite here, but portraying such bites as exemplifying the whole problem is disingenuous.]


From CNET: "The Y2K bug is a real problem, it's a widespread problem, and it needs to be fixed. But most of society's vital organizations expect to have the critical portions of their systems repaired or replaced in time. And nobody who's actually working on the millennium bug expects anything near the apocalyptic scenarios put forth by the doomsayers."

[I don't know who CNET is quoting here (and you really should say). I think it's worthwhile to distinguish between organizations *saying* they expect to meet the deadline, and actually expecting to do so. Perhaps this is a quibble, that's up to you.

What's really critical is what 'most' means in this context. 51% 'most'. So is 99%. But the difference is significant. Bear in mind what I said earlier about error rates. Right now we are set up to handle a few errors a day, say 2 or 3 at most (per IT department). Maybe with marathon hours we could handle 10 or 12 such errors. If we're looking at thousands of errors per day, all bets are off.

The statement that 'nobody who's actually working in the bug expects' really bad things is simply false. Too many testimonials of individual hopelessness are available to anyone who looks. Of course these are isolated and may not end up causing much problem, but the indeed exist. They're real.

Beyond this, there are serious questions of definition involved here. Yes, I agree that there are what I consider some truly lunatic visions of apocalypse floating around. But using these as the *standard*, and implying that because those who hold to them are nutcases, *therefore* there won't be much trouble, is a false argument and bad logic. The Great Depression wasn't "anything near the apocalpytic scenario put forth by the doomsayers" either. But it was nothing to ignore or laugh at. Hard times doesn't necessarily imply a massive dieback.]


CNET continues: "Sally Katzen is the director of the Office of Management and Budget for the President and is the point person for millennium bug fixes for 24 federal agencies. Katzen has no indication that many--or any--government systems will fail. "We have a high degree of confidence that the important services and benefits will continue through and after the new millennium. It is my expectation that when we wake up on January 1 in the year 2000, the millennium bug will have been a nonevent," says Katzen.

[Well, Katzen is now out, so this needs some updating. Still, OMB's descriptions remain very different from GAO. And even OMB sounds very worried. The FAA has been moving backwards, from 99% finished last August, to 31% finished this March! Oops. And for what it's worth, word on the geekvine from government is uniformly dismal. Not one single anonymous government programmer to my knowledge has come forth with anything but howling laughter at the suggestion that their problems will be fixed in time.]

Raymond Long, director of airway services for the Federal Aviation Administration (FAA), says the same thing. He is so confident that the bug won't affect air traffic that he's planning to fly cross-country at midnight on doomsday."

[Come on! This is a calculated sound bite, pure and simple. FAA has been falsely predicting upgrades to their ancient systems for over a decade. They've had a few efforts in that direction, and all have failed miserably. Document this! And look at the software problems experienced by new airports like Denver (2 years late) and Hong Kong (on hold indefinitely, after a catastrophic attempt to actually use it). The prognosis for several critically important airports is unknown right now. Unknown doesn't mean either bad or good, it means unknown. Their projected completion dates cut things pretty close. And projected completion dates for large projects have a terrible track record.

NOW, to what extent (if any) the remaining problems will interfere with air traffic is a wide open question. Maybe very little. Maybe not. My best guess is that air traffic will slow down and become less efficient. Economic impact unguessable.]

Government Systems, such as Social Security and Unemployment Insurance have passed their first Y2K tests with flying colors. Many challenges remain, but it was a great first step.

[Many challenges remain, eh? If this is government-speak, it means real trouble. "Challenges' is a government euphemism for FUBAR. The government is strongly motivated to test what little they know works OK and declare the test a success. When have you ever heard the government publicize a failure?

Please try not to paint a false picture here. We have many real bugs. We're working on critical systems and letting the rest slide. 'The rest' is 90% of government systems! These aren't even being looked at!]

See about government systems.

[Here you might also want to link to the recent Senate testimony as well. And to the GAO audit results. As a start.]


The main focus of the Y2K problem, in terms of a huge, civilization-wide, collapse is electricity. Without electricity, banking, and life in general becomes much more of a hardship.

Here in Hawaii, the Hawaiian Electric Company [HECO] is the electric company. As it happens, the Y2K fixes have been tested, and are in place as of November of last year. Other conventional facilities have implemented similar changes. Even the nuclear power plants, which are undoubtedly more complicated than our local diesel generators, are being widely corrected. There could be brownouts and blackouts some places in the world, but these will not be so drastic that there will be no electricity for six months to a year. In every report about this problem the news gets better.

See for Hawaiian Electrics Y2K pages See for the actual program fixes for the EMS system

See for the latest power Y2K news.

See for a report on NERC and several nuclear power plant Y2K reports.

[OK, I'll agree that the news from the power sector is pretty good and improving. Six months to a year seems pretty much ruled out. A week or two, in the North? Well, that can get pretty damned uncomfortable.]


CNET's articles: "Nick Magri is the overall coordinator for the Y2K project at the Securities Industry Automation Corporation, which oversees technology for the New York and American stock exchanges. He has not had a problem getting financial services businesses to fix the problem: "The securities industry started on this a year and a half ago. The bigger businesses we see a lot of, and they're on top of it," said Magri. He expects trading to continue as usual on the first day of the year 2000.

In fact, the financial industry is extremely conscious of the problem. Not only are financial programs more likely to use dates in calculations, but everyone in the industry is acutely aware of how interdependent their organizations are. As a result, m any financial institutions are under pressure from both internal and external sources to fix the Y2K bug. As Bank of America representative Bob Lynne says, "We don't operate in a vacuum. We're making every effort to see that our business partners--banks and financial services companies--are aware of the problem, know what they will do, and know how their systems will work with our systems."

Should you pull all your money from the bank because of Y2K? ZDNET writes: "With the caveat that nothing I say should be construed as investment advice, my opinion: Banks and financial services companies are pretty safe places for your money, regardless of the times or technical problems. They will not "lose" money, though it may be misplaced or temporarily inaccessible due to Y2K problems. Your concern should be, I think, with liquidity and accessibility of money."

See: for a general review

[OK. With the usual caveats that this is self-reporting, and the results of the currently ongoing trading tests aren't in yet, and some major traders weren't ready for the test yet, and this is US-centric as hell although the trading and banking systems are NOT.]



[Very carefully stated, I see. I flat guarantee that if all computers were to mysteriously vanish overnight, worldwide banking would collapse and stay that way for a long time.]

FACT: The working man and banking system were in place many years before computers came into the picture.

[I'd have to regard this statement as a nonsequitur. We have computerized many fuctions that were once done manually. In the process, we've become more efficient, offer more services, and make fewer mistakes. We've also lost the manual skills, we no longer have the required equipment, and most important, we've reorganized around computerization in ways that cannot possibly be reversed quickly.]

There will be paychecks, because it is in the business' interests that there be paychecks, come hell or large computer crash.

[Out of curiosity, How? If my employer's computers crashed, I guarantee there would be no paychecks. There are no blank checks, there is nobody to write them if there were, there'd be no way to know who to make them out to or in what amounts even if we had the people and the checks. Get real.

90% of startup businesses in the US go bankrupt within their first two years. Is it in their interests to go bankrupt? Well, they do it anyway! This sounds like the argument that nobody *wants* to die, so nobody will die. Bogus, man]

Banking data is routinely backed up, for obvious reasons, and though the computers themselves may be date-intensive, the data itself is not.

[HAW HAW HAW! You kiddin' me? These records are jam-packed FULL of dates.]

Computers with the Y2K fixes in place will be able to read the data just as readily as their non-compliant cousins.

[Well, this depends on the details. Perhaps the major factor leading companies to use windowing rather than expansion is the data. Expansion of dates changes all the data, it moves fields around in records. It requires modifying *all* programs that read *any* data, whether those programs use dates or not. If expansion is used, backed-up 2-digit-year-data *cannot be read* by the remediated programs. And windowing has its own problems. So such a blanket statement cannot properly be made.]

Computer solutions are being found, and the data can be re-inputted.

[Groan. Thank God it's not MY job. Even if the original source material these data came from were still available (and it isn't, else why input it in the first place? That's what computers are *for*), in many cases were talking *terabytes* of data here. I suppose if you had shifts re-entering this (non-existent) data around the clock, you might get finished in a decade or so, provided you didn't generate *any* new data during that decade! This is like saying, well, if the harvester breaks down, no big deal, I'll just grab my handy Bowie knife and go harvest the north 5000 manually. This is nonsense.]

People will continue to work and get paid...businesses that are silly enough to let a computer glitch stop everything cold will go under.

[OK, I'll go along with this subject to my points above. Now, how many businesses will end up being silly? Is it silly to underestimate the size of a problem of unknown size? Is it silly to try to fix the problem cheaply enough not to endanger the business itself (a BIG problem for small businesses)? Is it silly to go under because one of your key suppliers was also silly? Finally, is it silly if the glitch doesn't stop 'everything' but causes enough errors and downtime to bleed the company to death over the course of many months? These are real and important issues.]

Banks are a lot of things, but silly is not one of them. Remember, it was not very long ago when we did not have credit card readers, and you had to put your card in that silly gadget with the carbon paper, and authorization took days instead of seconds? That could happen for a little while (probably a week at the OUTSIDE) but even so, civilization doesn't stop.

[Yes and no. Are you being serious here? I hate to waste time if you aren't. Yes, we had those days of slower and clumsier technology. And credit card usage matched our ability to handle it. Now things are really fast and easy. We have credit cards and debug cards. We have wizbang technologies to handle it. And usage has grown in lockstep with the technology. We no longer even *have* those carbon paper gadgets. We no longer *have* the systems in place to handle them if we did have them. And the people who dealt with those systems when they existed are gone. And the organizational structures necessary to accommodate those gadgets are gone. There IS NO GOING BACKWARDS.]

Some new inconveniences? You bet-- and there will be grumbling. But product will move, be bought and sold, and be available because it is in the interests of the businesses to see that it is, computer or no computer. If the Computer Age were 150 years older, this would probably be a much more serious problem.

[Good point here, and a cautionary observation for the future. But while it's true that businesses will always act in what they see as their best interests, the fact remains that they cannot do what they cannot do, no matter how desperately they *want* to, or how strongly it's in their interest to do it. There's a very important matter of latency hiding in here, and I strongly recommend that you bring it out of hiding. The question is, *how long* will it take to adapt to radically changed circumstances? Could you really survive without food for the 2 or 3 years it would take for all the relevant businesses to revert to the mom and pop corner store level? The governor on our current rate of change is the speed with which we can adapt to that change. An extremely sudden change doesn't need to be any too damn large to exceed our maximum rate of adaptation. It's this period where the danger lies.]

However, it is important to minimize the very real potential of mistakes in your financial information. Taking careful stock of what you have, what you are owed, and having documentation to prove all that is essential. Check your bank's remediation efforts and act accordingly.

See: for more advice about personal finance and Y2K.


FACT: Howard Rubin phrased it best: "The level of disaster is still fundamentally our choice." [New York Times, December 27, 1998] Economic factors are always impossible to predict with absolute certainty. The markets may very well increase and decrease based on news, true or not, concerning the Y2K threat. Some have said that Y2K cold very well trigger Americas next recession. However, many disagree.

Mark Zandi, of The Dismal Scientist wrote in part: "To argue, however, that such disruption [Y2K] would bring an end to the economic expansion seems sensational. As has been pointed out by Governor Kelley, previous disruptions to the nations physical infrastructure, such as the early 1996 winter storm that paralyzed the East Coast, or last summers UPS strike, have had only transitory economic impacts."

See: for more detail about possible economic effects.

[Rubin's observation is running out of runway, I think. Already for many remediation projects, there simply isn't enough time. All the desire in the world will be thwarted by enough millions of lines of code. Yes, economists disagree on the impact. And sensational things have happened. Comparing what *might* happen to things that *have* happened (but very different things) is of limited utility. The question of just how valid those comparisons are is hotly debated. I personally don't feel those comparisons are very useful, and that y2k must stand along on its own merits. But if you're going with this, you should at least include Yardeni in here too.]


FACT: The FDIC is fine.


[Ummm. ZDNET gives every indication of being an advocate (grinding an axe). FDIC itself claims they'll be OK. A close friend of mine recently bailed from FDIC because, as one of their programmers, he'd given up all hope and didn't want to suffer the death march.

In any case, FDIC doesn't have the money. Their job is to *administer* the process of allocating money voted by Congress. And collecting that money from taxpayers during an economic downturn might be hazardous to re-election.

I DO NOT regard the statement "the FDIC is fine" as a fact. Perhaps at least you should link to a GAO assessment of FDIC.]



FACT: "This is one of the most pernicious myths of Y2K, fed by the offhand comments of an analyst before Congress and having been repeated without corroboration until its taken as the truth. But, a myth it is."

"No microwave, alarm clock, washer, dryer, refrigerator or radio will cease to function because of a chip hidden inside. A few appliances, like camcorders that are date-aware, will display the wrong date, otherwise they will operate normally. VCRs manufactured before 1988will need to be reset to pre-2000 dates to allow preset recording."

"According to the Association of Home Appliance Manufacturers (AHAM), the organization 'is not aware of any anticipated problems or disruptions associated with home appliance operation and use related to the Year 2000.'"

See: for an in-depth analysis of the appliance issue.

[Now you're being silly. The embedded systems issue isn't about home appliances. It's about PLCs running assembly lines, and vibration detectors for utility flywheels, and process monitoring equipment in chemical plants, etc.]

From CNET, about elevators: "Otis Elevator is similarly skeptical of the claims that embedded chips in elevators could cause stalls or crashes. 'We have done a thorough review of our elevator systems all around the world, and we have never found any reason to expect that the millennium bug will have any effect on Otis elevators. Our systems aren't date-dependent in any way,' says Peg Hashem, a spokesperson for the company.

Bob Wynne, media representative for Bank of America, said the bank's Y2K team is not really concerned about ATM malfunctions. '[Our engineers] don't want to sound cavalier about it, but they are concentrating on the mainframe fixes.'"

[Otis elevators appear to be OK. Rumors about others remain rumors as far as I know. Current evidence suggests that almost all if not all ATMs now work correctly.]

"Y2K consultant Peter de Jager has posted dozens of alarming articles on the millennium bug as it relates to mainframes. In contrast, only one recent posting mentions embedded systems--and the author flat-out states that 'most [embedded systems] won't fail" and that "very few firms will jeopardize their future by ignoring this issue.'"

[Several points here. First, we have the matter of criticality. The 1965 east coast blackout was caused by the failure of a single switch. As I recall, the Bhopal disaster was caused by a single failure as well. We're not worried any longer about the *number* of embedded failures, so much as *which ones*. This is important.

Second, there's the matter of the scope of the problem and the difficulty of addressing the issue. Chevron has already admitted there are just too many to deal with. Their implication is, they're blowing off any devices that won't materially affect their operations even if they fail completely.

Beyond this, there is no standard methodology for testing a 'generic' embedded system. They're all different. Some are essentially untestable (I've done some of these myself). My personal expectation is that embedded failures will show up in two ways: local things that go BOOM here and there, and manufacturing inefficiency due to nagging problems that just seem to keep happening, one damn thing after another.]

See: for an old, but decent article on embedded systems.

See: for CNET about embedded systems.

See: for a HUGE list of everything from Access control to Water Purification and its Y2K compliance.

See: for general commentary on embedded systems and why the problem, while serious, has been dramatically overblown.

[I agree the problem has been overblown, and there won't be nearly as many failures as was originally feared. Still, I'd advise you not to be downwind of certain military installations...]

Also, there is the small matter of physics involved. When your VCR or microwave are unpowered, either because you have unplugged them or a blackout has occurred, what happens when you plug them back in?

[Uh, they get power from the AC circuitry going to the plug? Your PC has a battery in it, good for 3-10 years of being unplugged from the wall (and much longer if you're plugged in most of the time). This battery *keeps time and date*. And such PCs are the guts of most of the critical embedded systems under discussion here. Other devices uses capacitors to retain configuration information for several days unplugged. And these are physics too, yes?]

When your car's battery dies completely and you get it replaced, what exactly happens? You have to reset your clocks on your VCR and microwave, as well as your car's clock and all your favorite radio stations that the radio has forgotten.

[Is this true? I don't know. I'd certainly design my car's clock to run off capacitance for a few days, especially as these things get more complicated and start storing lots of stuff like maintenance logs, radio settings, and whatnot. This would be very handy in most cases of dead battery, and dirt cheap to implement.]

What does that mean to any "embedded chips"? It means they have no concept of how much time has passed.



[And I'll say it again. WRONG! I've already given two methods: small batteries and capacitors. There are other ways that have been used, varying from magnetic induction to beamed power. And these aren't rare either (I already said this is true of ALL PCs). So let me make a similar simple statement: if any devices is *required* to keep real time, it is designed to be able to do so under all normal conditions that can be anticipated. Loss of power is a normal, anticipatable condition.]

What does this mean? It means your car's onboard computer systems REVERT BACK TO THE DEFAULT DATE OF THE MANUFACTURER.

[I'd need a good, reliable source for this statement. All I can say is, that's not the way *I* would design it.]

Your car may think it is August, 1985, or June, 1980, or any other random date in the past; the date of manufacture. The embedded chips have no way of recognizing the true dates. If they did, how come you have to reset the clocks on your appliances after a blackout?

[Calm down! How come you *don't* have to reset your wristwatch? Can't you see that it depends on the device? As a general rule of design, if there's no need to keep real time (as opposed to elapsed time while running), this time isn't kept. Why bother? If there *is* a good reason to keep real time, that process is pretty well defended against power failures.]

Therefore, even if you HAVE a Y2K vulnerable chip in your VCR or Microwave or car, chances are good that it has reverted at least once since you got the appliance. If not, unplug it, wait for a couple of minutes, and plug it back in. There. You have just reset the date back to the date of manufacture.

[Or randomized it in many cases. If real time isn't relevant, it isn't kept. If real time is easy to set and change, it isn't defended. It all depends. And by the way, capacitance holds the settings I selected for several components of my stereo system for three days. I learned this by trial and error.]

You now have random number of extra YEARS before you have to worry about the pesky embedded chip, and if the appliance or chip stays powered long enough to cause problems, unplug the thing, wait a moment or two, and plug it back in. The embedded chips' dates revert, and you have years of use before you have to worry about that problem again. Unlike computers, there are no BIOS batteries to keep date on an appliance. If the date resets after you unplug the thing, its onboard-embedded chips will not fail on Jan 1, 2000. Period.

[Sigh. Again, home applicances are NOT what we're worried about. We could care less. Your description applies to certain classes of devices. Not to all devices. If you are trying to generalize that there will be no problem with *any* device because there will be no problems with *some* devices, you're making a logic error. Real dangers do exist with some classes of devices.]


FACT: The laws of physics and gravity will not change come Y2K. Airplanes will be as fine a place to be as any. Airplanes dont have any Y2K difficulties that would prove catastrophic in the air, and some airports already sport fully compliant systems. Others expect to be compliant on time, but measures are in place in case of total electrical failuresa MUCH more serious condition than Y2K.

See about general air travel and airport compliance

See for the FAA Year 2000 projects

[This myth is hardly worth debunking anyway. Boeing and Quantas (that I know of) have gone through their planes very carefully, and found no noncompliances that would interfere with the safe operation of the vehicle. They *did* find noncompliances, just nothing critical. Beyond this, your logic stinks (no offense, much). If the instruments should die at rollover when the plane is flying through the fog, neither physics nor gravity would prevent that plane from flying into the side of a mountain.

Airports I already touched on. They are addressing their critical systems. I personally expect (my opinion) that airports and planes will operated at somewhat reduced efficiency. Word on the street is, you'll fly safely, but *expect* to lose your luggage.]


FACT: The Gas and Oil industries do have remediation problems, but they are not so extensive that all the fuel stops flowing. "Some oil drilling, refining and distribution systems are going to fail. There can be no doubt of it, in fact, because the oil industry is one of the most computerized in the world. Too, many of the systems used pre-date 1990, when few embedded systems manufacturers contemplated Y2K issues."

[Well, during the 1973-4 oil crisis, fuel never stopped flowing. It only slowed down a bit. Remember the results? Not just the long gas lines, but ancillary problems like surging inflation, higher unemployment, serious recession. And a reduction in fuel was the *only* problem happening at the time. Expressing your 'myth' in such absolute terms is an exercise in disinformation. Curtailed supplies (but not NO fuel), higher prices (but not prohibitively high) and oil equipment problems (not ALL machinery) can combine to produce some very unpleasant consequences. Your all-or-nothing formulation tries to hide a genuine threat behind a screen of exaggeration. This is unworthy.]

However, the President does have the option, if necessary, to open the American Oil Reserve of over 563 million barrels.

[Source? And how long will this last given projected shortfalls?]

Prices may rise, but the oil will get to where it is needed.

[Availability *somewhere* and availability *where it's needed* are different issues. But yes, there is a certain flexibility here, assuming (of course) that transportation is OK, refineries are OK, etc. We can even uncap wells that were not quite economical to pump, but this takes months.]

Rick Furiga, Deputy Assistant Secretary for the Strategic Petroleum Re serve at the Department of Energy, said in part: "We do not believe that the production of crude oil throughout the world will be substantially affected for a prolonged period by the year 2000 problem. However, for the sake of discussion, if production w e re to be negatively and substantially impacted the United States, in coordination with the other 22 countries that are members of the International Energy Agency, would consider the volume of production loss, the inventory situation, the reaction of unaffected producers with spare capacity, and reports of shortages. If the situation appeared serious the Department of Energy could recommend to the President that oil be sold from the SPR. The decision to sell or not sell would be at the discretion of the President. If he decided to sell oil from the SPR it would be contingent upon issuing a finding of an energy supply emergency."

The oil and gas will be availablebut speculation about the effects of Y2K, as well as the costs of remediation will cause fuel prices to increase. But the oil will not stop flowing.

See: for more about Oil and Gas.

See:,4,29381,00.html? about Mobil and Exxon's merger and their Y2K remediation efforts.

See: for the American Gas Association's Y2K information and Frequently Asked Questions.


FACT: Maybe that is trueyou can also say you don't "know" that the sun will come up tomorrow.

[Faugh! Assigning probabilities is damn difficult.]

However, we can make some very good estimated guesses that the sun will come upand we can make some very good estimated guesses about Y2K as well.

[No question. We can make *great* guesses. The neat thing about the future is, any guess is as good as any other until the due date arrives.]

For example, many people were predicting utter disasters even in January of this year, because computers that look forward more than a year would see 2000 and break. Also, on January 1st, the Euro was introduced. This affected about a third the number of computers that Y2K does, and many expected a "preview" of what Y2K glitches might be like in early 2000. The reality of both turned out to be this: Where hundreds of Y2K failures were expected for January of 1999 there were 11. Where thousands of glitches were expected for the Euro there was one.

[Uh, no. Not at all. Good evidence exists that there were many thousands of glitches associated with both January 1999 and the Euro. Fortunately these have been minor, and handled in-house without inconvenience to the customers. But they *did* happen, and stressed the maintenance capacities of those who experienced them. In fact, JAE problems continue to be a steady annoyance to these shops, but not insurmountable. Just longer hours, shorter tempers. I'll be glad to agree that the severity of these problems was overestimated by many, and by a large margin. But whether this can be translated directly into a prediction that the severity of y2k problems to come are also overestimated, I cannot say. The connection between them seems tenuous.]

What do we learn from this? We find that "organizations are prepared to deal with problems. Errors were identified and fixed quickly. And there just werent very many problems in the first place. Those are the facts. "

See: for what we can learn from the Euro.

See: for why we will have a very good idea about the Y2K problem before 1999 ends.

See: about details of problems that occurred in January of 99, ranging "from the annoying to the trifling."

[The astute and assiduous reader will surely notice, sooner or later, that almost all of your links point to zdnet. At best, this looks a bit lazy on your part. An informed reader might be aware that zdnet is notorious for painting a uniformly optimistic picture. When almost all your data are from the same source, regardless of the source, your objectivity might also come into question. How about some counter views here?]


FACT: If you have a Macintosh, run Unix, or are running a WINDOS computer that is newer than 1994, you can be 99% sure you are Y2K Compliant. If you aren't compliant, your computer's BIOS manufacturer has a Flash ROM upgrade that will solve the problem. In fact, there are now so many different solutions to the PC Y2K problem that it s more difficult to decide which one to use.

See: for some common software fixes for Y2K and your PC.

[Oops. My expertise precisely. I can assure you that BIOS problems are so trivial that a flash upgrade is moot. Here's the secret: Check the date after rollover. If it's wrong, change it. One time. You're fine from then until your battery dies (and dead batteries are not date-dependent).

NOW, this has nothing to do with applications and data. The Thunderbyte antivirus people have released an upgrade for a known date bug, sorry we trashed your hard disk, we'll let you have the upgrade free.

And oh yes, those spreadsheets and database programs you wrote yourself -- well, sorry about that. What, you wrote them on a Macintosh? So what. Date bugs you wrote are date bugs. Platform doesn't matter.

And how about all those thousands of homebrew 2-digit-year spreadsheets and data interface programs tied into the company mainframe? Can these cause problems? Well, yes they can. What, you mean I need to look at ALL of this stuff written over the years by ALL the power users we've ever employed? You got it. There's millions of needles in thousands of haystacks out there. How many of these needles will give you blood poisoning? Well, it only takes one...]

What to do?

The advice I have been giving people is the same as I tell my computing clients:


If you have IRAs or are getting Social Security checks, have them draft you all the pertinent information, and keep it safe. Make sure your latest banking statements are up to date, accurate, and keep them safe. Have them on paper, the best back-up stuff there is. No computer bug can destroy paper.

Do NOT panic and immediately withdraw all your money from the bank, because in doing so you are making a banking crisis, and making the Y2K bug nothing more than a self-fulfilling prophecy.

Keep records about what you have, what you are owed, and to what you are entitled. I'd say that even if there were no Y2K bug at all. That way, when a computer crash does happen (and it will happen, regardless of Y2K) you have the stuff to prove who you are and what the numbers should be. Problem solved. Inconvenient as hell, but a solution nonetheless.

See: for advice on what documents to make sure you have, and where to get copies.

As to stockpiling of food and supplies, it is probably good to do some of that anyway. Most places are prone to one kind of natural disaster or another; here in Hawaii hurricanes, tsunamis, and possible volcanism are the biggies. Having a few days of non-perishable food, a portable water purification system, an emergency kit, and an automobile with three-quarters of a gas tank is simply prudent, regardless of Y2K or not. Keeping your personal papers and documentation up to date, organized, and in a safe location is the rule, not the exception.

See: for supplies you could need in the event of any disaster.

The bug is serious. However, millennial superstition certainly plays a part in its widespread reportage and the general overreaction that has been seen here and elsewhere. The world will survive. Lives will continue. Civilization won't end. Just make sure you have copies of your banking statements. :)

[Yeah. hehehe. All good advice. I can't speak about Hawaii. For those on the mainland, I'd recommend an alternative heat source, a stockpile of food and potable water for a while (probably a month is good enough, but I'm prepared for a year), a reasonable stash of cash in case of bank runs or shutdowns (you yourself quoted above that the bank won't *lose* your money, but you might not be able to get at it for a while).


-A computer glitch will not bring about the end of civilization. It takes hordes of panicking people to do that.-

[Maybe so. But if I lose my job and can't find another, or if the plant next door blows up, of if I'm among the minority suffering a blackout, then civilization won't look too good from my viewpoint.]

-- Flint (, March 22, 1999



just glancing through it (don't have time for more), your responses look pretty good to me. if i get the time (ROFL) in the next few days, i'll print it out & go through it more closely.

-- Drew Parkhill/CBN News (, March 22, 1999.

Who is Latimer and where is his essay?

-- No Spam Please (, March 22, 1999.


Jonathan Latimer. I don't know more about him than his name, and the fact that he has posted this essay on his site. He is looking to update the essay and asked for comments. Since I am nowhere near an expert on everything he mentions, I could only do my limited best and then ask for help from any very patient volunteers here.

The essay is currently posted at:

-- Flint (, March 22, 1999.

Just because I'm a copyright fan, here's the last item of Latimer's essay:
) 1999 by Jonathan Latimer. Permission is given to distribute in whole or in part as long as author's name and copyright notice appear.

-- No Spam Please (, March 22, 1999.


Actually, my article wasn't done yet, which was why I was solicitng comments from people about where I could get more information/clarify things/update it. Flint seems to have a good middle of the road mentality, and also writes well enough to make me laugh, so I mailed to him asking his opinions. The article is out of date, and needs work. However, since its posted here already, I guess I'll take the heat for what I wrote.

To those whom it actually matter, I have been involved with computers for fifteen years, own my own little computer consultancy in Maui, Hawaii, and host a tiny computer-minute type radio blurb (can't really call it a show). I have been looking over Y2K for about 15 months now, have 2000+ pages of printed documentation, (I am a researcher at heart) and have been soliciting comments from people involved with Y2K to make version 2 of my article more accurate. My Y2K article was quoted on CNN...but that was awhile ago and, like I said, I was updating for better/fresher information.

At any rate, comments appreciated, and I know that torpedoes will be inbound, so I'll brace for them.

Keep smiling,


-A computer glitch will not bring about the end of civilization. It takes hordes of panicking people to do that.-

-- Jonathan Latimer (, March 22, 1999.

I had a couple of people write me about lack of research, so I started going through my pages. If you want my meager internet findings so far...I am not sure how many of these links still work but I do have them all printed on paper.

Y2K General Articles:,6158,2213323,00.html .html t=A&ak=news1486,4,31727,00.html? mpl&setCookie=1 ml

(No hyperlink) NY Times Feb 9, 1999 'Fear of the Year 2000 bug is a problem,too by Barnaby Feder

(No Hyperlink) Time for Kids The Year 2000 Bug Special January 15th, 1999,5859,2209104,00.html ews,6158,2206553,00.html y2k_5.html .html


(No hyperlink) Honolulu Advertiser 2/25/99 Y2K: a big worry only if we make it so

(No Hyperlink) Millennial Cults ad the Concerned Christians by Michael Shermer, Skeptic mag

(No Hyperlink) The New York Times national Report 01/24/99 Doomsday Machines by James Gleick l 6256713003D958F

Whew. That's the first two sections. I have sixteen sections to go, but I and my fingers are pooped. The sections are:


1998 an 1999 problems


Bad Idea


Airplanes and Travel


Critical Systems and Power




PCs and Personal Computing

Embedde Systems




Each has about the same number of articles as above. I'll post each section, as long as the board doesn't think I'm spamming uncontrollably.

If some of the links have changed/don't work/have typoes my apologies...I am typing all this by hand (I still have a devil of a time with 'millennium'). However, I do have all the refernces I cited on paper...and you can't change the web address of paper. :) So if a link has moved or disappeared, let me know and I can change the address, or cite the article (though I don't want to type the whole thing in, I will if I have to).

At least its a start.


-A computer glitch will not bring about the end of civilization. It takes hordes of panicking people to do that.-

-- Jonathan Latimer (, March 23, 1999.

"-A computer glitch will not bring about the end of civilization. It takes hordes of panicking people to do that.-" Jonathan Latimer

As the resident quotemeister around here, may I exercise my prerogative of commenting on your sigline, which exemplifies a common fallacy among the optimistic.

Bad weather does not cause accidents. Drivers' reactions to bad weather cause accidents. Is there a fundamental difference in the result? The glitch itself cannot do anything but cause an inefficiency in our infrastructure and economy. This degradation in our system can (and does, daily) cause inconvenience. How much inconvenience can or will people tolerate before they respond inappropriately?

How big is a "hoard of panicking people?" (Congratulations on the correct spelling of panicking.) Viewing a complex system bordering on instability, one only needs to have a way of determining the trigger point beyond which a system destabilises at an increasing rate. As soon as we know, or if we ever determine, this point, we can then make a more accurate assessment. Then the next question is: Where is the next point of stability? 1973 equivalent? 1929? 1900? 1750?

Y2K is not JUST a technical problem or a management or economic or social problem. It is ALL of the above, combined in intriguing and complex ways. And that is the reason so many sincere, aware and intelligent people are having such difficulty deriving a reasonable prognostication.


"We have put the egg of civilization in one basket, woven from the fibers of virtual reality, suspended by an electrical cord." --- Allen Comstock

-- Hallyx (, March 23, 1999.

Y2K General Articles:,6158,2213323,00.html idx.html col=NX&kt=A&ak=news1486,4,31727,00.html? cgi/...=all&TemplateName=predoc.tmpl&setCookie=1 ml,5859,2209104,00.html ews,6158,2206553,00.html y2k_5.html idx.html

PSYCHOLOGY,6158,2217402,00.html nc/1301hpd4.shtml l< /P> 6256713003D958F

(No hyperlink) Honolulu Advertiser 2/25/99 Y2K: a big worry only if we make it so

(No hyperlink) NY Times Feb 9, 1999 'Fear of the Year 2000 bug is a problem,too by Barnaby Feder

(No Hyperlink) Millennial Cults ad the Concerned Christians by Michael Shermer, Skeptic mag

(No Hyperlink) Time for Kids The Year 2000 Bug Special January 15th, 1999

(No Hyperlink) The New York Times national Report 01/24/99 Doomsday Machines by James Gleick

The above hyperlinks were prepared in less than 5 minutes with the following method:

  1. Select and copy the text to Word97
  2. Hit enter at the end of each line
  3. Save as HTML
  4. View Source
  5. Find & Replace quote+greaterthan with quote+greaterthan+carat+p (this avoids most of the text breakup but will not be saved on exiting view source)
  6. Select text within the opening and closing BODY tags, Copy
  7. Paste into response window.

-- Jon (, March 23, 1999.

Thanks Hal,

As far as the .sig goes, unfortunately we do seem to live in the age of the sound byte :) and I had a difficult time condensing everything down to it. I am terrible with one sentence statements. I am a fairly adept speller. Your tag at the end of your post was good, too; it reminded me of Robert Heinlein's "The earth is too small and fragile a basket for the human race to keep all its eggs in."

However, I stand by the tag. I understand what you are saying about drivers and hurricanes, and the point is well taken. However, hurricanes are real, quantifiable things. We have lots of experience with them, and have reasonably good ideas on how to deal with them (i.e. Don't drive in a hurricane.) Y2K is similar. We don't know the absolute specifics about the problem, but we can make some pretty good estimated guesses based on similar, albeit smaller, examples from the past.

Comparing Y2K to a natural disaster is not a fair assessment of the facts. Nature breathes in rhythms we can barely comprehend, and her wrath is much more dire than any computer problem. Having lived through Iniki, which was merely the briefest glance at Nature Pissed Off, I can say this. Nature is Way Bigger than us.

As far as Y2K being not just a technical problem or a management or economic or social problem, but all of the above, that is strictly up to you and me. The technical problem is there but work is getting done fairly efficiently. Management always has problems (IMHO) and Y2K will be no different, but in spite of that if the technical problems get fixed the management prolem becomes a moot point. The social problem is every person's decision and responsibility. Howard Rubin phrased it best in the NYTimes: "The level of disaster is still fundamentally our choice."

Couldn't say that to any hurricane. :)

Thanks for your comments, I appreciate them.


-A computer glitch will not cause the end of civilization. It STILL takes hordes of panicking people to do that.-

-- Jonathan Latimer (, March 23, 1999.

There are many points - on both sides - that could be expanded upon and/or corrected. At this time I would like to offer one correction and post a viewpoint.

"In 1979 Bob Bemer, the man credited with the creation of ASCII and coining the word "Cobol", wrote an article warning of potential difficulties resulting from the omission of the 19. "

With all due respect to Bob Bemer, he did *not* coin the word Cobol. Well maybe he coined the "word" Cobol, but not the Acronym "COBOL" which is analogous to the term "COmmon Business Oriented Language" which, by the way, was coined by the late Admiral Grace Hopper - The "mother" of COBOL.

Viewpoint - It appears that no matter who you are, or what side of this fence you stand on, there is the air of distrust for opposing viewpoints. For every view here, I can counter with another, links and all. But I won't waste my time. You see it becomes a matter of dignity when someone counters with their own viewpoint at the very least. If your idea(s) are radical to any degree - you will be summarily stood up and verbally shot. The Internet is a great place to get information - unfortunately it is equally as easy to place false information here. Of course, someday, someone will "link" to these false words and tout them as "FACT". I am not saying that it is all false, or all fact - what I am saying is it would be prudent to use a little common sense when reading some of this information. Consider the fact that "Good news does not sell..." This means newspapers, magazines, websites (that rely upon hit rates to appease sponsors) et al, are suspect of printing what does sell. Bad news!.

I will expand this diatribe to say that I hold any website, magazine, newspaper and newsletter, suspect if they, in any way, support the sale of Y2K survival Gear / supplies.

Yours in COBOL... Dino!

-- COBOL Dinosaur (, March 23, 1999.

Thanks, Jon!

I hadn't realized that the post down here should be in HTML, the other board I posted it to did it on the fly. Once it was posted I couln't edit it (darn it! :) and so there was a bunch on non-linked links. Anyhow, thanks for doing that, and the nifty instructions! :)


-- Jonathan Latimer (, March 23, 1999.

Moderation questions? read the FAQ