1. Create a folder on your hard drive called NSTL.
2. Close all programs and reboot your computer in MS-DOS mode by clicking on Start,
Shutdown, Restart the Computer in MS DOS mode.
3. When the computer comes back up you should be at a DOS screen, not in Windows 95. At
the prompt type
cd\nstl
2000
4. Follow the instructions and read the results on your monitor to see if your computer is
OK.
If YMark2000 should recommend a manual reboot test, perform the following steps:
1. 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.
2. Set the date into the Year 2000 using the DATE command and reboot the system. LEAVE THE
BOOT DISKETTE IN THE DISKETTE DRIVE.
3. 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.
4. Be sure to restore the computer's date to today's date!
NSTL's Y2K test program, YMARK2000, performs the following tests:
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 OR The BIOS is a victim of the Crouch-Echlin
Effect
16 The BIOS potentially fails a reboot test. A manual reboot test is highly
recommended.
17 BadRTC & bad reboot BIOS
18 BadProgression & bad reboot BIOS
19 BadProgression & BadRTC & bad reboot BIOS
22 BadY2K & bad reboot BIOS
23 BadY2K & BadRTC & bad reboot BIOS
26 BadLeapYear & BadProgression & bad reboot BIOS
27 BadLeapYear & BadProgression & BadRTC & bad reboot 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 RebootBIOS :1; // 16, BIOS is known to fail reboot tests
};
Is your personal computer ready to handle the 21st century? You can't be sure unless your system is properly tested. NSTL, a division of CMP MediaInc., 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 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.)
CaveatsSince 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 QuestionsQ. Is this test program free?
A. Yes. The program, 2000.EXE, provided by NSTL, a division of CMP Media Inc., 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 24 hrs 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, disclosure 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. What is the Crouch-Echlin Effect?
A. The Crouch-Echlin Effect (or time dilation) is a little understood problem, but it can
cause great headaches for the user. Dates of systems containing this problem may appear to
run fast. Every time the system is booted, the date has advanced several days or months
beyond the current date.
For more information, please see
http://www.nethawk.com/~jcrouch/dilation.htm
Upgrading the BIOS may eliminate the problem. See your system vendor for BIOS upgrades.
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, a division of CMP Media, Inc., 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 onducts 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.