Novell Year 2000 Testing
Articles and Tips: article
01 Dec 1999
Novell defines "Year 2000 Ready" as the ability of our software products to accurately process date data from, into, and beyond the years 1999 and 2001, including leap year calculations, when used in accordance with the product documentation, provided that all products (e.g. hardware, firmware, software) used in combination with Novell software, properly exchange date data with it.
This page provides a brief description of the criteria used in testing Novell products. See http://www.novell.com/year2000/for more information.
This document is a guide to assist in creating Year 2000 testing. It does not contain specific test cases or methods of testing. Due to the diverse nature of software environments Novell cannot recommend methodology or implementation procedures. If you require technical assistance creating or implementing Year 2000 testing please contact a consultant familiar with your software applications and environment.
Year 2000 ready testing of Novell products should be done in a test environment only, not in a live production environment.
Moving time forward for testing then backward again to perform another test or to reset to the current time on a NetWare server requires the generation of a new Epoch to resolve "future" timestamps in the NDS database. Declaring a new Epoch sends ALL NDS objects to all holders of NDS replicas which, depending on the tree design, has been known to require excessive network bandwidth while the new Epoch information is distributed.
A similar caution is in order for testing GroupWise. If purge or archive rules are created by the user or administrator and the date of the client machine or server is advanced to test for Year 2000 issues in a production environment, the purge or archive rules may be invoked and GroupWise mail, appointments, tasks, etc., may be permanently erased.
Novell's 10 Requirements for Year 2000 Readiness
Novell has identified ten Year-2000 and other date-related requirements for its products. These requirements are listed below:
Correctly displays dates up to the year 2035. This includes debugging, logging, and diagnostic information that may be used by other programs.
Correctly treats the year 2000 as a leap year.
Correctly calculates the day of the week for all dates from 1980 to 2035.
The calendar arithmetic must correctly count time durations between any two dates from 1980 through 2034. This includes, but is not limited to, the following critical dates:
Friday, December 31, 1999
Saturday, January 1, 2000
Monday, February 28, 2000
Tuesday, February 29, 2000
Wednesday, March 1, 2000
Sunday, December 31, 2034
Monday, January 1, 2035
In addition, the difference between 01/01/1980 and 01/01/2035 should calculate to 20,089 days.
The product or business application must sort dates in proper chronological order for any collection of dates from 1980 through 2034.
The product or business application must treat "dates and durations" intended to mean "no date" or "never" explicitly. Specific attention is directed to 9/9/99.
For each product or business application: Wherever a time stamp is stored in binary, the time stamp must be tested for rollover to zero or rollover to negative to ensure proper handling. All time stamps used for dates must have sufficient capacity to function properly during the years 1980 through 2034 without ambiguity.
For each product or business application: Any file format used as input to a subsequent process must be scrutinized and the subsequent process analyzed to ensure proper operation of the combined functionality from 1980 through 2034.
For each product or business application: Any file format that is changed as a result of these requirements will be supported by documentation describing the migration from the old format to the new format. Programs that manipulate the new format must also tolerate the old format.
Any wire protocol that is changed as a result of these requirements will be supported by documentation describing the migration from the old wire protocol to the new wire protocol. Servers or clients that use the new protocol must be able to tolerate the old protocol as well. If two devices must exchange times or time stamps and only one of them is capable of the old format, the newer device must be capable of supplying the old format.
This information is provided "AS IS" without any warranties. Novell expressly disclaims any warranties or representations as to the accuracy or completeness of the contents and expressly disclaims any implied warranties of merchantability or fitness for a particular purpose. The contents are not suitable for use in all situations, and any use by you of the contents is at your own risk. Readers are advised this information is updated from time to time as new data is available. Novell will not be liable for damages of any kind, including direct, consequential (including loss of profits, business, or data) or special damages, which may arise out of or result from reliance on or use of this information.
Novell makes no warranty or representation regarding any third-party products; such products are provided "AS IS." Users interested in the Year 2000 readiness of these products, or corresponding warranty information, should contact the respective third-party product manufacturer.
This document is a Year 2000 Readiness Disclosure under the United States Year 2000 Information and Disclosure Act.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.