He is joint author, with Graham Stedman, of Computer Contracts. He now acts as an independent consultant and can be contacted on 0181 505 5847 (tel/fax).
I was recently at the Wallace Collection admiring among other treasures the numerous French 18th century clocks. All are in full working order and there are anything up to five different time pieces in any one room. Imagine a man walking through the Collection who suddenly needs to know the time. He may glance at any watch he is carrying. Or he may turn to (or on the hour listen to) one or other of dozens of these marvellous machines. Some are conventional enough technically, albeit encased in exotic materials like Sevres porcelain, or ormulu and tortoiseshell. One splendid device (by Fortier, 1750) is an astronomical clock with the time, date, day of the week, signs of the zodiac and phases of the moon. One by Falconier made in the 1770s is in the form of a disk which acts as a lid on top of a substantial marble urn and rotates horizontally to show the hour and minute on the rim. A large figure of Mercury points at the result.
To return to my man who wished to know the time. How do we know what mechanism among the many available he has used? We do not. And the use of date/time modules in the Year 2000 crisis is the same. The software threads its way through the various options for deducing the date like the visitor wandering from room to room of the Wallace Collection. It is I submit impossible for an outsider to know what mechanism a program has used to arrive at a date. it may be any one of:
- user input
- the PC’s hardware
- the operating system (eg Windows 95)
- software embedded from some other supplier such as Oracle.
- For networked systems there are three further complications:
- the network operating system (eg NetWare)
- the server’s hardware
- the server’s operating system (eg Windows NT).
As if this were not bad enough, there is no knowing where or how a date may be used. There are date fields in data of course, but there is nothing to prevent a piece of software using a date for some other purpose – a hash total for example. This may or may not matter when we come to consider the Year 2000.
Tests for Software
For those of you who have written your own software there is nothing for it but to examine every bit of code and test exhaustively. But this article is really directed to those who have purchased their packaged software from a supplier and have neither access to the code nor knowledge of how to examine it.
Whether you stick with your old software or move to new software, your problem is the same unless you are content to rely exclusively on a manufacturer’s warranty that his software is Year 2000-compliant. And that, I suggest, is unwise by itself in that if a problem occurs with the software you need to be sure it is that supplier’s fault. He may easily take refuge in saying that his software is compliant – it is only that you used it with such and such version of the operating system (or such and such hardware) which is not compliant.
This brings us to testing software. As we do not know for certain (unless you are able to burrow into every piece of code used in the program) where and how a date may be used in a program, it will not be possible to test all and every occurrence of the use of a date in the software. But you can devise tests which give a good indication.
Various bodies provide advice on what tests to do: the British Computer Society, and the Computer Services and Software Association (www.cssa.co.uk/cssa/) for two. May of these go well beyond looking at the transition from 31 December 1999 to 1 January 2000. They may include a test to ensure that 2000 is a leap year, that 2001, 2002, 2003 are not but that a leap year will recur in 2004. They may also cover the (to my mind much less plausible) possibility that your programmer set 9/9/99 as a date for infinity so that the system will not be able to reach 10 September 1999. If you want to test this while you are about it, then do – but remember that the Year 2000 is the main concern.
To conduct your tests you will need to focus on both the inputting in advance of dates beyond 2000 – eg to show a termination date in 2003 of a contract which has already started; and also the processing of data when you have actually passed 1 January 2000. The first of these is relatively easy to do now. Your software may even (as do many human resources systems) display a calendar of future months. Such a calendar will also allow you to be sure that the system displays the days of the week correctly – which may not matter for many systems, but again is a common feature in human resources systems.
For the second type of test you will need to discount as much as possible the various other sources of dates set out above. The best I have come up with is to wind each system forward to the relevant date after 2000. In the case of the local PC, this is not too difficult. In the case of the server and network operating system, this is much harder. For some software it may be feasible to run it in stand-alone mode on a single PC and still load enough data to run and test the system successfully. Provided this stand-alone version is identical to the networked version, this may be an acceptable and simpler solution, and enables you to ignore the complications of server and network. But for most systems, a test winding forward the server and network is the only way of achieving certainty that these items have been eliminated from consideration, and the test will have to be done at a time when the server and network are not in use for any other purpose – not easy to schedule.
Both the inputting in advance and the inputting after passing 2000 need testing, so your test script will need to provide for both. It will probably start notionally in late 1999 and go through to at least beyond 1 March 2000. For accounting and some other systems, this will mean several month-end routines before and after the important date, and should ideally include the first year end after 2000, which unless your financial or other year starts on 1 January will include a mixture of 1999 and 2000 material.
In view of the restriction on dates which you need to test and the necessity of winding systems forward, my recommendation to those acquiring new systems is to keep your acceptance test of the other functionality of these systems separate from Year 2000 compliance.
The tests should be well documented. The data used should be kept, together with the result. You should also record the version of the software you are testing identifying all the modules tested, the model of each hardware item (server and PC/terminal and even printer), and the version of each operating system used. In this way the results can be replicated if necessary.
In the event that your tests discover a fault, you will need to rerun the tests when you receive any patch or new version from the supplier which purports to address the problem. This rerun should be on exactly the same configuration as the earlier tests.
Compliance Statements
Finally there is the little question of getting from a supplier a statement of Year 2000 compliance. Although as I made clear above, this is not sufficient in itself, it is not valueless. But to get the most out of it I suggest you:
- tell the supplier which hardware and operating systems you intend to use and get him if possible to say that the system will work with these;
- in the event that he demurs at this, ask him to specify minima for these himself; and
- ask him to warrant that not only his own software but any embedded software (which he should identify) is Year 2000 compliant.
If you are purchasing a new system, you may be in a much stronger position to obtain these assurances.
Nothing’s Foolproof
Finally when you have done all this and satisfied yourself as far as you can that your systems are compliant, bear in mind that you may still get find non-compliance in your software. This may be because:
- your test did not test a particular function
- you are using a different version of the software (or embedded software) from the one you tested
- you have changed the PC, server or any of the operating systems.
There is I am afraid no such thing as certainty in this area. But making no effort to find out is not only foolish, but might even be interpreted as failing to exercise reasonable care in any action you may need to bring against a non-compliant supplier. Meanwhile you will be busy till and possibly after the year 2000. The Wallace Collection also contains Poussin’s famous A Dance to the Music of Time; that’s not a bad image of what we are all doing right now – going round in circles.
