To: Technologyguy who wrote (7448 ) 7/30/1999 11:01:00 PM From: Jim Read Replies (4) | Respond to of 9818
Technologyguy, I wouldn't bother trying to reason, or have a discussion with Ken. I stopped responding when he made a reckless comment that pacemakers might not work next January. When he refused to identify the hospital that gave him the information, he responded with a personal attack on me to shift the focus of the argument ie. the best defense is a good offense. I'm also surprised that his sexist remarks ie. "wifey material" have not upset the female posters to this thread. Anyways, here is why I am not worried about Y2K problems next January: 1. Computer Hardware Failures: Being in the computer business, I have tested every old computer I can find (286, 386, 396, Pentiums etc.) by setting them to 31Dec99 at 23:59 and letting them cycle over to the new year. I have YET to find a computer that does not work when the year rolls over to 2000. They also reboot with the correct new date (except for old DOS machines which needed to be reset with the date each time anyways). I really question these Y2000 software tests that are on the market, because they ALWAYS fail and suggest you buy a special board to fix the "problem". Has anyone else had a computer fail when rolling over the year? 2. Computer Operating Systems I understand that Windows 95 and 98 are not Y2K compliant. My staff tells me that we use none of the features that could cause a problem, and if we did, patches are available. It reminds me of the uproar over the Pentium bug when they first came out that gave an incorrect answer for some obscure mathematical calculation which only scientists would be using. 3. Computer Application Software The only applications that are affected are those which are date sensitive and which have a design flaw in which only two positions were used for the year field. Since on average, a business changes their computer software every seven years, hopefully most of the year sensitive software has been replaced with compliant software. This is very easy to check by changing the date to 2000 and testing the software (after a good backup of course). The banks still have mainframes running Cobol, but they have been in the forefront to become compliant (and to ensure their customers are compliant as well). If some software is not compliant, this will cause a reporting problem next January. There are reporting problems all the time, as new or modified systems are implemented. These are fixed in the normal course of business and the reports or application re-run. This is why you are seeing some computer problems when Y2K fixes are not working when first implemented. 4. Embedded ChipsUNLESS THE CHIP OR SYSTEM HAS SOME WAY FOR THE USER TO SET THE YEAR AFTER A BATTERY OR POWER FAILURE, THERE IS NO WAY THE CHIP OR SYSTEM CAN BE PRONE TO Y2K FAILURE. I have checked with some electrical engineers, who assure me that this statement is correct since a chip may not be "burned" with date / year logic. If you accept this premise then it is obvious that 1. chips in concrete or under the sea cannot have a Y2K problem, and 2. it is very easy to identify those chips or systems that need checking ie. if the year must be re-entered after a power failure. This is why alarm clocks will not have a problem, but VCRs might. I would be very interested to know if any believe the above statement to be incorrect, because I base my comfort level on this premise regarding embedded chips. So.. here is a chance to perhaps convert a "polly" by showing me where I am wrong about the above four points.