                 FidoNet Technical Standards Committee (FTSC)
                 ============================================

                          Year 2000 Working Group
                          =======================

                   Compatibility Tests : Revision 1.00
                   =================================== 


PLEASE read the whole document from start to finish before beginning any
tests to be sure that all the issues are well understood. These tests
may require some reasonably detailed knowledge of the workings of FTNs
(FidoNet Technology Networks) in some places.

These tests should ideally be conducted in order and in a single session.
That is, the clock should be set and tested appropriately before the other
tests, and when all the tests have been completed care should be taken to
restore the system to its original status (clock, addresses etc.) before
restarting the normal operation of the system.

WARNING :

  You should back up all data before running tests. Clearly, deliberately
  provoking Year 2000 bugs early could have adverse (and unknown) effects
  on your data.

  These tests are provided as is, and no responsibility can be assumed by
  the FTSC, the FTSC working group Y, nor by any invited guest of those 
  bodies for any damages arising from the use of the tests or the 
  information included herein.

At each step, success indicates you should proceed to the next test.

Remember, non compliant software need not be junked. In many cases year 2000
compliant versions of current packages are being actively developed, in
other cases simply workarounds may be possible.

Where possible, data generated by programs should be checked directly. That
is, someone with knowledge of the appropriate structures should examine the
data with a hex-editor or some similar tool to make sure every field is
correct.

Ensure that the issue number of the tests (as above) appears in the submitted
results form.



1. Operating Systems

  Operating Systems are of course outside the remit of the FTSC, but as a
  courtesy the following tests are suggested.


  (a) Operating System

  TEST DETAILS
  ============

  Set the clock on your system to a date in the year 2000. The Date
  March 14th, Year 2000 is suggested (due to later tests).

  Check whether this date has been set correctly.

  ** NOTE

  March the 14th, 2000 is a Tuesday. If your system says it is a Monday,
  it does not realise that 2000 is a leap year (unlike 1900).


  ISSUES
  ======

  Failure may indicate a compatibility issue with your Operating System.

  SOLUTION IDEAS
  ==============

  Attempt to update the OS.


  (b) Operating System - Transition

  TEST DETAILS
  ============

  Set the clock on your system to a time such as 23:58, Dec 31, 1999. While
  the machine is on, wait until the time should have rolled into Jan 1, 2000.
  Now check the clock to see if the date and time are correct (they are in
  the year 2000).

  ISSUES
  ======

  Failure may indicate an inability in the Operating System to handle the
  actual changeover moment from 1999 to 2000.

  SOLUTION IDEAS
  ==============

  Updating the OS may solve the problem, but if test 1(a) was passed this is
  a one-off transient problem. It can be circumvented by powering the machine
  down just before the changeover and powering backup when safely in the
  year 2000 (subject to the tests in Section 2).



2. Hardware

  Hardware is of course outside the remit of the FTSC, but as a courtesy the
  following tests are suggested. These are relevant to systems with Real
  Time Clocks.


  (a) Real Time Clocks - Storage

  TEST DETAILS
  ============

  If your system has a RTC (Real Time Clock) which preserves the time
  setting when the machine is switched off, you should now reset the
  machine (ie. shut it down and restart), and check the date shown
  by the machine is still in the year 2000.

  ISSUES
  ======

  Failure may indicate your BIOS or clock has problems with these dates and
  cannot store them, and hence restore them after a reset. As many Node
  machines are kept on at all times, this may not be a problem.

  SOLUTION IDEAS
  ==============

  It may be possible to fix this problem by arranging a program to run
  on startup which will set the software clock to the correct century.


  (b) Real Time Clocks - Transition

  TEST DETAILS
  ============

  Set the clock on your computer to a time such as 23:55, Dec 31 1999.
  Power off your computer (if it takes more than five minutes to shutdown
  the machine, set the initial time to be earlier). Wait (with the machine
  switched off) until the time should have rolled into Jan 1, 2000. Power
  up the machine and confirm the date has changed correctly.

  ISSUES
  ======

  Failure may indicate your BIOS or RTC cannot handle the transition from
  the year 1999 to 2000.

  SOLUTION IDEAS
  ==============

  It may be possible to fix this problem by upgrading your BIOS, where
  possible. However, if the machine passes test 2(a), this is only a one-off
  transient problem. Merely ensure that care is taken to correct the clock
  on the first occaision that the machine is switched on in the year 2000
  (or beyond).



