Year 2000 Compliance

Year 2000 Issues...

ISL Software Certification

This table collates the Year 2000 Compliance status of ISL software. Also included is a statement of the Year 2000 Conformance and Testing Rules, and an outline of the principle problem topics.

Software Title	Version	Status	Certificate
Tube Sheet Diagram	v1.30d	Compliant.	Certificate
Floormap Graphic Software	v1.11	Compliant.	Certificate
PowerTube - Database	v1.09	Compliant.	Certificate
PowerTube - Diagnostics	All versions	Compliant.	Certificate
PowerTube - Forecast	All versions	Compliant	Certificate
PowerTube - Strategies	All versions	Compliant	Certificate
PowerTube - Tempest	All versions	Compliant	Certificate
PowerTube - Wall-Map	All versions	Compliant.	Certificate
Quality Document Developer	All versions	Compliant	Certificate
Dinsley Devices DinSearch 200	All versions	Compliant	Certificate

Definition of Year 2000 Conformity...
"Year 2000 conformity shall mean that neither performance nor functionality is affected by dates prior to, during, and after the Year 2000."

Year 2000 Compliance Rules...

Rule 1:	"No value for current date will cause any interruption in operation."
Rule 2:	"Date based functionality must behave consistently for dates prior to, during, and after Year 2000."
Rule 3:	"In all interfaces and data storage, the century in any date must be specified either explicitly or by unambiguous algorithms or inferencing rules."
Rule 4:	"Year 2000 must be recognised as a leap year."

Sources:
Action 2000 Millennium Bug Campaign Fact Sheet #10
BSI DISC PD2000-1

Background to the Y2K Problem
In essence, the Year 2000 issue has arisen because computers (until quite recently) used 2-digit year codes to store dates, instead of 4-digit codes, e.g. 98 instead of 1998. Over the years software was also written to process dates in this 2-digit format, and much of the data that these programs generated was stored in 2-digit format.

The Y2K problem will show itself when computers attempt to process the dates after 31 December 1999... systems may accredit some dates with an incorrect century, e.g. systems which are not Year 2000 compliant might interpret years such as 2001, as 1901; conversely years such as 1993 (saved as 93) might be interpreted as 2093.

Year 2000 compliance issues must address four main topics...: 1. Hardware... the ability of the users computer(s) to make the midnight transition into 2000 successfully,
2. Software... the ability of programs to assign the correct century during data input, output, and searches,
3. Archived Data... the updateing of databases archived with the 2-digit year formats.
4. Embedded Systems... identification of evaluation of all systems which possess embedded date/time hardware.

The following notes briefly summarise each topic. (ISL is concerned mainly with Item 2 - Software compliance).

1. Hardware Compliance: Many older computers will fail to make the transition successfully. However, computers which fail are unlikely to crash, though they may revert to a system date of 1 January 1980 or 4th January 1980... and such a change may affect software running at that time. There are several free programs currently available which will automatically supervise the transition and make the necessary corrections. Even if these programs are not used, manually resetting the computers' system date may overcome the problem. Alternatively, an upgrade to the computer BIOS may be possible, or the computer may need to be used only for non date-sensitive applications, or in the extreme, de-commissioned.
2. Software Compliance: In new software applications the Y2K issue will (probably) have been addressed already, although certification from the vendor should be sought.
For programs that are still being serviced by their developers, then an upgraded version may be required... again certification from the vendor should be sought.
Obsolete programs or operating systems, i.e. programs that are still being used successfully, but which are no longer supported by their suppliers, may need replacement. The potential for disruption when transferring from an obsolete system to a current version should not be under-estimated.

3. Archived Data Handling: Data that has been stored in 2-digit year codes must either be re-processed to convert it to 4-digit codes, or must be addressed only by a program that can unambiguously recognise its correct century.

3. Embedded Systems: Any systems that use internal 'chips' to perform timing functions to control external events, may be vulnerable to the problem. Users should identify every system that could incorporate such chips, and should seek advice from the manufacturers or vendors to determine their compliance.

An Action 2000 information pack relating to the Millennium Bug Campaign is available...
UK hotline: 0845-601-2000
Web: http://www.bug2000.gov.uk