Hi Jim. I thought that your posting show some interesting thinking. You do a good job of explaining your position. But, I disagree on some of your points.
1. Computer Hardware Failures:
I pretty much agree with you on this point, with one exception / concern. Some PC will reset to 1980 or 1984 when they try to reboot after their clocks have rolled into 2000. If they lose power causing them to shut down temporarily, they will reboot with the incorrect date. Some of these PC are setup to transmit data to other systems and the system date is sometimes included in the transmission. This could cause problems on the system that receives the data.
In the organizations that I have seen these systems in, the PCs are usually older models. They have been running, usually trouble free, for years and are often overlook when doing Y2K remediation and testing. They could even be completely overlooked because no one has touched it in years.
Any problems that occur in this area will probably not be immediately apparent. It shouldn't cause any major problems but could be a “headache” to track down.
2. Computer Operating Systems
Again, I agree that the problems with Windows 95 and Windows 98, and Window NT for that matter, are not that serious. Most can be easily worked around or a patch is available from Microsoft that will fix most of the problems. But, there are many other operating systems and a lot of systems level software that has Y2K problems.
The organizations that I have been working with have had to upgrade almost their entire inventory of systems software: Operating systems, DBMS's, Language compilers and a variety of utilities. There are “growing” pains associated with each of these upgrades. Some of this systems level software has been customized to fit a particular need and the customized feature may not be available in the upgraded version, resulting in the loss of this functionality.
Overall, I don't think that operating systems and system level software are going to be a big problem, especially in organizations that have made the necessary effort to upgrade. But, since we are a global economy and many countries around the globe have been dealing with more pressing matters, I believe that these upgrade may have been put on the back burner, and this will cause problems, including system crashes without viable “work-arounds”.
3. Computer Application Software
This is the area that I work in, and I know that there are going to be problems with application software. What I don't know is how serious the problems will be. I completely disagree with your statement: 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.
I have been programming for about 25 years, and in that time I only worked on one system that was designed to be Y2K compliant. As a consultant, I am often brought in to help organization upgrade their application software. These upgrades never included upgrading the system to be Y2K compliant… until Y2K came onto the corporate radar. One project that I worked on 4 years ago even specifically instructed me to NOT make the system Y2K compliant because they had a Y2K team that was going to fix all of their system. Interestingly enough, I ended up on the Y2K team that went over all of the code.
You sure make testing sound easy: This is very easy to check by changing the date to 2000 and testing the software (after a good backup of course). While this may be true of stand-alone systems running on PCs, mainframe testing of large systems is quite another matter. The company that I am working for has spent a year and a half testing their system, and they still aren't finished. We are finding about 6 to 10 errors per system in the remediated code.
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). Indeed, banks probably are in the forefront, but who is bringing up the rear. Governments and large / medium sized companies use mainframes extensively and many are seriously lagging in their Y2K projects. Imagine the repercussion if the IRS fails next year. If the IRS can't process tax receipts, social security won't have money to pay the social security recipients. No money coming in, no money going out.
If some software is not compliant, this will cause a reporting problem next January. If reporting problems next January were the only problems that non-compliant software causes, then we would be very lucky. If the reporting problems are caused by corrupted data, then it may seem like a “reporting” problem to the people receiving the report, but the data will still be corrupt. Fixing corrupt data may not be easy, especially if it is not caught very quickly. You not only have to fix the data, you have to identify and repair the source of the corrupted data.
4. Embedded Chips
I believe that you have over simplified the embedded systems problem. Systems can get the time from the airwaves. My VCR downloads the time from the airwaves after it looses power. Systems can also get the date from the GPS satellites or from a network. The user input does not have to take place at the actual embedded system.
But my biggest concern with embedded systems is that we don't know where all of them are located. Many small businesses don't even know about the embedded systems problem. If we don't know where they are, we can't fix them.
I think of the GPS rollover as a subset of the embedded systems problem and will use the GPS rollover on August 21-22 as an indicator of the size of the embedded systems problem. GPS is only 20 years old and many GPS manufacturer's newer model take this rollover into account. But, have all of the problem GPS systems been fixed, replaced or accounted for by some other means. If any problems occur because of the GPS rollover, then I don't think that the embedded system problem will be repaired. This will also be a good test of company contingency plans.
Jim, even though you are a self proclaimed “Polly”, I sincerely hope you are at least thinking about what contingency plans you should have, just in case.
Personally, I have three plans in place. One for a BITR to a 2-3 year recession scenario, one for a recession to 10 year depression scenario, and one for a catastrophic scenario. None of my preparations will be wasted. For the most part, all that we are doing is storing larger quantities of items that we would use anyway.
B.K. |
