Loading ...
Sorry, an error occurred while loading the content.

[urb-eco] Can anyone refute this?

Expand Messages
  • Bagelhole1@aol.com
    The possibility of infrastructure rupture is NEVER too remote to ignore, but it is no more a possibility on 1/1/2000 than any other day. This is the last 2
    Message 1 of 1 , Aug 8, 1999
    • 0 Attachment
      "The possibility of infrastructure rupture is NEVER too remote to ignore, but
      it is no more a possibility on 1/1/2000 than any other day."
      This is the last 2 lines of Lee's argument. I put it here so that you may
      know a little of what this discussion is about.

      >Dear Lee,
      > I don't want to take up your time quibbling about small things.
      >in the interest of a fair discussion, that should hopefully lead to a
      >understanding, I ask that you either agree or refute the simple logical
      >conclusion I sent you below. Speculation about what might or might not
      >happen, doesn't interest me. But if the following is wrong, then I may be
      >wasteing my time, I would hope that you would show me what I am missing.
      ><<>Assumption 1: All computers and embedded chips will not be fixed by
      >>Assumption 2: No one can know what percent of non-compliancy it would take
      >>set off some form of collapse of the infrastructure.
      >>Conclusion: The possibility of infrastructure rupture is not remote enough

      Assumption #1 is correct. All computers will not be fixed on time.
      However, from there the logic breaks down, although I can understand why
      people who aren't involved with computers might think that #2 and #3 would
      be true.

      There are 3 misconceptions that people have about the Y2K problem that make
      it seem as if your assumptions would be logical:

      1) That all computers and embedded chips are vulnerable to the Y2K bug
      because they all have internal clocks, 2) that many computerized systems no
      longer have manual backup procedures, and 3) that if a computer with a Y2K
      problem has not been fixed, it will fail or crash altogether.

      All three of the above statements are false under the circumstances we're
      discussing - that is, critical infrastructure like the power and water grid,
      train systems, medical equipment, communications satellites, etc.

      First let's look at myth #1. It's true that all computer systems have
      internal clocks, and those clocks are capable of tracking the date.
      However, a programmer has to go out of his way to make a computer aware of
      the date. All a computer's clock does is measure sequential time in
      milliseconds. It does math based on that. For example if a pacemaker has
      to give your heart a jolt of electricity every 3 seconds, it just counts out
      3000 pulses of the clock, does its task, then starts again for another 3000.
      It has no clue what the time or date is. The programmer would never have a
      reason to give it that information.

      If an application DOES have to keep track of the date, a day is likewise
      however many milliseconds equal a day. At that point the computer's clock
      increments the date. This is called a "Julian Day Number". Just as an
      example, most personal computers use January 1, 1900 as the beginning of the
      Julian calendar - day number 00000 (they decided in the case of PC's to
      standardize on 5 digit Julian dates). So at the end of each 24 hours the
      clock just increments another number. Under that scenario, December 31,
      1999 is day number 36525, and January 1, 2000 is day number 36526. Nothing
      special. Just another day. A computer may *display* a date in the format
      MM/DD/YY, but in the types of applications we are talking about
      (infrastructure), very few store their dates that way internally, which is
      what would cause a problem on 1/1/2000. Satellites, power plants, train
      systems, and the like use this Julian calendar, not the Gregorian calendar
      that we are used to thinking of, which is the only type of system that would
      be affected.

      The types of computer systems that do use Gregorian calendars are *business*
      applications. Your power company's billing department might have some old
      systems with Y2K problems. In that case, you might get a bill saying you
      are 100 years overdue! But this is obviously an error and will not cause
      system rupture - just headaches for the poor folks who have to straighten
      out the billing problem. Businesses may lose money because their reporting
      or billing is inaccurate, but that's hardly the end of the world.

      Now let's look at myth #2. Most people think that many infrastructure
      systems that are computerized have no manual backup. People like Gary North
      have really worked hard to scare people by telling them things like the
      trains will stop running because train systems are computerized and there
      are no longer any manual switches on many lines. This is completely false.
      Talk to any actual railroad line foreman and they will tell you there are
      manual switches and they have to use them all the time. Nobody builds
      critical systems like these without manual backup, for the simple reason
      that (like I said earlier) computer systems crash *every day.* Some of the
      problems with them are harder to find and fix than Y2K. Right now, I'll bet
      there's at least one embedded chip or system down somewhere in your power
      grid and you'll never know it. ALL critical systems have manual backup.
      Again, the people who will be affected by the problem are mostly businesses
      who are running non-critical systems. If somebody's online store crashes,
      it might be disastrous for their business but not for the world at large.

      Now we'll talk about the last myth: that "non-compliance" equals complete
      failure. It doesn't. All a Y2K bug means is that the system doesn't know
      the correct date. This could be a drag in the case of something like your
      bank, which might calculate the interest wrong on your mortgage. But the
      computer won't lose your balance or any other data. The only thing it will
      lose is the ability to do date related calculations correctly. In any case,
      banking systems have been compliant for a long time because they've had to
      deal with loans that won't expire till after 2000 ever since 1970. Social
      Security and Medicare have to deal with beneficiaries born in the 1800's, so
      they've had 4 digits in their dates too.

      So, to figure out whether Y2K is going to cause major infrastructure
      rupture, the questions need to be asked really are:

      1) What percentage of computers are running critical infrastructure?
      2) Of that percentage, how many use the Gregorian date system?
      3) Of that percentage, how many will fail if they don't know what day it
      4) Of *that* percentage, how many do not have manual backup procedures?

      Based on what I've told you, I hope you can see that the final number you
      would arrive at is infinitessimally small. In fact, just as big on that day
      as any other day. A Julian clock is like an odometer on your car - when it
      will become inaccurate depends on when it was set, how much you drive your
      car and how many digits the odometer has. Lots of Julian clocks on older
      systems have already rolled over, and that can happen on any day.

      Even the financial systems that some people have worried about are not
      having many problems. You know, the fiscal year 2000 started on July 1 of
      this year. Lots of wags predicted major losses for banks and other economic
      problems on that day. Nothing happened that anybody noticed. The next day
      that people worry about will be September 9th, because a lot of programmers
      used to enter 9/9/99 as an indicator that a process should continue
      forever - not realizing that some of their systems would still be in
      operation on that day! I'll wager nothing much will happen on that day
      either, at least that you or I will be able to discern. Sure, there'll be
      some frantic programmers working overtime to fix it. There may be some
      hassles and headaches, some lost business, some lawsuits. But Armaggedon?

      The possibility of infrastructure rupture is NEVER too remote to ignore, but
      it is no more a possibility on 1/1/2000 than any other day.
    Your message has been successfully submitted and would be delivered to recipients shortly.