IP: There's no Y2K-fix there...

[Dave Farber <farber () cis upenn edu>]

Date: Wed, 29 Dec 1999 10:55:46 -0800 (PST)
From: John Wharton <jwharton () netcom com>
Message-Id: <199912291855.KAA15414 () netcom com>
To: farber () cis upenn edu
Subject: Re: Early victories?
X-UIDL: 392e4876e67be24a51dca10ba6a846ff

Dave--
I just now saw the John Locke-Wheaton posting on Y2K credit-card handling
that ended, "Let's hope that none of the other bugs are life threatening."
It looks like Oakland officials have their act together -- now -- but you
might want to include a preface to my "911" message pointing out that --
unchecked -- this WOULD have been a most-life-threatening oversight.
(Or you could just repost this addendum, suitably re-titled.)
--John Wharton


> Date: Wed, 29 Dec 1999 10:47:58 -0800 (PST)
> From: John Wharton <jwharton () netcom com>
> To: farber () cis upenn edu
> Subject: There's no Y2K-fix there...
>
> Dave--
>
> KCBS radio is reporting this morning that the Oakland 911 Emergency call
> system has determined its call prioritization algorithm is, well,
> technically speaking, /not/ fully Y2K compliant yet.
>
> Apparently incoming calls are timestamped with just a two-digit year code.
> Normally the call routing software gives top priority to the oldest
> (=earliest) calls, as one would expect.
>
> Alas, this means that as of the Friday midnight roll-over, all pending
> calls will instantly be kicked to the bad end of the priority list.  As I
> interpret the news reports, the post-rollover calls will be stamped
> 1/1/1900, and, naturally, anyone who "just" called -- at 11:58 Friday
> evening, say -- is in far less dire straits than people who have been
> on hold for nearly 100 years.
>
> Oakland's solution, the 911 officials say, will be that, starting at
> 11:50pm or so, all not-yet-dealt-with calls will be transferred to a
> different phone system to ensure that they don't get lost.  Dispatchers
> can then continue dealing with existing emergencies while newer calls
> queue up normally until dispatchers again become available.
>
> (The moral?  It's probably best /not/ to have an emergency in Oakland
> during those last few minutes before midnight...)
>
> =====
>
> My first impression was that this was a terribly embarrassing oversight,
> for this problem not to have been "fixed" months ago.  Date-stamps being
> processed backwards is /exactly/ the textbook example of what happens
> when the year field overflows.
>
> On the other hand, it /does/ seem the problem will be terribly short-lived,
> affecting maybe five or ten minutes' worth of calls -- ever.  After 12:10am
> or so, then, and for the remainder of the next century, the original call
> prioritization algorithms should continue to work just fine.
>
> Whereas re-opening the program source, rejiggering the code, augmenting
> the data structures and so forth could quite plausibly introduce new
> problems and incompatibilities that might bedevil emergency call
> processing for months.
>
> Leading one to wonder: was this just an embarrassing oversight?  Or a
> deliberate, rational cost-benefit decision to leave sleeping codes lay?
>
> Happy Holiday, Dave.  Knock wood.
>
>   --John Wharton


******************

A Happy Holiday and a safe New Year

from Dave and GG Farber

******************