For further Year 2000 information from KIC, please contact:

     Year 2000 Office
     KIC Thermal Profiling
     15950 Bernardo Center Dr., Suite E
     San Diego, CA  92127
     858-673-6050
     FAX: 858-673-0085
     Email: y2k@kicmail.com

KIC Thermal Profiling
Y2K Testing for
KIC Software Version 2.3

About the Y2K Test Criteria
Tests 1-5
Tests 6-10
Tests 11-12
Tests 13-15
Tests 16-19
Test 20
Tests 21-22
Tests 23-25
Tests 26-28
Tests 29-31
Instructions for Completing the Y2K Test Response Form
Test Files
A Y2K Hardware Testing Tool for the Customer

About the Y2K Test Criteria

Version 2.0 of the SEMATECH YEAR 2000 Readiness Test Scenarios were chosen as the testing criteria. They were chosen based on their wide recognition and acceptance by industry leaders, some of which include:

AMD	Digital Equipment Corporation	Hewlett-Packard Company
Hyundai Electronics	IBM Corporation	Intel Corporation
Lucent Technologies	Motorola	National Semiconductor Corporation
Philips Semiconductor	Rockwell International Corporation	SGS-Thomson Microelectronics
Siemens Semiconductors	Texas Instruments Incorporated	TSMC

Primary Dates of Concern

These testing scenarios require date testing surrounding six main YEAR2000 dates of concern:

Date	Issue
1. December 31, 1998 to January 1, 1999	Year transition
2. September 8, 1999 to September 9, 1999
3. December 31, 1999 to January 1, 2000	Century transition
4. February 28, 2000 to February 29, 2000	Leap day
5. February 29, 2000 to March 1, 2000	Leap day + 1
6. December 31, 2000 to January 1, 2001	Year Transition

Additional Dates of Concern

Additional dates may present problems with internal business systems or are beyond the scope of this testing. The Software Development Team should also consider these dates when writing and testing the software:

Date	Issue
1. April 10, 1999	99th day of 99th year. May have Julian date implications.
2. January 10, 2000	First time seven positions is required to represent the date.
3. October 10, 2000	First time eight positions is required to represent the date.
4. January 1, 2011	Some Microsoft apps will fail due to the method used to resolve YEAR 2000 issues. (i.e., year > 10 assumed to be in 20th century)
5. January 1, 2030	Some commercial apps will fail due to the method used to resolve YEAR 2000 issues. (i.e., year > 29 assumed to be in 20th century)
6. January 19, 2038	many UNIX based products will fail due to overflow of the integer used to store the date

How the Scenarios are Organized

There are a total of 29 scenarios, number 1 through 31 (test 21 &22 are reserved for future use and not used in version 2.0 of the SEMATECH YEAR 2000 Readiness Test Scenarios). These 29 scenarios are divided into 9 groups. The scenarios in each group are similar but distinct.

ERA

If an individual test results in the expected observations, then ERA (Expected Results Achieved) is used to annotate a passed test.

SECS/GEM

Tests #16-18 verify compliance with the SEMI E5-0698 standard and are do not really diagnose YEAR 2000 Issues. With this in mind, please enter the results of these tests for information purposes. Disregard the test results for tests #16-18 when making the determination of the overall tool status. Test #19 is a YEAR 2000 test and its results will contribute to the overall tool status.

The KIC software does not support SECS-II communication and these scenarios are not performed during testing.

"NOT APPLICABLE"

