  |
|
|
|
All of these problems get compounded by the degree to which most large computer systems are networked and interdependent. Even extra-enterprise systems can cause losses for a company; If your widgets need titanium lugnuts and the lugnut supplier thinks that it's 1900, you won't be getting any lugnuts and will be unable to produce widgets. Banking systems are particularly sensitive to this kind of crash as there are hundreds and thousands of nodes in their networks; Consider how many Interact / Credit Card / Automated Teller systems are in place now! If the software (or firmware) in any one of these systems is not working properly it can cause problems anywhere in the network.
The latter touches on an important aspect of the problem. There is no definitive answer to a manager's question of "what will happen to my program?" The all-encompassing answer is that it depends. Some operating systems will default back to their creation date (1990 for MS-Windows 3.1; 1980 for Ms-Dos machines). Some programs will do the same, or interpret the year as 2000. Others still will work sporadically and output random data. Some will crash altogether. Some other applications are based around a client server model. The server may be able to be modified to cope with a larger year field, but the client programs, often off-the-shelf, cannot be modified and in many cases are no longer supported! The problem, then, is very subjective and ambiguous - there will be no quick fix. "For once in our lives," says de Jager, "it doesn't matter the size of the project, how many resources, how much money you have - the deadline is fixed." -- Peter de Jager, Year 2000 Consultant, quoted from Datamation magazine References Solutions to the Year 2000 Problem: By Stephen Manley Go To Page: 1
The copyright of the article Networking: Multiplying the error in Software Re-engineering is owned by . Permission to republish Networking: Multiplying the error in print or online must be granted by the author in writing.
|
|
|
|
