Found two Y2K bugs in two seperate applications today. What is worse is they are programs I wrote and remediated. One involved age analysis of backorders. Sure enough it choked up on a Feb. 2000 scheduled ship date. The second involved year 2000 kill dates on the internal order entry / inquiry / AR message system. Yep 00 was less than 99 and was rejected because the kill date was less than the message entry date. Fortunately it took only a few minutes to find each bug and correct it.

Calm down folks, I don't work for a power plant, refinery or chemical plant. Also this is not second hand.

-- Ed (ed@lizzardranch.com), December 15, 1999

Answers

Damn, a couple minutes each!! Lets get you an SR71 and some No Doze and start flying you around the world hitting the hotspots after rollover!

-- Guy Daley (guydaley@bwn.net), December 15, 1999.

Hi Guy,

The difference between what Ed did in this case and what many others have to do is familiarity. Ed was thoroughly familiar with programs he had written (and recently gone through for remediation), so knew exactly where to look when the problems occurred.

A "few minutes" in this case could be anywhere from 10 minutes to 2 days, depending on the size of the system involved. The original run time (which probably had to be re-run) counts toward the time to find the bug, then there's actually finding the bug in the program, making the source code (I assume) changes, then recompiling and testing (and documenting, if needed).

The very smallest production (not sample or class exercise) program I've done took around 10 minutes for these steps. Mainframe-level programs usually take a few days for the process.

-- Dean -- from (almost) Duh Moines (dtmiller@midiowa.net), December 16, 1999.

Yup, the vast majority of software problems take five minutes to fix. But six weeks to find. :)

But really... :(

-- Servant (public_service@yahoo.com), December 16, 1999.

A WHOLE BUNCH of people around here would be totally snowed if you dropped the typical production program listing and abend listing on their desks.

First, they would have problems believing tht the program compile was actually 2" thick. then readinmg the abend report/dump would be interesting. Then translating this into where in the listing the instruction that blew up is executed, and then figuring out the error in logic....

the ONLY reason these errors were found in about 10 minutes each is because you could read the listings with or without lights because of familiarity with them.

Congrats.

chuck

-- Chuck, a night driver (rienzoo@en.com), December 16, 1999.

I even wrote code that had year 2000 problems just last year. I tried to use a zero as an end of input and the input was a year. Slapped my forehead and shouted, "D'oh!", then fixed it.

-- Tim the Y2K nut (tmiley@yakko.cs.wmich.edu), December 16, 1999.