The Co-Intelligence Institute/Y2K Return to Y2K home RETURN to CII home

One company's real life Y2K problems

>Date: Thu, 29 Oct 1998 08:11:48 -0500
>From: "Bernard A. Galler" <>
>Subject: One company's real life Y2K problems

>>Date: 28 Oct 1998 04:17:45 GMT
>>From: Blake Leverett <>
>>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.
>>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
>>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.
>>runs everything from manufacturing documentation to accounting, payroll
>>accounts payable included.
>>The company management dragged its feet until March. Finally, after
>>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
>>to make the switchover happen. Well, here it is the end of October, and
>>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
>>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
>>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
>>a wee bit behind on their AP, so they paid out partial payments to many
>>their vendors. A total of $150K worth of checks was printed, and
>>mailed. Shortly thereafter, the system crashed yet again. The record of
>>the latest checks was lost. Since a large number of vendors were paid,
>>now have no idea of what they owe to any vendor. It effectively
>>all records of their AP.
>>Y2K is serious. This little manufacturer is wasting lots of time
>>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
>>THOUSANDS of similar small companies that haven't shelled out big bucks
>>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
>>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 with this text:
>>subscribe politech
>>More information is at

Bernard A. Galler
Fax: 734-668-9998