home *** CD-ROM | disk | FTP | other *** search
/ PC World 1999 March / PCWorld_1999-03_cd.bin / Software / drivers / y2000 / y2000.exe / README.TXT < prev    next >
Text File  |  1998-12-16  |  17KB  |  325 lines

  1. Test Instructions
  2. 1. Boot to DOS.
  3. 2. Execute 2000.EXE
  4. 3. Read the results on your monitor.
  5.  
  6. If YMark2000 should recommend a manual reboot test, perform the following
  7. steps:
  8.  
  9. 1. Create a DOS boot diskette and use it to boot the system you want to test.
  10.    Be sure you are using DOS version 3.2 or higher.
  11. 2. Set the date into the Year 2000 using the DATE command and reboot the 
  12.    system.  LEAVE THE BOOT DISKETTE IN THE DISKETTE DRIVE.  
  13. 3. Check the date after the boot.  If it is the same as the date set in 
  14.    step 2 then you will need to set the date one time only once.
  15. 4. Be sure to restore the computer's date to today's date!
  16.  
  17.  
  18. NSTL's Y2K test program, YMARK2000, performs the following tests:
  19.  
  20.   · Verify MC146818 RTC compatibility.  This test ensures that the date
  21.     and time indices are compatible to the MC146818 and the data is in
  22.     packed BCD format.  Some non-DOS based operating systems, like Unix,
  23.     do not use the BIOS but use drivers to access the clock directly.
  24.     This test ensures that the clock is a Motorola MC146818 compatible
  25.     chip.  If the chip is not compatible, then these "other" operating
  26.     systems or programs that read the clock directly may fail.
  27.  
  28.   · Verify progression from December 31st, 1999 to January 1st, 2000.
  29.     If real-time support fails, then the ability to set the date
  30.     manually is checked.
  31.  
  32.   · Verify recognition and support of leap years from 2000 through
  33.     2009 inclusive.
  34.  
  35. NSTL considered including a power cycle test to confirm the retention
  36. of century information.  Although conceivable, it is highly unlikely
  37. that a BIOS reporting a correct century in real-time will fail after
  38. a power cycle.  Nonetheless, a reboot test is an important part of the
  39. total Year 2000 test process.
  40.  
  41.  
  42. Batch file support:
  43.  
  44. YMark2000 returns an error level that can be used in batch files.
  45. The error levels returned are:
  46.  
  47.       0 The system is Year 2000 compliant
  48.       1 The hardware clock is not compatible to the MC146818
  49.       2 Progression to the next century is not supported
  50.       3 Progression to the next century is not supported and
  51.         the hardware clock is not compatible to the MC146818
  52.       6 The year 2000 is not supported
  53.       7 The year 2000 is not supported and
  54.         the hardware clock is not compatible to the MC146818
  55.       8 The leap year of 2000 is not supported
  56.      16 The BIOS potentially fails a reboot test.  
  57.         A manual reboot test is highly recommended.
  58.      17 BadRTC & bad reboot BIOS
  59.      18 BadProgression & bad reboot BIOS
  60.      19 BadProgression & BadRTC & bad reboot BIOS
  61.      22 BadY2K & bad reboot BIOS
  62.      23 BadY2K & BadRTC & bad reboot BIOS
  63.      26 BadLeapYear & BadProgression & bad reboot BIOS
  64.      27 BadLeapYear & BadProgression & BadRTC & bad reboot BIOS
  65.  
  66.     255 The program failed to execute.  Either the license agreement was not
  67.         accepted, the RTC is not running, or an unknown command line
  68.         parameter was issued.
  69.  
  70.  
  71. An explanation for the programmers.  Error levels are indicated by bit 
  72. fields.  Since multiple errors can be detected, the sum of the error
  73. bits are returned.  For example, error level 6 (The Year 2000 is not 
  74. supported) is a combination of BadProgression and BadManualSet (2+4).
  75.  
  76.    struct {
  77.      int BadRTC         :1;  // 1, The hardware clock is bad
  78.      int BadProgression :1;  // 2, Progression to 2000 does not occur
  79.      int BadManualSet   :1;  // 4, Cannot manually set 2000
  80.      int BadLeapYear    :1;  // 8, Error in leap year support
  81.      int RebootBIOS     :1;  // 16, BIOS is known to fail reboot tests
  82.      };
  83.  
  84.  
  85. Overview: The Year 2000
  86.  
  87. Is your personal computer ready to handle the 21st century?  You can't be sure
  88. unless your system is properly tested. NSTL, a division of CMP MediaInc., 
  89. has developed a program that can definitively tell whether a personal 
  90. computer system will handle the transition to the next century.
  91.  
  92. Software and operating systems retrieve the date from the computer.  If the
  93. computer does not support the 21st century, neither will its software.
  94.  
  95. This program tests the personal computer's ability to support the year
  96. 2000, not the operating system or software applications.  Separate
  97. testing must be performed on software.
  98.  
  99. The term "personal computer" in this document refers to any x86 based
  100. "industry standard" computer that contains a built-in real-time clock.
  101. "Industry standard" itself refers to IBM compatible or clone.  In general,
  102. this applies to personal computers built since 1985.  Operating systems are
  103. meant to include all flavors of DOS and Microsoft Windows.
  104.  
  105.  
  106. How the Computer Clock Works
  107.  
  108. Every personal computer contains two clocks - a built-in hardware clock and
  109. a virtual clock.  The hardware clock (real-time clock) runs whether the
  110. system is on or off.  The virtual clock (system clock) is set to the real-
  111. time clock when the computer is turned on and exists only while the computer
  112. is operating.  While the computer is up and running, the two clocks run
  113. independent of each other.
  114.  
  115. The system clock is a 24 hour timer and has no real concept of days;
  116. whereas, the real-time clock tracks the time and date.  In fact the system
  117. clock has no concept of traditional hours, minutes, and seconds.  It merely
  118. increments a counter 18.2 times per second.  The operating system, which is
  119. dependent upon the system clock for the time, converts the counter into
  120. hours, minutes and seconds.  As for the date, the operating system, during
  121. initialization, reads the real-time clock via the BIOS then tracks the date
  122. independently based on the virtual system clock rolling over midnight.
  123.  
  124. For some reason, the real-time clocks used in today's personal computers do
  125. not track centuries - only years, such as '96, are tracked.  When the next
  126. century occurs, the real-time clock merely indicates year '00.  It is the
  127. BIOS's responsibility to track the century and preserve that information in
  128. the real-time clock's nonvolatile CMOS memory.
  129.  
  130. The BIOS assumes that the years 1900 through 1979 cannot occur, so when the
  131. year is within 00 - 79 and the century information is 19, the BIOS should 
  132. set the century information to 20.  If the BIOS does not track the century, 
  133. the operating system will be given an invalid year and most likely will 
  134. assume 1980.  (Microsoft operating systems do not support dates earlier 
  135. than 1980.)
  136.  
  137. Caveats
  138.  
  139. Since the two clocks run independently, the real-time clock can be set to
  140. any nonsensical value while the system is running and the operating system 
  141. will not notice.  Such will occur January 1, 2000 if your system does not 
  142. support the year 2000 and it is left on.  As    long as the system is running, 
  143. the operating system will correctly support the occurrence of the year 2000.
  144. Problems will occur, however, when the system is rebooted or powered off 
  145. then on.  This is the first caveat -- Setting the date and time just prior 
  146. to the year 2000 and just letting the new year occur is not a valid test.  
  147. The real-time clock may be invalid, but the date according to the operating
  148. system will be correct.  The system must be powered off then on to complete
  149. this type of test but there is still a catch.
  150.  
  151. The second caveat may occur when the operating system is used to set the
  152. date and time.  The system clock will always be set by the operating system.
  153. However, not all operating systems will concurrently set the real-time clock
  154. along with the system clock.  In this scenario, the above methodology may 
  155. cause a system that correctly supports the year 2000 to fail if the operating
  156. system does not set the real-time clock as well.
  157.  
  158. Frequently Asked Questions
  159.  
  160. Q.  Is this test program free?
  161. A.  Yes. The program, 2000.EXE, provided by NSTL, a division of CMP
  162.     Media Inc., is publicly available.
  163.  
  164. Q.  What does YMARK2000 do?
  165. A.  The program tests a personal computer for its ability to support the
  166.     year 2000.  The program tests only the BIOS and the real-time clock's
  167.     functionality.  Operating systems and applications must be tested
  168.     separately.
  169.  
  170. Q.  A manual test on my PC shows Y2K compliance, but NSTL's test program
  171.     says my system is non-compliant.  Why the discrepancy?
  172. A.  A manual test can not examine the real-time clock's ability to rollover
  173.     to the 21st century in real time.  If a manual test indicates support
  174.     yet NSTL's test shows otherwise, chances are this is what you are
  175.     experiencing.  NSTL's program examines the hardware clock rolling over
  176.     to the next century.  A DOS level manual test with system reboot does
  177.     not.
  178.  
  179.     Why is real time support important?  For the majority of applications
  180.     it is not important.  But for applications that must record the date
  181.     and time accurately, this is very important.  The system clock (DOS's
  182.     clock) is notoriously inaccurate and most applications, and certainly
  183.     the operating system, use it.  But for accurate time, the hardware clock
  184.     is far better.  Network operating systems, voice messaging systems,
  185.     automated schedulers, etc. usually use the hardware clock since they run
  186.     24hrs a day.
  187.  
  188.     An assumption is made that DOS sets the real-time clock hardware as well
  189.     as the system clock.  This is true for later versions of MSDOS and PCDOS.
  190.     It is not true for earlier versions and I don't know off-hand whether
  191.     other DOS "compatible" operating systems set the hardware clock or not.
  192.     Testing the hardware clock is more accurate since the operating system
  193.     must initially obtain its date and time from the hardware anyway.
  194.  
  195.     To avoid uncertainty, NSTL's test bypasses the operating system
  196.     completely and examines the clock interface at the level that DOS, and
  197.     some applications, use.  Thus, disclosure of more subtle problems are
  198.     observed.
  199.  
  200.     Operating systems, such as Unix, do not use the BIOS but obtain the date
  201.     directly from the RTC hardware.  NSTL's Y2K test makes sure the year in
  202.     the RTC is located at the standard location.
  203.  
  204.     NSTL's Y2K test does not examine DOS's time/date functions.  The test
  205.     interfaces solely with BIOS interrupt 0x1A, functions 2, 3, 4 and 5.
  206.  
  207.     The methodology is simple.  The RTC date and time is set via the BIOS
  208.     and allowed to roll over to the next day.  The date is read via the
  209.     BIOS and is examined and reported.  The date and time being displayed by
  210.     the program is what the BIOS is reporting in real time.
  211.  
  212.     The following methodology demonstrates what you are witnessing.  It is a
  213.     manual test, but it is a test of the hardware clock.
  214.  
  215.     At the DOS command line, enter "2000 READ".  The current date and time
  216.     of the hardware clock is displayed.  Set the date and time via DOS prior
  217.     to the next century just as you do in your manual test.  Enter
  218.     "2000 READ" at the command line again to view the new date and time.
  219.     Using the F3 key, re-issue the "2000 READ" command repeatedly and watch
  220.     the time and date rollover midnight.  I believe you'll find that the
  221.     date goes to 1/1/1900.  Power cycle the system.  Once back at DOS, enter
  222.     the "2000 READ" command again and you'll find that the date is now
  223.     1/1/2000.
  224.  
  225.     It is NSTL's position that a manual Y2K test is inadequate for this
  226.     reason.
  227.  
  228.     Although NSTL may be biased, our Y2K program has a very strong track
  229.     record.  We know it to have been run on hundreds of PCs with accurate
  230.     results.  The Canadian government along with many major corporations
  231.     currently use it for testing personal computers.
  232.  
  233. Q.  My computer does not support the year 2000, what can I do?
  234. A.  Contact the system's manufacturer for a BIOS upgrade.  (It is the BIOS
  235.     that is responsible for supporting the next century.)  If an upgrade is
  236.     not available, the next best solution is to replace the system with one
  237.     that does support the 21st century but that is expensive.
  238.  
  239.     Your system may maintain the new century if you set the date
  240.     manually.  Do a manual year 2000 test by setting the date to
  241.     1/1/2000 and rebooting the system.  If DOS returns 1/1/2000, then
  242.     you will need to manually set the date only once when the next
  243.     century comes.
  244.  
  245.     It is possible to install special programs that will fix the problem,
  246.     but that program must be executed every time the computer is booted.
  247.     Unfortunately, the program will always be susceptible to unsuspecting
  248.     persons believing it was not needed and thus removing the program.  If
  249.     supporting the 21st century is a must, this solution is not desirable.
  250.  
  251.     You can manually set the date every time you turn on the system or have
  252.     the computer automatically retrieve the date from a network.  You're
  253.     human and most networks seem to exhibit human traits too; thus, you can
  254.     forget, accidentally enter the wrong date, are unable to connect to the
  255.     network, the network is down, etc....
  256.  
  257. Q.  What is the Crouch-Echlin Effect or Time Dilation?
  258. A.  The Crouch-Echlin Effect (time dilation) is a phenomenon observed by two 
  259.     gentlemen.  Apparently, the date and/or time appears to advance or go
  260.     backwards between boots of a PC.  Their claim is that this may occur
  261.     on a PC in the next century.
  262.  
  263.     NSTL, Compaq and Intel have not been able to confirm the Crouch-Echlin 
  264.     Effect.
  265.  
  266.     For more information, please see 
  267.                http://www.nethawk.com/~jcrouch/dilation.htm
  268.  
  269.  
  270. Q.  Does Windows 95 correct the year 2000 problem on systems that fail
  271.     this test.
  272. A.  Not really.  Windows 95 itself does.  But Windows 95 is based on
  273.     DOS and the DOS itself does not.  Thus, the problem is most likely to
  274.     affect DOS based applications that must run in dedicated DOS sessions.
  275.  
  276. Q.  Does Windows NT 4.0 correct the year 2000 problem on systems that
  277.     fail this test.
  278. A.  Yes, but only within the NT operating system.  If other operating
  279.     systems are run on the same system, the problem may still exist.
  280.  
  281. Q.  Can the failure to support the 21st century be corrected via a software
  282.     patch?
  283. A.  Not reliably.  In order to correct this problem, the patch software must
  284.     be loaded and executed everytime the computer is started and before date
  285.     sensitive applications are run.  Unfortunately, device drivers and TSRs
  286.     are loaded after the operating system and can easily be bypassed.  Also,
  287.     the patch software must be loaded everytime the system is booted for the
  288.     life of the computer which could extend well into the next century.
  289.     Unsuspecting individuals, not knowing what the patch software is, could
  290.     easily remove the patch software from CONFIG.SYS or AUTOEXEC.BAT files.
  291.  
  292. Q.  Does NSTL have any other Y2K services?
  293. A.  Yes. NSTL has a Year 2000 System Compliance Program. Using YMARK 2000,
  294.     NSTL will determine if a system is Year 2000 compliant. Systems meeting
  295.     test standards will receive the NSTL Tested Year 2000 System Compliant
  296.     logo.  System vendors and marketers can use this seal in advertising,
  297.     packaging, sales materials and other promotional materials.  NSTL also
  298.     offers consulting services and can recommend workarounds and solutions
  299.     for software that does not support year 2000.
  300.  
  301.     While NSTL has made YMARK2000 available free of charge, NSTL's other
  302.     services are all fee based. For more information on NSTL's commercial
  303.     testing services e-mail year2000@nstl.com or call 610-941-9600.
  304.  
  305. Q.  What is NSTL?
  306. A.  NSTL, a division of CMP Media, Inc., is the leading, independent testing 
  307.     facility for the computer industry.  Founded in 1983, NSTL pioneered the 
  308.     use of objective, comparative testing of PC and LAN hardware and software.
  309.     NSTL offers custom compatibility, certification, performance, usability, 
  310.     BIOS and comparison testing services to hardware developers, software 
  311.     publishers, government agencies and corporations throughout the world.  
  312.     NSTL also onducts testing for 60 business and trade publications 
  313.     worldwide.
  314.  
  315. NSTL does not guarantee accuracy, adequacy or completeness of the services
  316. provided in connection with this program.  NSTL MAKES NO WARRANTIES, EXPRESS
  317. OR IMPLIED, AS TO RESULTS TO BE OBTAINED BY ANY PERSON OR ENTITY FROM USE OF
  318. THE CONTENTS OF THIS PROGRAM.  NSTL MAKES NO EXPRESS OR IMPLIED WARRANTIES OF
  319. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE OF ANY PRODUCT MENTIONED
  320. IN THIS PROGRAM.
  321.  
  322.  
  323.  
  324.  
  325.