On Wed, 16 Dec 1998, Pollywog wrote:
> Could Exim be tested for Y2K compliance by moving the system clock date up
> to the day before January 1, 2000. I am guessing there is some reason
> this won't work, but I don't know what that reason might be.
Speaking as someone who just finished the process planning for our Y2K
project (the Email part at least), I can tell you that there's much more
than that to consider.
In any complex program, just running it with the clock set to a Y2K date
isn't enough.
Consider:
- Running Exim with the clock set to a Y2K date
- Feeding Exim messages with Y2K dates in the headers
- Running Exim without moving the clock but using Y2K-dated headers
- Running Exim with moving the clock and using non-Y2K headers
- Running Exim with messages in the spool that have Y2K timestamps (both
with and without the clock set to a Y2K date). Ensure that the retry/fail
algorithsm function correctly.
- and so much more
I forget where I saw this, but I recently read a quote saying that the
amount of technical work required to fix the Y2K problem is dwarfed by the
task of managing the procedure to do so. In any good Y2K plan, you don't
just take the author's work for it that the product is compliant. You get
that compliance statement, then you run the program through rigorous
testing in your environment. Failure to do so means that you haven't
taken "reasonable steps" to ensure that your systems are Y2K compliant.
Most insurance companies are issuing Y2K liability policies based upon
you taking these "reasonable steps".
I'll get off the soapbox now.
--
j.
James FitzGibbon james@???
System Engineer, ACC Global Net Voice/Fax (416)207-7171/7610
--
*** Exim information can be found at
http://www.exim.org/ ***