3. Software

  As suggested above, you should determine that your operating system is
  capable of dealing with dates in the year 2000, and the system clock
  should be set in the Year 2000 before conducting the following tests.
  The date March 14th, Year 2000 is recommended.

  This document is of course mostly concerned with Fidonet technology
  programs. It should be noted that some programs (such as NODEDIFF
  processors) may use time calculations and should be tested, even though
  they are not an obvious part of the mail configuration.


  (a) Editors

  TEST DETAILS
  ============

  You should test that your editor can create messages with dates in the
  year 2000. Once your clock is set in the year 2000 as above, you should
  attempt to create a message in each storage type supported by your editor
  (HMB/JAM/SQUISH/.MSG) etc. (** If possible, check the created message
  directly as the Editor may correct an error before display. **)

  ISSUES
  ======

  Failure may make it very difficult to conclude the tests in this document,
  as it may be hard to check unpacked messages.

  SOLUTION IDEAS
  ==============

  In editors that support various storage methods, it may be possible to
  simply transfer all mail to folders in which the editor is compliant.


  (b) PKT Files - Unpacking

  TEST DETAILS
  ============

  The Packet files which contain bundled mail (traditionally with a .PKT
  format on appropriate operating systems) use two digit dates in one
  location. Programs may be prone to unpack them assuming them to be in the
  wrong century.

  Sample PKT files containing messages ranging from 1999 to 2008 have been
  included for you to unpack with your software.
  
  You may need to rename these files if your operating system does not use
  an 8+3 filename convention. If your operating system *does* use 8+3 but 
  your software will not touch the files, try renaming them so that they 
  are padded to 8+3 (for example, rename 1.PKT to 00000001.PKT).
  
  If your software junks messages too far in the "future" you may want to
  change your clock further forward to 14th March 2008.
  
  In the case of Mailers, you should try to unpack the files:

  1.PKT         Type 2   Packet;
  2.PKT         Type 2.2 Packet;
  3.PKT         Type 2+  Packet.

  Echomail processors should be used to unpack:

  1E.PKT        Type 2   Packet (Echomail);
  2E.PKT        Type 2.2 Packet (Echomail);
  3E.PKT        Type 2+  Packet (Echomail).

  In addition if, as most do, the EchoMail processor can unpack NetMail
  messages, you should test 1.PKT, 2.PKT and 3.PKT as well. The conference
  name of the messages in the EchoMail packets is YEAR2000_TEST. You should
  attempt to toss the mail into a conference of this name in each supported
  message base format.

  All the Packets are set up to originate from 2:2/5000 and to be destined
  for 2:2/5001. You may wish to, or need to configure 2:2/5001 as one of
  your system addresses for the duration of the test. (** Remember to
  remove the address after the tests **).

  Once unpacked, examine the messages carefully, either directly or with
  an Editor (** Which has been shown to be compliant **). Direct examination
  is always preferable, as a compliant Editor may be fixing problems in the
  message base itself.

  The messages are all dated on March 13th at 12 pm exactly (noon). Messages
  range from 1999 to 2008.

  ** NOTE

  If the year is reported correctly, but the date is not March 13th
  (especially if the error is one day), this may indicate that your software
  believes (erroneously) the year 2000 is not a leap year, and there may be
  serious problems arising from this, even if the software is otherwise
  compliant with 2000+ dates.

  ISSUES
  ======

  Failure to toss messages into message bases with the correct date may
  indicate a need to replace the program.

  SOLUTION IDEAS
  ==============

  In the case of EchoMail processors, it may be possible to avoid certain
  message base formats that are not compliant in favour of those that are.
  Lack of compliance in a mailer is a more serious problem; as incorrectly
  processed messages may be propogated through the network.

  This might also be the case with an EchoMail processor which is not a
  "leaf" in the network topology, which is examined in test 3(c) below.


  (c) PKT Files - Generation

  TEST DETAILS
  ============

  You should also test generation of PKT files by the software package.

  It is always preferable to check the generated PKT file manually [Testing
  it with a program shown to be compliant with test 3(b) may not be
  comprehensive, as the program may automatically be correcting some minor
  errors].

  For EchoMail processors, toss the test echomail PKTs 1E, 2E and 3E (above),
  after adding a (fake) system to the export configuration of the
  YEAR2000_TEST echo. The generated packets should be checked (as detailed
  in the paragraph above).

  ISSUES
  ======

  Generation of broken packet files is an even more serious issue than
  incorrectly unpacking them. After all, this problem will affect other
  systems to which the generated packet is exported.

  SOLUTION IDEAS
  ==============

  It may be possible to run a correcting program over the generated Packet
  files before they are transmitted.


  (d) Miscellaneous Tests

  TEST DETAILS
  ============

  In addition to the above tests, you should attempt to test other time
  related functions of programs. For example, the event handling in Mailers,
  and the message base purging in EchoMail processors.

  ISSUES
  ======

  Failure should be considered especially serious when its consequences will
  affect other (remote) systems. Tolerable problems in the local system is
  still to be regarded as a lack of compliance, although the program may
  still be useable in some sense.

  SOLUTION IDEAS
  ==============

  Possible solutions depend on the situation in hand. In many cases (such
  as faulty event handling) the fault may be terminal, in others (such as
  an EchoMail processor failing to purge certain message base types
  correctly), it may possible to avoid the problem areas.



-=-

Checklist

  Before resuming normal operation of the system, check the following:
  
  * System clock has been reset correctly (and survives a reset);
  
  * Temporarily added system addresses, conferences, and export systems
    have been removed;
  
  * Unpacked messages are deleted to prevent them propogating;
  
  * Data has been thoroughly checked for corruption, especially message
    bases, event files, high water marks, lastread pointers, and
    corrupt or all data has been restored from backup.
    
-=-

If you feel there are problems with these tests, please NetMail your
suggestions to Colin Turner at 2:443/13.0.

More information can be obtained by

File Request "FTSC2000" from 2:443/13.0
or at http://www.piglets.com/ftsc2000

-=-

Product of the FidoNet Technical Standards Committee (FTSC).
               Working Group Y (Year 2000 temporary group).

Last revised 20th July 1998.

-=- End Of File

