One company's real life Y2K problems
>Date: Thu, 29 Oct 1998 08:11:48 -0500
>To: korn.general@umich.edu
>From: "Bernard A. Galler" <galler@umich.edu>
>Subject: One company's real life Y2K problems
>
>
>>Date: 28 Oct 1998 04:17:45 GMT
>>From: Blake Leverett <bleverett@nospam.worldnet.att.net>
>>Subject: Real Life Y2K failure
>>
>>Here is a real-world example of a Y2K failure. A buddy of mine (call
him
>>"Jim") is the network administrator at a small (8 Mill/yr
sales) company.
I
>>can't say the company name, so if you are going to whine about how
I am
>>making this up, don't bother reading on. But I am familiar enough
with
the
>>situation (I know some other people there) to know that he is not
making
>>this up. It is a manufacturing company.
>>
>>"Jim" warned the company management over a year ago that
the company's
>>software would self-destruct in October of 1998 because of the year
2000
>>bug. It looks out 15 months into the future and although the software
is
>>configurable, it can't be configured to look ahead for a shorter
time
>>period. The software is an old DOS package, and it's not Y2K compliant.
It
>>runs everything from manufacturing documentation to accounting,
payroll
and
>>accounts payable included.
>>
>>The company management dragged its feet until March. Finally, after
"Jim"
>>threatened to quit, they decided to shell out the $100K or so it
cost for
>>new software. Months of work followed by both the software vendor
and
"Jim"
>>to make the switchover happen. Well, here it is the end of October,
and
the
>>new system isn't up yet. They started too late, so the old software
is
>>still running, and is peeking over the Y2K boundary.
>>
>>There have been problems. The database files get scrambled on a
daily
>>basis. "Jim" has to edit these files manually with a hex
editor to fix
>>them. The headers get screwed up, and he uses a hex editor to
side-by-side
>>compare the old (good) file with the new (screwed) file. Then he
guesses
>>what to edit to make it limp along for another 4 hours. Sometimes
the
files
>>can't be repaired, and the lost data must be re-entered from paper
copies
>>(if any exist).
>>
>>The real kicker came the other day when they ran Accounts Payable.
They
are
>>a wee bit behind on their AP, so they paid out partial payments
to many
of
>>their vendors. A total of $150K worth of checks was printed, and
promptly
>>mailed. Shortly thereafter, the system crashed yet again. The record
of
>>the latest checks was lost. Since a large number of vendors were
paid,
they
>>now have no idea of what they owe to any vendor. It effectively
destroyed
>>all records of their AP.
>>
>>Y2K is serious. This little manufacturer is wasting lots of time
fighting
>>Y2K problems (100 man-hours this month so far), and is losing money
from
>>lost information. And they are in good shape - my friend "Jim"
saw this
>>coming and insisted that the problem be fixed at great expense to
the
>>company. He is a big asset to the company, so they listened when
he
>>threatened to quit. If he were mediocre, they probably would have
called
>>his bluff. They will be ready (supposedly) on November 1st. But
there
are
>>THOUSANDS of similar small companies that haven't shelled out big
bucks
for
>>a fix. They will start seeing problems soon. And the problems will
get
>>worse and worse as more routines look past 1/1/00.
>>
>>Although this company is experiencing lots of computer problems,
the
>>customers have yet to find out. The customers can only interact
with the
>>company via telephone with the sales or service departments (or
www), so
>>internal problems are easily concealed. But their efficiency and
>>effectiveness has been reduced significantly. And it has cost them
dearly
>>both to fix the problem and to not have it fixed in time.
>>
>>I hope this provides a small example of what Y2K can do. Computers
are
>>boring and unimportant devices - until they quit working. There
are very
>>few companies that can survive for long without their data.
>>
>>Blake Leverett
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------------------------
-
>>POLITECH -- the moderated mailing list of politics and technology
>>To subscribe: send a message to majordomo@vorlon.mit.edu with this
text:
>>subscribe politech
>>More information is at http://www.well.com/~declan/politech/
>>-------------------------------------------------------------------------
-
>>
>
>
Bernard A. Galler
E-mail: galler@umich.edu
Fax: 734-668-9998