' Re: Washington Water Power
'From:
kiyoinc@ibm.XOUT.net (cory hamasaki)
di 22:35
Subject:
Re: Washington Water Power
On Tue, 20 Oct 1998 13:43:22, karinoliver@my-dejanews.com wrote:
> When a company remediates for Y2K they assess, repair, and test. All these
> articles that I've been reading say that they plan to finish their
> remediations this year and do testing next year.
They're just funning with you. The people in IT know that it takes a
long time to implement, test, fix bugs, reimplement, retest, etc. the
systems so they picked a very long period of time for the test cycles, a
full year.
That's why the code is supposed to be fixed by December 1998. December
1998 is magic because we think of a year as a long time and everyone
knows it will take a long time to test the code.
The problem is, some systems take two or three years to implement and
shake down, others take only 3-4 months.
There's no way to really tell but I've seen large packages, documented,
shaken down by multiple other installations, take more than a year to
drop into production.
There are people who study these issues in the abstract, Capers Jones,
Larry Putnam, Ed Yourdon... I'm a hands on code-head, I'm the guy with
the sledge hammers called ASMH, IFOX00, AMASPZAP... I can blow in to a
shop, chat it up with the other gear-heads, PDSUTIL the libs, IDCAMS
print some files, AMBLIST the libraries and tell you whether the system
will make it or not. I might run GTF one morning, take a look at RMF
but in a couple days, I'll know if you're burning up the CEC, outa MIPS,
pedal to the metal or if things are mismanaged.
> Now it takes a set amount of time to do the actual remediation, correct? If
> upon testing, you discover that you haven't caught everything, and it still
> goes blooey, then don't you have to do the remediation again? Granted, you
> won't have as much to rewrite, but you still have to find it. I would think,
> then, that the time allotted for testing would have to be at least the same
> time period as for the remediation, if not twice as much, just to be safe.
> If you managed to catch everything, you'd be fine, but how many remediation
> projects in IT exist where that has happened? So basically, that would mean
> that unless everyone is suddenly blessed with perfection, chances are we're
> screwed.
Yes 'n no... the done by December 1998, leaving all of 1999 for testing
is an artifact of the public relations people and the idiots in the
corner office. Don't take it to mean anything.
Here're the facts. In large complex systems, you don't know what you'll
find when you pop the hood. The job could be smooth or it could be a
horrid mess. The really bad problems are very likely just surfacing
now. These are lost source code, code that resists modification, dates
in VSAM keys of terabyte files... or be still my heart, BDAM with date
keys and assembler XDAP IO... or how about RSCS mods.
There are shops with source tied to old compiler versions and operating
systems. Upgrading any part will force upgrades of other components.
There have been a couple cites of these cascade upgrades in c.s.y2k.
If the shop is lucky, and they started a couple years ago.... and
they're actually sliding the last brick into place this December 1998.
They might be able to complete their testing in 1999. That's assuming
that they have their time machine, that the staff doesn't bail, and
there are no fundamental conflicts uncovered in testing.
.but it's a matter of the luck of the draw now...
> I am not a programmer, so perhaps I've made some assumptions that are
> incorrect, and I welcome any programmers to correct my thinking in this
> matter.
You haven't really made an error... other than, maybe, buying into the
idea that the schedules mean something. In general, not enough
time was allocated, the schedules are unrealistic, and the work will not
be done.
There are a few companies that are in fair shape. I'm tracking a few
that should make the deadlines. I expect the December 1998 and January
1999 time period to be very interesting.
cory hamasaki 437 days, 10,496 hours.
|
