'150 days until the first battles begin'
Some insights from Cory.
John
______
Subject:
Re: Early indicators predict extent of y2k??
Date:
18 Jun 1998 13:51:53 GMT
From:
kiyoinc@ibm.XOUT.net (cory hamasaki)
Organization:
HHResearch Co.
Newsgroups:
comp.software.year-2000
References:
1 , 2 , 3
On Thu, 18 Jun 1998 03:54:34, "Jim Abel" <evolutioninactio@usa.net> wrote:
> After yesterday's stupidity I hardly dare speculate about anything
> mathematical, but what the hell.
Jump in, Jim.
> It should be a relatively valid assumption that, if the engineers who
> created the system built date dependencies into it, they also devised a
> manufacturing or configuration protocol which included the necessary steps
> to set it correctly. Assume that this is incorrect in a "very" small number
> of cases. That would mean systems failing now from rollover problems would
> probably be "beneath the noise level" of failures from other causes.
>
> OTOH, there should be a bell curve of failures resulting from initial
> settings off by a few minutes one way or another. I'd guess it would be
> aggravated by oscillator variations over a period of years. And then we have
> to take the time zones into account.
The above is a bit too abstract for me. I'm still thinking about
Frank's solar moonshine still (Solar, moon; sun... moon? Sun Young
Moon... Frank's a Moonie!) and hot tub.
> So maybe, sometime in late December next year, the curve of rollover
> failures will rise above the noise level. Over the next few (several? many?)
> days the primary rollover failures will occur. Maybe the curve will be
> averaged by the variables into some simple 2 or 3 step bell curve. Maybe it
> will spike and drop as large non-compliant populations pop all together.
> Whatever the shape, it will probably be over by the 2nd or 3rd of January.
My guesstimate is that fiscal year 00 will be a minor problem. The
failures... and I'm speaking strictly IT, heavy metal, enterprise scale,
these failures will follow the 000197AF model. During December 1998,
that's this year not next, the systems that frame transactions into
calendar year 1999 will begin testing the wall at January 1, 2000.
They do this by asking the question, is this record before January 1,
2000. The systems will hold a transaction or record in one hand and
probe at the wall with the other, is this more or less, if less, then
mark it for processing, else mark it for deletion or put it in a bin to
be looked at later.
This logic error will cause queues to fill, records to be lost, and grit
tossed into machinery that has run for decades without error. In
January 1999, more systems will touch the wall, more odd things will
happen.
In some cases it will take 3-6 months of gradually decreasing revenues
and complaints of delayed billings, shipments, before anyone notices...
Well, except that like tm_year, I'm tipping you consultants off now.
Those of you with loyal clients, start examining these issues now. The
CY1999 problems are more specific than the CY2000 problems and we have
to get these locked down in the next 150 days. That's identified, fixed,
tested, and back in production in time for December 1998.
By spring 1999, all remediation will cease. The IT pro's, Oxley,
Secor, Shmuel, Infomagic, :Dave, (and other's ... darn I need to start
building a list of heavy-hitters I can call on.) the pro's will be
150% busy finding and fixing CY1999 Y2K problems. We'll be in crisis
recovery mode, it won't be a simulation, and all the clueless nubies and
5 week remediation wonders will just be in the way.
But the crisis of CY1999 will be nothing like the real thing, CY2000.
The CY2000 problems start in December of 1999 as the systems encounter
the first of the 2000 data items.
Yes, I know; the non-IT'ers aren't following this. Speaking just to the
non-IT'ers, your confusion has the same basis as your belief that "Banks
are OK because they wrote 30 year mortgages in 1970" and 30+70 = 100.
That one specific case has nothing to do with the thousands of other
cases. That one case might be a few dozen lines in a subsystem of a few
tens of thousands of lines of code... printing, projections, etc. Trust
me on this one, I was right about tm_year, I'm right about this one.
We have until December 199eight to fix a specific class of Y2K failure.
This might be a only a few tens of thousands of lines in a typical
corporate inventory.
The general problem is a million lines in an inventory of twenty million
lines. In CY2000, all million lines will be doing something wrong...
and it's only 5% of the inventory of a multinational bank or
corporation.
> The wild thing is, if things get really bad, we may never know the real
> events that take place. We'll just see their results over the next month or
> two.
>
> Jim Abel
With only 150 days to the preliminaries, I advise the heavy-hitters to
get lots of rest, line up pals to help you when production fails. Start
streamlining your life so that you don't have a lot of distractions. Fix
up your office, get some nice CDs to listen to while you work. Tell
your spouse or life partner and dependents that you will be very busy
and may not have as much time for them but you will think about them,
call them regularly (if you are on a remote assignment) and somehow,
somehow in spite of horn-haired managment, denial-heads, we will make it
through this mess.
I've started organizing the information that I'll need for crisis
recovery. Rexx's, C/C++ template programs, my Wizard's Books (the IBM
FE handbook, MVS data areas, green card), my HP-16C has new batteries.
I also spent an hour uncrating manuals last weekend, I have old IMS and
TCAM manuals, NOMAD (I have a spare set.)
Did you know that IBM in its wisdom moved the IEB utilities into the
DSDF bookshelf instead of putting them with the JCL manuals in the base
MVS shelf? I've spent hours looking for IEBPTPCH.
Brrrrr. I'm glad I get paid by the hour.
cory hamasaki 651 days left
150 days until the first battles begin
51 days to complete Triage planning.
(private note to Frank: Gunaxf sbe orvat tbbq angherq nobhg gur grnfvat.
Zl fpurqhyr vf gb gnxr n pbhcyr qnlf n zbagu bss, zbfgyl zvq-jrrx,
arkg gvzr lbh'er orgjrra pbagenpgf, znlor jr pna trg gbtrgure va JI.) |