In some cases, individual tests are not applicable to the particular piece of equipment being tested. In these cases the tester should use the test result NA (Not Applicable). A comment must be added to indicate the basis for determining that the test is not applicable. (e.g. Test # 16 is NA because "Tool does not support SECS/GEM communication" or Test # 20 is NA because "There is no time based purge mechanism")

When reporting test results for a particular tool / software product, if the result for each test is either "ERA" or "NA" the overall tool status should be reported as "Ready Now".

FAILED TESTS WITH WORKAROUNDS

In some cases, an individual test may result in "FAIL" but there is a simple, temporary workaround that will allow the software to be used through one or more of the key date transitions. Because the test resulted in a failure, the overall status cannot be reported as "ready now". Instead:

if there is no plan to provide a future version of the software that remedies the failure, report the overall tool status as Never Ready (NR) and provide comments to explain the workaround.
if there is another software product already available that remedies this failure, report the overall tool status as Upgrade Available (UA) but also provide the comments to explain the workaround for the failed test.
if there is a planned future software release that will remedy this failure, report the overall tool status as Upgrade Future (UF) but also provide the comments to explain the workaround for the failed test.

Tests 1-5

Validate the ability of the Y2K testing platform to successfully set and hold dates after 1/1/2000 and use the appropriate calendar for day of week and day of month.

TEST DETAILS	RESULT OF TEST
TEST 1 - Century Date set and hold Set internal clock to 01/01/2000 01:01:01. Is system date = 01/01/2000? If system has concept of day of week, is day-of-week = Saturday?	ERA
TEST 2 - Leap Day set and hold Set internal clock to 02/29/2000 01:01:01. Is system date = 02/29/2000? If system has concept of day of week, is day-of-week = Tuesday?	ERA
TEST 3 - Leap Day + 1 set and hold Set internal clock to 03/01/2000 01:01:01. Is system date = 03/01/2000? If system has concept of day of week, is day-of-week = Wednesday?	ERA
TEST 4 - Century Date set and hold after reboot Set internal clock to 01/01/2000 01:01:01. Power machine off. Wait 2 minutes. Power machine on. Is system date = 01/01/2000? If system has concept of day of week, is day-of-week = Saturday?	ERA
TEST 5 - Leap Day set and hold after reboot Set internal clock to 02/29/2000 01:01:01. Power machine off. Wait 2 minutes. Power machine on. Is system date = 02/29/2000? If system has concept of day of week, is day-of-week = Tuesday?	ERA

Tests 6-10

Validate the ability of the Y2K testing platform to successfully roll over into year 2000 and leap day 2000 and hold these dates even after a system shutdown.

TEST DETAILS	RESULT OF TEST
TEST 6 - Century Date basic rollover Set internal clock to 12/31/1999 23:59:00. Wait 2 minutes. Is system date = 01/01/2000 If system has concept of day of week, is day of week = Saturday.	ERA
TEST 7 - Leap Day basic rollover Set internal clock to 02/28/2000 23:59:00. Wait 2 minutes. Is system date = 02/29/2000? If system has concept of day of week, is day of week = Tuesday?	ERA
TEST 8 - Leap Day + 1 basic rollover Set internal clock to 02/29/2000 23:59:00. Wait 2 minutes. Is system date = 03/01/2000? If system has concept of day of week, is day of week = Wednesday?	ERA
TEST 9 - Century Date basic rollover with reboot Set internal clock to 12/31/1999 23:59:00. Power machine off. Wait 2 minutes. Power machine on. Is system date = 01/01/2000? If system has concept of day of week, is day of week = Saturday?	ERA
TEST 10 - Leap Day basic rollover with reboot Set internal clock to 02/28/2000 23:59:00. Power machine off. Wait 2 minutes. Power machine on. Is system date = 02/29/2000? If system has concept of day of week, is day of week = Tuesday?	ERA

Tests 11-12

Validate the ability of the KIC software to successfully execute a process that straddles the change from 1999 to 2000 and Leap Day 2000.

TEST DETAILS	RESULT OF TEST
TEST 11 - Century Date with continuous process Create test process recipe with a time parameter = 2 minutes or minimal tool cycle time whichever is greater. Set internal clock to 12/31/1999 23:59:00. Run/simulate process created in step 1. Does process continue to completion? At completion is system date = 01/01/2000? Did process complete successfully in the time specified in step 1?	ERA
TEST 12 - Leap Day with continuous process Use test recipe from TEST 11. Set internal clock to 02/28/2000 23:59:00. Run/simulate process created in step 1. Does process continue to completion? At completion is system date = 02/29/2000? Did process complete successfully in the time specified in step 1 of TEST 11?	ERA

Tests 13-15

Validate the ability of the KIC software to provide equivalent feedback whether it is based on activities before or after the change from 1999 to 2000.

TEST DETAILS	RESULT OF TEST
TEST 13 - Equivalent Feedback without straddle Set internal clock to 12/31/1999 10:10:00. Run a short duration process. Observe and record all feedback (i.e., extract and save a representative sample of screens and reports). Set internal clock to 01/01/2000 10:10:00. Repeat short duration process from step 2. Did the process proceed identically? Is feedback "equivalent"? Does all timestamped information from both sides of the year change sort correctly? (i.e., in most-recent-first sorting order, year 2000 records appear prior to any 19XX records) Does all timestamped information from year 2000 appear with a human understandable representation? (2000 -or- 00)	ERA
TEST 14 - Century Date process with straddle Set internal clock to 12/31/1999 10:10:00. Run a short duration process with a time parameter = 10 minutes or minimum tool cycle time whichever is greater. Observe and record all feedback (i.e., extract and save a representative sample of screens and reports). Set internal clock to 12/31/1999 23:55:00. Repeat short duration process from step 2. Did the process proceed identically? Is feedback "equivalent"? Does all timestamped information from both sides of the year change sort correctly? (i.e., in most-recent-first sorting order, year 2000 records appear prior to any 19XX records) Does all timestamped information from year 2000 appear with a human understandable representation? (2000 -or- 00)	ERA
TEST 15 - Cumulative History Set internal clock to 12/31/1999 10:10:00. Run three short duration processes. Extract and save a representative sample of all historical screens and reports for the time period covering the past 24 hours. Set internal clock to 01/01/2000 10:10:00. Run three short duration processes. Extract and save a representative sample of all historical screens and reports for the time period covering the past 48 hours. Is feedback "equivalent"? Does the feedback from step 6 include all data from step 3? Does all timestamped information from both sides of the year change sort correctly? (i.e., in most-recent-first sorting order, year 2000 records appear prior to any 19XX records) Does all timestamped information from year 2000 appear with a human understandable representation? (2000 -or- 00)	ERA

Tests 16-19

Validate the application�s conformance to SEMI E5-0698 (formerly E5-97). The results of tests 16-18 should be shown for information purposes but excluded when assigning the overall tool status. Results for test 19 should be shown and must be considered in assigning the overall tool status.

TEST DETAILS	RESULT OF TEST
TEST 16 - TIMEFORMAT Equipment Constant ID What is the equipment constant id (ECID) number that the application uses to represent the new indicator TIMEFORMAT?	NA
TEST 17 - TIMEFORMAT request Simulate the SECS-II Stream 2, Function 13 (Equipment Constant Request) using the ECID identified in Test 16. Tool will return a SECS-II Stream 2, Function 14 (Equipment Constant Value). Is returned value = 1? Is returned value = 0? Is returned value = <L> (empty list)?	NA
TEST 18 - Current Time Request Simulate / emulate the SECS-II Stream 2, Function 17 (Date and Time Request). Tool will respond with a SECS-II Stream 2, Function 18 (Date and Time Data). In TEST 17, was returned value = 1? In TEST 17, was returned value = 0 -or- is the TIMEFORMAT ECID unknown? Is response = the current date/time (within a reasonable tolerance) and formatted as YYMMDDHHMMSS? Is response = the current date/time (within a reasonable tolerance) and formatted as YYYYMMDDHHMMSSCC? * Y=Years Digit, M=Months Digit, D=Days Digit, H=Hours Digit, M=Minutes digit, S=Seconds Digit, C=Centi-seconds Digit	NA
TEST 19 - YEAR 2000 Time Request Set internal clock to 10/10/2000 03:04:05. Simulate / emulate the SECS-II Stream 2, Function 17 (Date and Time Request). Tool will respond with a SECS-II Stream 2, Function 18 (Date and Time Data) In TEST 17, was returned value = 1? In TEST 17, was returned value = 0 -or- is the TIMEFORMAT ECID unknown? Is response = 0010100304SS? Is response = 200010100304SSCC? * S=Seconds Digit, C=Centi-seconds Digit	NA

Test 20

Validates the application�s data retention/purge routines.

TEST DETAILS	RESULT OF TEST
TEST 20 - Data Retention during purge Backup all tool data to a secure medium. Set internal clock to 10/10/2000 03:04:05. Execute system data purge routines to remove/archive all data that was recorded on or before last Monday. Is any data from last Tuesday through 12/31/1999 in the purge data log? Is any data from 1/1/2000 through 10/09/2000 in the purge data log? Is any data prior to last Tuesday in the purge data log? Restore data from backup.	NA
Alternate Test if no Purge Data Log is generated Execute steps 1 through 3 above. Retrieve a sample history of activity beginning 30 days ago. Is data from 1/01/1998 through 12/31/1999 in the history of activity? Is data from 1/1/2000 through 11/22/2000 in the history of activity? Is any data prior to last Tuesday in the history of activity? Restore data from backup.	NA

Tests 21-22

Reserved for future expansion.

TEST DETAILS	RESULT OF TEST
TEST 21	NA
TEST 22	NA

Tests 23-25

Validates the KIC software�s ability to properly handle the date transition from 12/31/1998 to 01/01/1999.

TEST DETAILS	RESULT OF TEST
TEST 23 - 01/01/1999 basic rollover Set internal clock to 12/31/1998 23:59:00. Wait 2 minutes. Is system date = 01/01/1999 If system has concept of day of week, is day of week = Friday.	ERA
TEST 24 - 01/01/1999 basic rollover with reboot Set internal clock to 12/31/1998 23:59:00. Power machine off. Wait 2 minutes. Power machine on. Is system date = 01/01/1999? If system has concept of day of week, is day of week = Friday?	ERA
TEST 25 - 01/01/1999 process with straddle Set internal clock to 12/31/1998 10:10:00. Run a short duration process with a time parameter = 10 minutes or minimum tool cycle time whichever is greater. Observe and record all feedback (i.e., extract and save a representative sample of screens and reports). Set internal clock to 12/31/1998 23:55:00. Repeat short duration process from step 2. Did the process proceed identically? Is feedback "equivalent"? Does all timestamped information from both sides of the year change sort correctly? (i.e., in most-recent-first sorting order, year 1998 records appear prior to 1999 records) Does all timestamped information from year 1999 appear with a human understandable representation? (e.g., 1999 -or- 99)	ERA

Tests 26-28

Validates the KIC software�s ability to properly handle the date transition from 12/31/2000 to 01/01/2001.

TEST DETAILS	RESULT OF TEST
TEST 26 - 01/01/2001 basic rollover Set internal clock to 12/31/2000 23:59:00. Wait 2 minutes. Is system date = 01/01/2001? If system has concept of day of week, is day of week = Monday?	ERA
TEST 27 - 01/01/2001 basic rollover with reboot Set internal clock to 12/31/2000 23:59:00. Power machine off. Wait 2 minutes. Power machine on. Is system date = 01/01/2001? If system has concept of day of week, is day of week = Monday?	ERA
TEST 28 - 01/01/2001 process with straddle Set internal clock to 12/31/2000 10:10:00. Run a short duration process with a time parameter = 10 minutes or minimum tool cycle time whichever is greater. Observe and record all feedback (i.e., extract and save a representative sample of screens and reports). Set internal clock to 12/31/2000 23:55:00. Repeat short duration process from step 2. Did the process proceed identically? Is feedback "equivalent"? Does all timestamped information from both sides of the year change sort correctly? (i.e., in most-recent-first sorting order, year 2000 records appear prior to 2001 records) Does all timestamped information from year 2001 appear with a human understandable representation? (2001 -or- 01)	ERA

Tests 29-31

Validates the KIC software�s ability to properly handle the date transition from 9/08/1999 to 9/09/1999.

TEST DETAILS	RESULT OF TEST
TEST 29 - 09/09/1999 set and hold Set internal clock to 9/09/1999 01:01:01. Is system date = 9/09/1999? If system has concept of day of week, is day of week = Thursday?	ERA
TEST 30 - 09/09/1999 basic rollover Set internal clock to 9/08/1999 23:59:00. Wait 2 minutes. Is system date = 9/09/1999? If system has concept of day of week, is day of week = Thursday?	ERA
TEST 31 - 09/09/1999 basic rollover with reboot Set internal clock to 9/08/1999 23:59:00. Power machine off. Wait 2 minutes. Power machine on. Is system date = 9/09/1999? If system has concept of day of week, is day of week = Thursday?	ERA

Instructions for Completing the Y2K Test Response Form

Complete one response form for each software product/version tested. If one version of the software supports several different processing tools, a single response form may be used provided all applicable equipment models are shown.

Enter the name of your COMPANY and, if appropriate, your DIVISION. (e.g., Acme Widgets / Precision Bearings)
Enter the model/submodel of the EQUIPMENT for which the software was tested. (e.g., Mirra-Flow 200E)
Enter the name of the SOFTWARE PRODUCT that was tested. (e.g., Gusto-II)
Enter the VERSION of the software product tested. (e.g., 3.2)
Enter the date that testing was completed
For each YEAR 2000 Readiness test, enter the following:
- The test result ERA (EXPECTED RESULT ACHIEVED), F (FAILED), NA (NOT APPLICABLE), or NC (NOT COMPLETED)
- An explanation for any test that resulted in Fail, Not Applicable, or Not Completed.
  - If FAIL describe workarounds that could allow the software to be used despite the failure
  - If NOT APPLICABLE describe why this test is not relevant to the equipment
  - If NOT COMPLETED describe why this test was not run and what will be done to convert this test result to ERA
Use additional sheets of paper to provide any details that will not fit on the form.
If any additional tests were run to verify the YEAR 2000 readiness of this software version, please describe them on a separate sheet of paper.
Describe the platform on which these tests were executed.
- Identify the hardware processor/motherboard (e.g., Pentium 2, Sun Sparc 2000, etc.)
- Identify the OPERATING SYSTEM (e.g., WindowsNT, Solaris, etc.)
- If tool communication is handled by a separate piece of software, identify the SECS/GEM INTERFACE product and version used.
- Describe any additional platform dependent items that affected the running of these tests. Such subsystems as user interface, RDBMS, networking, monitoring, component/chamber control, etc. software should be named if they are not an integral part of the master control system.
Indicate the next known date (if any) when this software will fail due to date considerations. (e.g., if Unix based, 1/19/2038 will cause problems)
Indicate the Overall Tool Status for the product tested. Summarize the results of tests 1-15, 19-20, 23-31 and assign one of the following overall status:
- Never Ready - One or more of the tests failed and no software version is planned to remedy these failures.
- Upgrade Future - One or more of the tests failed and a future version of the software is planned to remedy these failures.
- Upgrade Available - One or more of the tests failed and a version of the software exists which remedies these failures.
- Ready Now - The software failed no tests and is Year 2000 Ready as is.
Attach or enclose any application documents or data files.
Obtain the signature of a company representative attesting to the completion of these tests. It is recommended that the Vice President of Engineering or equivalent be the signatory.

COMPANY:          KIC Thermal Profiling                EQUIPMENT: NA                          
SOFTWARE PRODUCT: KIC Windows software (a.k.a. WinKIC)   VERSION: 2.3    DATE: April 16, 1999

TEST #	TEST DESCRIPTION	TEST RESULT*	EXPLANATION (IF FAIL, NOT APPLICABLE, NOT COMPLETED)
1	Century Date set and hold	ERA
2	Leap Day set and hold	ERA
3	Leap Day + 1 set and hold	ERA
4	Century Date set and hold after reboot	ERA
5	Leap Day set and hold after reboot	ERA
6	Century Date basic rollover	ERA	Refer to Test6.kdf
7	Leap Day basic rollover	ERA	Refer to Test7.kdf
8	Leap Day + 1 basic rollover	ERA	Refer to Test8.kdf
9	Century Date basic rollover with reboot	ERA
10	Leap Day basic rollover with reboot	ERA
11	Century Date with continuous process	ERA	Refer to Test11.kdf
12	Leap Day with continuous process	ERA	Refer to Test12.kdf
13	Equivalent Feedback without straddle	ERA	Refer to Test13A.kdf, Test13B.kdf, Test13C.txt
14	Century Date process with straddle	ERA	Refer to Test14A.kdf, Test14B.kdf, Test14C.txt
15	Cumulative History	ERA	Refer to Test15A.kdf to Test15F.kdf, Test15G.txt
16	TIMEFORMAT Equipment Constant ID	NA	Tool does not support SECS-II communication.
17	TIMEFORMAT request	NA	Tool does not support SECS-II communication.
18	Current Time Request	NA	Tool does not support SECS-II communication.
19	YEAR 2000 Time Request	NA	Tool does not support SECS-II communication.
20	Purge	NA	There is no time based purge mechanism.
23	01/01/1999 set and hold	ERA	Refer to Test23.kdf
24	01/01/1999 set and hold after reboot	ERA
25	01/01/1999 with continuous process	ERA	Refer to Test25A.kdf, Test25B.kdf, Test25C.txt
26	01/01/2001 set and hold	ERA	Refer to Test26.kdf
27	01/01/2001 set and hold after reboot	ERA
28	01/01/2001 with continuous process	ERA	Refer to Test28A.kdf, Test28B.kdf, Test28C.txt
29	09/09/99 set and hold	ERA
30	09/09/99 basic rollover	ERA	Refer to Test30.kdf
31	09/09/99 rollover with reboot	ERA

TEST PLATFORM
*Processor / Motherboard:*		Pentium 90
*Operating System:*		Windows 95 4.00.950
*SECS/GEM Interface:*		NA
*Other:*		Data acquired from the following:
		KIC TPU

NEXT EXPECTED DATE RELATED FAILURE
01/19/2038

OVERALL TOOL STATUS
[ ] Never Ready		[ ] Upgrade Available
[ ] Upgrade Future		[X] Ready Now

*TEST RESULTS
ERA	Expected Results Achieved	NA	Not Applicable (Explanation)
F	Failed - (Explanation)	NC	Not Completed (Explanation)

Company representative attesting to these results:

       President            Philip C. Kazmierowicz      Philip C. Kazmierowicz  04-26-1999 
         Title                   Printed Name                  Signature / Date

Test Files

Note: TestALL.exe is a self-extracting archive containing all other test files listed in the table below.

Test6.kdf 89KB	Test7.kdf 89KB	Test8.kdf 89KB	Test11.kdf 82KB	Test12.kdf 81KB	Test13A.kdf 82KB
Test13B.kdf 81KB	Test13C.txt 1KB	Test14A.kdf 150KB	Test14B.kdf 150KB	Test14C.txt 1KB	Test15A.kdf 589KB
Test15B.kdf 589KB	Test15C.kdf 589KB	Test15D.kdf 589KB	Test15E.kdf 589KB	Test15F.kdf 589KB	Test15G.txt 1KB
Test23.kdf 89KB	Test25A.kdf 150KB	Test25B.kdf 149KB	Test25C.txt 1KB	Test26.kdf 89KB	Test28A.kdf 150KB
Test28B.kdf 150KB	Test28C.txt 1KB	Test30.kdf 89KB	TestALL.exe 453KB

A Y2K Hardware Testing Tool for the Customer

Is your personal computer ready to handle the 21st century? You can't be sure unless your system is properly tested. National Software Testing Laboratories, a division of The McGraw-Hill Companies, has developed a program that can definitively tell whether a personal computer system will handle the transition to the next century.

Software and operating systems retrieve the date from the computer. If the computer does not support the 21st century, neither will its software.

This program tests the personal computer's ability to support the year 2000, not the operating system or software applications. Separate testing must be performed on software [The SEMATECH criteria is used to test the software].

The term "personal computer" in this document refers to any x86 based "industry standard" computer that contains a built-in real-time clock. "Industry standard" itself refers to IBM compatible or clone. In general, this applies to personal computers built since 1985. Operating systems are meant to include all flavors of DOS and Microsoft Windows.

How the Computer Clock Works

Every personal computer contains two clocks - a built-in hardware clock and a virtual clock. The hardware clock (real-time clock) runs whether the system is on or off. The virtual clock (system clock) is set to the real- time clock when the computer is turned on and exists only while the computer is operating. While the computer is up and running, the two clocks run independent of each other.

The system clock is a 24 hour timer and has no real concept of days; whereas, the real-time clock tracks the time and date. In fact the system clock has no concept of traditional hours, minutes, and seconds. It merely increments a counter 18.2 times per second. The operating system, which is dependent upon the system clock for the time, converts the counter into hours, minutes and seconds. As for the date, the operating system, during initialization, reads the real-time clock via the BIOS then tracks the date independently based on the virtual system clock rolling over midnight.

For some reason, the real-time clocks used in today's personal computers do not track centuries - only years, such as '96, are tracked. When the next century occurs, the real-time clock merely indicates year '00. It is the BIOS's responsibility to track the century and preserve that information in the real-time clock's nonvolatile CMOS memory.

The BIOS assumes that the years 1900 through 1979 cannot occur, so when the year is within 00 - 79 and the century information is 19, the BIOS should set the century information to 20. If the BIOS does not track the century, the operating system will be given an invalid year and most likely will assume 1980. (Microsoft operating systems do not support dates earlier than 1980.)

Caveats

Since the two clocks run independently, the real-time clock can be set to any nonsensical value while the system is running and the operating system will not notice. Such will occur January 1, 2000 if your system does not support the year 2000 and it is left on. As long as the system is running, the operating system will correctly support the occurrence of the year 2000. Problems will occur, however, when the system is rebooted or powered off then on. This is the first caveat -- Setting the date and time just prior to the year 2000 and just letting the new year occur is not a valid test. The real-time clock may be invalid, but the date according to the operating system will be correct. The system must be powered off then on to complete this type of test but there is still a catch.

The second caveat may occur when the operating system is used to set the date and time. The system clock will always be set by the operating system. However, not all operating systems will concurrently set the real-time clock along with the system clock. In this scenario, the above methodology may cause a system that correctly supports the year 2000 to fail if the operating system does not set the real-time clock as well.

Frequently Asked Questions

Q:	Is this test program free?
A:	Yes. The program, 2000.EXE, provided by National Software Testing Laboratories, a division of the McGraw-Hill Companies, is publicly available.
Q:	What does YMARK2000 do?
A:	The program tests a personal computer for its ability to support the year 2000. The program tests only the BIOS and the real-time clock's functionality. Operating systems and applications must be tested separately.
Q:	A manual test on my PC shows Y2K compliance, but NSTL's test program says my system is non-compliant. Why the discrepancy?
A:	A manual test can not examine the real-time clock's ability to rollover to the 21st century in real time. If a manual test indicates support yet NSTL's test shows otherwise, chances are this is what you are experiencing. NSTL's program examines the hardware clock rolling over to the next century. A DOS level manual test with system reboot does not. Why is real time support important? For the majority of applications it is not important. But for applications that must record the date and time accurately, this is very important. The system clock (DOS�s clock) is notoriously inaccurate and most applications, and certainly the operating system, use it. But for accurate time, the hardware clock is far better. Network operating systems, voice messaging systems, automated schedulers, etc. usually use the hardware clock since they run 24hrs a day. An assumption is made that DOS sets the real-time clock hardware as well as the system clock. This is true for later versions of MSDOS and PCDOS. It is not true for earlier versions and I don't know off-hand whether other DOS "compatible" operating systems set the hardware clock or not. Testing the hardware clock is more accurate since the operating system must initially obtain its date and time from the hardware anyway. To avoid uncertainty, NSTL's test bypasses the operating system completely and examines the clock interface at the level that DOS, and some applications, use. Thus, disclosures of more subtle problems are observed. Operating systems, such as Unix, do not use the BIOS but obtain the date directly from the RTC hardware. NSTL's Y2K test makes sure the year in the RTC is located at the standard location. NSTL's Y2K test does not examine DOS's time/date functions. The test interfaces solely with BIOS interrupt 0x1A, functions 2, 3, 4 and 5. The methodology is simple. The RTC date and time is set via the BIOS and allowed to roll over to the next day. The date is read via the BIOS and is examined and reported. The date and time being displayed by the program is what the BIOS is reporting in real time. The following methodology demonstrates what you are witnessing. It is a manual test, but it is a test of the hardware clock. At the DOS command line, enter "`2000 READ`". The current date and time of the hardware clock is displayed. Set the date and time via DOS prior to the next century just as you do in your manual test. Enter "`2000 READ`" at the command line again to view the new date and time. Using the F3 key, re-issue the "`2000 READ`" command repeatedly and watch the time and date rollover midnight. I believe you'll find that the date goes to 1/1/1900. Power cycle the system. Once back at DOS, enter the "`2000 READ`" command again and you'll find that the date is now 1/1/2000. It is NSTL's position that a manual Y2K test is inadequate for this reason. Although NSTL may be biased, our Y2K program has a very strong track record. We know it to have been run on hundreds of PCs with accurate results. The Canadian government along with many major corporations currently use it for testing personal computers.
Q:	My computer does not support the year 2000, what can I do?
A:	Contact the system's manufacturer for a BIOS upgrade. (It is the BIOS that is responsible for supporting the next century.) If an upgrade is not available, the next best solution is to replace the system with one that does support the 21st century but that is expensive. Your system may maintain the new century if you set the date manually. Do a manual year 2000 test by setting the date to 1/1/2000 and rebooting the system. If DOS returns 1/1/2000, then you will need to manually set the date only once when the next century comes. It is possible to install special programs that will fix the problem, but that program must be executed every time the computer is booted. Unfortunately, the program will always be susceptible to unsuspecting persons believing it was not needed and thus removing the program. If supporting the 21st century is a must, this solution is not desirable. You can manually set the date every time you turn on the system or have the computer automatically retrieve the date from a network. You�re human and most networks seem to exhibit human traits too; thus, you can forget, accidentally enter the wrong date, are unable to connect to the network, the network is down, etc.
Q:	Does Windows 95 correct the year 2000 problem on systems that fail this test.
A:	Not really. Windows 95 itself does. But Windows 95 is based on DOS and the DOS itself does not. Thus, the problem is most likely to affect DOS based applications that must run in dedicated DOS sessions.
Q:	Does Windows NT 4.0 correct the year 2000 problem on systems that fail this test.
A:	Yes, but only within the NT operating system. If other operating systems are run on the same system, the problem may still exist.
Q:	Can the failure to support the 21st century be corrected via a software patch?
A:	Not reliably. In order to correct this problem, the patch software must be loaded and executed everytime the computer is started and before date sensitive applications are run. Unfortunately, device drivers and TSRs are loaded after the operating system and can easily be bypassed. Also, the patch software must be loaded everytime the system is booted for the life of the computer which could extend well into the next century. Unsuspecting individuals, not knowing what the patch software is, could easily remove the patch software from `CONFIG.SYS` or `AUTOEXEC.BAT` files.
Q:	Does NSTL have any other Y2K services?
A:	Yes. NSTL has a Year 2000 System Compliance Program. Using YMARK 2000, NSTL will determine if a system is Year 2000 compliant. Systems meeting test standards will receive the NSTL Tested Year 2000 System Compliant logo. System vendors and marketers can use this seal in advertising, packaging, sales materials and other promotional materials. NSTL also offers consulting services and can recommend workarounds and solutions for software that does not support year 2000. While NSTL has made YMARK2000 available free of charge, NSTL's other services are all fee based. For more information on NSTL's commercial testing services e-mail year2000@nstl.com or call 610-941-9600.
Q:	What is NSTL?
A:	NSTL is the leading, independent testing facility for the computer industry. Founded in 1983, NSTL pioneered the use of objective, comparative testing of PC and LAN hardware and software. NSTL offers custom compatibility, certification, performance, usability, BIOS and comparison testing services to hardware developers, software publishers, government agencies and corporations throughout the world. NSTL also publishes Software Digest and PC Digest and conducts testing for 60 business and trade publications worldwide. NSTL does not guarantee accuracy, adequacy or completeness of the services provided in connection with this program. NSTL MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO RESULTS TO BE OBTAINED BY ANY PERSON OR ENTITY FROM USE OF THE CONTENTS OF THIS PROGRAM. NSTL MAKES NO EXPRESS OR IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE OF ANY PRODUCT MENTIONED IN THIS PROGRAM.

Using the NSTL software

Attached below is NSTL�s YMark2000 program.

y2000.exe
24KB

Test Instructions for Ymark2000:

Boot to DOS.
Execute 2000.EXE
Read the results on your monitor.

If YMark2000 should recommend a manual reboot test, perform the following steps:

Create a DOS boot diskette and use it to boot the system you want to test. Be sure you are using DOS version 3.2 or higher.
Set the date into the Year 2000 using the DATE command and reboot the system. LEAVE THE BOOT DISKETTE IN THE DISKETTE DRIVE.
Check the date after the boot. If it is the same as the date set in step 2 then you will need to set the date one time only once.
Be sure to restore the computer's date to today's date!

NSTL's Y2K test program, YMARK2000, performs the following tests:

Verify MC146818 RTC compatibility. This test ensures that the date and time indices are compatible to the MC146818 and the data is in packed BCD format. Some non-DOS based operating systems, like Unix, do not use the BIOS but use drivers to access the clock directly. This test ensures that the clock is a Motorola MC146818 compatible chip. If the chip is not compatible, then these "other" operating systems or programs that read the clock directly may fail.
Verify real-time progression from December 31st, 1999 to January 1st, 2000. If real-time support fails, then the ability to set the date manually is checked.
Verify recognition and support of the 2000 leap year.
NSTL considered including a power cycle test to confirm the retention of century information. Although conceivable, it is highly unlikely that a BIOS reporting a correct century in real-time will fail after a power cycle. Nonetheless, a reboot test is an important part of the total Year 2000 test process.

Batch file support:

YMark2000 returns an error level that can be used in batch files. The error levels returned are:

0	The system is Year 2000 compliant
1	The hardware clock is not compatible to the MC146818
2	Progression to the next century is not supported
3	Progression to the next century is not supported and the hardware clock is not compatible to the MC146818
6	The year 2000 is not supported
7	The year 2000 is not supported and the hardware clock is not compatible to the MC146818
8	The leap year of 2000 is not supported
18	A manual Year 2000 reboot test is required since the system is using an Award BIOS.
19	BadProgression & BadRTC & Award 4.50G BIOS
22	BadY2K & Award 4.50G BIOS
23	BadY2K & BadRTC & Award 4.50G BIOS
26	BadLeapYear & BadProgression & Award 4.50G BIOS
27	BadLeapYear & BadProgression & BadRTC & Award 4.50G BIOS
255	The program failed to execute. Either the license agreement was not accepted, the RTC is not running, or an unknown command line parameter was issued.

An explanation for the programmers

Error levels are indicated by bit fields. Since multiple errors can be detected, the sum of the error bits are returned. For example, error level 6 (The Year 2000 is not supported) is a combination of BadProgression and BadManualSet (2+4).

   struct {
     int BadRTC         :1;  // 1, The hardware clock is bad
     int BadProgression :1;  // 2, Progression to 2000 does not occur
     int BadManualSet   :1;  // 4, Cannot manually set 2000
     int BadLeapYear    :1;  // 8, Error in leap year support
     int AwardBIOS      :1;  // 16, An Award BIOS is in use
     };

Company || PWI || Products || Ordering || Press || Support || Download || Library
Home || Contact || Links || Search

Table of Contents