The extent of corporate vulnerability to PC failures is seen in this letter.
* * * * * * * * *
From: "Richard Dale"
Date: Tue, 30 Dec 1997 10:16:39 +0000
Subject: Year 2000 Assessment PC/Client Server Software
I have been given the task of assessing all of the PC and Client Server software used by my UK company for Year 2000 compliance. These are mostly US packages. Our business is the supply of IT services to major companies. The result was that of 216 PC packages and inhouse applications 51 require either replacement or repair to attain Year 2000 compliance, approx 24% are non-compliant.
Who said it was just a mainframe problem? The more you delve the worse it gets. Most of these packages were developed or certainly upgraded several times within the past 5 years or so.
Many of the packages that need upgrading have been declared non-compliant by the supplier therefore it is difficult to know just what is the extent of the problem (whether minor cosmetic date display problems through to total failure). However I would think that a supplier would not produce an upgrade for Y2000 if there were only minor problems. On the other hand they may be playing safe for fear of litigation. Some packages have extensive features that are not necessarily used by everyone, the suppliers aren't telling us just where the problems are so we'll probably never know. Often date processing is more or less completely transparent even to expert users, eg it is impossible to tell whether communications software for instance has dates, however almost every comms package produced by a well-known supplier is non-compliant.
The sorts of problems we have found are as follows:
System does not accept 21C dates due to use of YY and lack of windowing
21C dates displayed as rubbish eg 01/01/2001 shown as 01/01/0100
Cannot search on Year 2000 dates by operand GT/LT due to use of YY
Special (hardcoded) use of date fields eg 9700 YYMM to signify a condition
No proper validation of date fields, eg accepts 0000 YYMM
Cannot report data over the turn of the century
Cannot sort data into correct date sequence
For Start End Selection - End Year YY of 00 not accepted as being greater than Start Year YY 97
In terms of numbers, most of the 216 packages are bought in. We do use a few larger systems bought in but enhanced internally in some cases.
We have tried to assess a product when it is considered to be of high business priority however we have written to the supplier in each case, if they say it is non-compliant we obviously don't bother to try to test it. We also have many other packages which we have not bothered to assess, since they are of low priority. Failure of these will not have any significant business impact. For all new purchases we are demanding a compliance statement from the supplier.
We have found that many types of software are non compliant eg
Comms/LAN
Netware
Accounting
Server File back-up
Virus Checking
DB enquiry
Booking systems
It would help if all suppliers put compliance statements on their websites. There is a chance that package users will be OK in the year 2000 assuming that they check every copy of software including the version. There is time to arrange for an upgrade within the next 2 years if users start assessment immediately. For large companies (especially in the US) with many individual copies or networks this could be a major problem but soluble. Incidentally I have previously worked on a Year 2000 mainframe project which fortunately is on target for completion by mid 1998, but only because they started in 1992 and used offshore programmers. This was at a well-known UK Composite Insurance Company.
Richard_Dale@figroup.co.uk
|