Gary North's Y2K Links and Forums - Mirror

Summary and Comments

(feel free to mail this page)


Category: 

Personal_Computers

Date: 

1997-07-28 15:59:42

Subject: 

Will Every Business Take These Steps?

Comment: 

Prof. Echols of Creighton University describes in detail what it takes for any firm that uses PCs to see if it will survive y2k. This list is so detailed that we can be sure that very few businesses will do this. If they do, very few vendors will respond.

Remember: there are an estimated 300 million PC's out there.

* * * * * * * * *

Any y2k compliant upgrade scenario must have all of the following elements present to avoid severe negative consequences:

1. For ANY software package still being used by a business, the original developers of the software must still be in business (including the developers of the original DOS programs).

2. If the software developer is in business, they must invest research and development dollars to determine which of the previously sold software packages are not y2k compliant, and take corrective actions required to make them compliant and then invest the development dollars to create the compliant version, both for currently selling packages, and for software packages which no longer generate any sales dollars nor will EVER generate any future sales because the 16 bit machines they run on will never again be sold - EVER.

3. For the currently sold software, the developer must do all of the diagnosis and development work of item 2, then, the software developer must contact all of the users who are currently running the software and inform them of the upgrade. In order to accomplish this developer initiated diagnosis and upgrade option, the developer must have the names, addresses and/or telephone numbers of the entire installed base. Most shrink wrapped software is sold through wholesale or retail intermediaries and no record is kept linking the original manufacturer to the ultimate user.

4. In the event the developers do invest in diagnosis and compliance, BUT the avenue for making such information available to the impacted users is not practical or not initiated by all developers, the only alternative solution path is for the users to initiate action. For this to be successful the following must take place:

a. The user has to know that they are currently dependent on the ABC company's canned package XYZ version 1.2 - that is, the user must know that they run version 1.2 (not 2.0 which is compliant). They also must know the developer company name, address and a contact, for every software package and every version of every software package currently being used on every PC used within their entire organization world wide. That is, they must have a complete inventory of every version of every package on every PC in to know what to ask each vendor about in the first place and to know what action is required if and when they do get the y2k compliant version.

Note: It is virtually certain that no organization of an size in the entire world knows name, vendor and version of EVERY software package running on EVERY PC in the organiztion.

b. Once the users knows what they are dependent upon, they must contact the original vendor for action status. The State of Washington has been doing precisely this for the past year and as of this date, 38% of the largets 136 software developers have given NO RESONSE. This says nothing about the thousands of past and present software developers who have written PC software since the early 1980s.

While I certainly am not in the Chicken Little camp, I am firmly of the mind that the information and decision processes required to avoid severe negative consequences are not in place, and that indeed, the debate is not sufficiently focused at this time to deal with the issues in PCs before January,2000.

Michael E. Echols Ph. D. Executive Director Creighton Institute for Information Technology and Management and Chairman of the Board Double E Computer Systems


Return to Category: Personal_Computers

Return to Main Categories

Return to Home Page