|
|
|
|
Link to slides used for this paper as presented at the conference. They are in Acrobat PDF format.
Silicon Graphics 655F Lone Oak Drive, Eagan, Minnesota 55121
darason@sgi.com
The Year 2000 problem is a major challenge that all organizations are facing. We at Silicon Graphics-Cray Research want to assist you in achieving complete compliance well in advance of the December 31, 1999 deadline. Silicon Graphics-Cray Research is dedicated to resolving the Year 2000 issue on all currently supported and future systems.
This paper details Cray PVP (parallel vector processing) and MPP (massively parallel processing) products that will be Year 2000 compliant and the testing that was done to find problems. Silicon Graphics hardware and software support for Year 2000 compliance is documented separately. See http://www.sgi.com/Technology/year2000.
Silicon Graphics-Cray Research defines a product to be Year 2000 compliant if it does not produce errors or experience loss in functionality as a result of the transition to the year 2000.1
The capability to input and output four-digit years and correctly interpret and support two-digit years has been present in Cray UNICOS operating environments for many years, and most UNICOS compatible applications are already Year 2000 compliant. Silicon Graphics-Cray Research will continue testing new products for compliance based on the above definition.
All currently supported Cray PVP and MPP systems are Year 2000 compliant. There is a known boot problem with CRAY J90 IOS-V based systems which may be encountered during Year 2000 testing only if a reboot or power cycle occurs (see the VME boot PROM information below). Operational software that runs on the OWS/SWS/MWS and I/O Subsystems are Year 2000 compliant. The underlying operating system for these workstations and subsystems may not be Year 2000 compliant.
Table 1 shows the initial operating system releases providing Year 2000 compliance for Cray Systems that will be supported in the year 2000.
| Hardware | Year 200 Compliant Operating System | Targeted Operating System Release Date |
|---|---|---|
|
CRAY T902 |
UNICOS 10.0 |
November 1997 |
|
CRAY C90 |
UNICOS 10.0 |
November 1997 |
|
CRAY J903 |
UNICOS 10.0 |
November 1997 |
|
CRAY Y-MP(E)4 |
UNICOS 9.0.2.8 |
March 1998 |
|
CRAY T3E |
UNICOS/mk 2.0.2 |
February 1998 |
|
CRAY T3D |
UNICOS MAX 1.3.0.6 |
December 1997 |
Customers with CRAY T90, CRAY C90, and CRAY J90 platforms should upgrade to the UNICOS 10.0 operating system in 1998 or 1999 to prepare for Year 2000 compliance. UNICOS 9.1, 9.2, and 9.3 releases on these platforms are not Year 2000 compliant.
Note: Most CRAY Y-MP(E) and CRAY T3D service contracts will expire before the year 2000. For CRAY Y-MP(E) and CRAY T3D customers who would like to have support beyond their contract expiration date, Silicon Graphics-Cray Research will only provide support for Year 2000 compliance issues. Those customers who would like to have support for Year 2000 compliance issues beyond their contract expiration date should contact their local Silicon Graphics-Cray Research service representative for an extended service contract.
The CRAY J90 IOS-V based systems have been found to have a problem relating to the year 2000. An updated IOS-V kernel fix is currently available for sites with Model V based systems that have upgraded to UNICOS 10.0 or UNICOS 10.0.0.1 to address Year 2000 problems that have been identified with the IOS-V software. UNICOS 10.0.0.2 and beyond will contain this fix, so application of the IOS-V kernel fix package will not be needed if using a newer version of UNICOS.
First the booting of the IOS-Vs and the Cray mainframe are dependent upon the time on the J90 Console. By default the J90 Console will properly provide the time in a format that the IOS-V(s) can use when going to PROM mode or when the IOS-V(s) are loading the IOS-V kernel.
The time command when the IOS-V(s) are in PROM mode does not properly handle the year 2000. If the IOS-V is in PROM mode and passes from Dec. 31, 1999 to Jan. 1, 2000, the output of the time command will be:
If the IOS-V(s) are reset during the year 2000 or beyond, the PROM time command will produce something similar to the following output:
While the PROM time command does output the incorrect time this does not affect the taking of an IOS dump, nor the loading of a new IOS-V kernel.
If a site takes an IOS dump while in PROM mode, the time stamp of the IOS dump will be taken from the J90 Console and not the IOS-V and it's internal time.
If a site loads a non Year 2000 compliant IOS-V kernel, the date being provided by the time command will produce some incorrect output:
This will impact the booting of the CRAY J90 Model V mainframe in that the time being passed to the Cray mainframe will need to be changed when going to single-user mode.
While the PROM does produce the incorrect output, the PROMs for the Model V based systems are not being replaced since a software fix has been created. This fix has been tested to verify the correct time is passed to the Cray mainframe during booting to single-user mode.
Cray software products that will be actively supported in the year 2000 will be tested and updated to meet Year 2000 compliance requirements.
All the asynchronous products that will be supported in the year 2000 will have a Year 2000 compliant release available by the end of June 1998. For example, the following release levels (and later releases) will be Year 2000 compliant:
| Product | Release Level | Targeted Release Date |
|---|---|---|
| DMF | 2.5.4.4 | Released |
| MPT | 1.1.0.4 | Released |
| CVT | 3.1 | Released |
| CRL | 2.0.9 | Released |
| Programming Environments CF90, C++ (including Standard C) | 3.0.2 | Released |
| NQE | 3.3 | Released |
As is normal with software support, releases supported today might not be supported years from now. Year 2000 compliance does not alter standard support policies or the duration of the software support.
Year 2000 support does not apply to retired products and features. Bugs in retired software, such as date display errors or improper leap-year calculations, will not be fixed. This includes operating systems, compilers, libraries and asynchronous products. For example:
The MVS station was scanned for Year 2000 bugs and no major errors were found. The VMS station was not scanned. If errors are found in any station products, they will not be corrected. Replacement products for stations (FTA, NQE, RQS, and FES) are Year 2000 compliant. Customers should plan to move to these alternate solutions.
CF77 and Standard C programing environments will be retired prior to the year 2000.
If Year 2000 bugs are found in retired compilers or libraries, they will not be fixed, but alternatives are usually possible. For example, if a retired CF77 or Standard C library were to return an incorrect date, the application code could be modified to compensate or the code could be recompiled with Year 2000 compliant CF90 or C++ (including Standard C) Programming Environments.
Testing focused on finding any date related problems that affect our systems not just the ones related with the year 2000 problem. To do this we defined a number of possible problem date related areas (I call date epochs) and focused on these. Of these date epochs the ones in bold I will refer to as "major date epochs."
The date epochs that were defined are ;
In general two approaches to testing were used to find date related problems and for year 2000 compliance. First, all the source code was examined using automated tools to find date related errors. Second, all systems and products that we tested were tested for each of the date epochs mentioned.
A script examined all source code to find possible year 2000 problems. The scripts used can be found at: www.sgi.com/Technology/year2000/yr2k-scan_tool.html.
The following are some of the more important items for which the script looked:
Problems reported by these scripts were examined and fixed. The scripts are currently run on a regular basis to help prevent new problems from being released.
When doing system testing, we ran the systems in either dedicated mode or open batch mode, and in some cases with UNICOS under UNICOS (UuU) running. We used a CRAY C90, CRAY T90, CRAY J90, CRAY T3E, and CRAY T3D systems in the testing. During testing the systems used (Cray mainframe, OWS/SWS, and file systems) were connected to our entire campus network.
The following are highlights of the testing and verification performed on these systems. This is not a complete list of everything tested, for this information see our Year 2000 web site for a list of compliant products:
We have been working on the year 2000 problem since early 1997. During this time we have rolled the system date hundreds of times without incident.
The systems used in testing (Cray mainframe, console, and file systems) were connected to our entire campus network and did not cause any sort of problem.
A number of problems relating to the date epochs have been found, fixed, and tested. The problems found would have been classified as major and below using the current SPR guideline.
Silicon Graphics-Cray Research is committed to supporting you throughout the Year 2000 conversion and beyond. Please visit our Web site at http://www.sgi.com/Technology/year2000.
Bruce Schneider in Silicon Graphics-Cray Research Product Management is the designated contact for Year 2000 compliance for Cray systems. If you need additional information on CRAY PVP or MPP Year 2000 issues, please contact your Silicon Graphics-Cray Research sales representative or Bruce Schneider at <bcs@cray.com> or (612) 683-5365. For IRIX Year 2000 issues, please contact Addison Snell at <asnell@engr.sgi.com> or (650) 933-5712. Silicon Graphics-Cray Research looks forward to doing whatever we can to simplify your Year 2000 transition.
UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Limited.