Year 2000 Overview
Bull recommendations for the last night of 1999

This process is based on:

• Bull Assistance 2000 services with fully dedicated organizations at country and headquarters levels to answer and fix all Year 2000 related questions and problems submitted by customers

• Crisis management teams (at headquarters and country levels) composed of top management representatives to make the right decisions at the right time on procedure adaptations, staffing adjustments, budget allocations, and priority reassignments in order to optimize the time and accuracy of responses to customers’ queries.

In terms of prevention, extensive tests have been conducted (and continue to be conducted) by the Bull engineering teams and by our partners where we have included their products in our offerings.

These tests have been performed successfully for the "Year 2000 ready" products listed in our Compliance Catalog available on the Web at: www.bull.com/year2000

Definitions

Note: The following definitions have been extracted from our Compliance Catalog.

Year 2000 Ready

Products identified in this Catalogue as "Year 2000 Ready" are Products which are capable of correctly identifying, manipulating, and performing calculations on dates later than December 31, 1999, and which have been tested as such, provided they are used in accordance with their associated documentation and provided that when they are linked up to other components, such components factor in the calendar date on the same conditions as, and are compatible with such Products.

The term "Year 2000 ready" is not used as a trademark or a tradename of product or services but as a litteral expression to define a technical status of our product.

Not Year 2000 Ready

Products identified in this Catalogue as"Not Year 2000 ready" are Products for which Bull does not make any statement that they will be capable of correctly identifying, manipulating, and performing calculations on dates later than December 31, 1999.

In certain cases, after a preliminar study and diagnosis, Bull may provide support for such products .

Recommendation for the Year 2000 transition

We should recall that an Information System is composed of:

• its infrastructure (Hardware platforms with their operating systems and system applications, the associated peripherals, the network and associated stations, terminals and network equipment, …) and
• the customer’s applications.

Both must generally be adapted (renovated) to the Year 2000 problem.
The applications are very often connected through various type of networks to suppliers’ applications: we may not have full confidence in the quality of their renovation, increasing thus the risk of failure during transactions.

Speaking of software, Year 2000 analysts such as Gartner Group suggest that 8 to 15% of renovated code and 5 to 9% of renovated and tested code will still have remaining defects likely to cause inaccurate data or failure.

If these figures are even half-correct, a significant number of failures will occur on renovated code mostly during 4Q1999 and 1Q2000 with a possible peak during the last night of 1999.

Bull products

Based on the amount and scope of testing done by its engineering, Bull can state that there is no need to reboot its main "Year 2000 ready" platforms running GCOS 8, GCOS 7, AIX or HVX Operating Systems and associated "Year 2000 ready" system software, across midnight of December 31^st. This statement has been verified during qualification cycles and live test scenarios.

Nevertheless, due to experience over the years (very few software projects are entirely bug free), and in order to limit the risk of failure and its corresponding impact on the whole Information System, we recommend:

• limiting system activity to the minimum necessary;
• limiting the number of connected users to only those mandatory at this point in time;
• saving Databases and data files before the date change.

User applications

In case of doubt on the applications, and if it is decided to stop them, two scenarios can be used:

• synchronized and chronological stop of the applications
  • almost simultaneous stop of the applications

The first scenario may insure data consistency without flows waiting: the 1999 processes are executed in 1999 and the saves can be done safely. But this scenario may need several days to be run, and also requires the securing of exchanges synchronization (stop and restart) not to mention re-implementing in 2000 the actions performed manually during the stop of activities.

The second scenario may appear drastic but its impact can be reduced if the applications are stopped for only few minutes (15 to 30 minutes).

In both scenarios, if the systems are to be switched off, the interruption should not be long to avoid cooling / re-heating of sensitive components.

Generally speaking,

• if the system is to be switched off, the following actions must be taken:

• stop the applications,
• stop the connections,
• save the data,
• stop the physical components (discs, controllers,…), then
• stop the system itself,

To restart the Information System after midnight:

• switch on all physical components,
• switch on the system itself,
• execute a warm boot ( for GCOS 8, without EDIT and without RESTART),
• start the applications.
• if the system is not to be switched off, the set of actions is the same but without the physical switch off/on.

The major criteria for the selection can be:

• business protection considerations: orders, deliveries, accounting, customer services, … (the overall supply chain)
• feasibility of the necessary actions (time to save, CPU time, …)
• reliability of the solution.

For technical reasons, we recommend the second scenario (again, in case of doubt on the applications). This limits the amount of tests (no need to verify the synchronization or to qualify it between the processes).

Business critical applications and their exchanges are to be stopped at the same time, whereas non-critical applications may be stopped at any time beforehand: this also means that the applications feeding them have to be stopped at the same time, at the very latest.

This allows the saving of the Operating System configuration and its applications environment (without its data) one or two days before, in order to limit the data saving time to a minimum just before stopping the applications.

To minimize the time required for saving large amounts of data, parallel processing, use of fast storage equipment and/or splitting storage over several units may be considered. Also, save procedures need to be seriously checked in order to avoid problems after restoring the data.

Conclusion

In summary, Bull states that there is no need to stop its "Year 2000 ready" systems: the engineering production systems are planned to remain operational throughout the rollover to the Year 2000.

Nevertheless, customers should take their own decision, based on their business risk analysis.

In any case, Bull recommends limiting year-end activities and saving the Information System environment prior to the date change.