"Y2K:
Will my Spectrometer work in January? "

Dr K England, University of Manchester & Dr Keith Hallam, IAC-Bristol

This presentation began with a reminder of the basic tenets of Year 2000 Compliance:
 

	Neither performance nor functionality is affected by dates prior to, during and after the year 2000;
	No value for the current date will cause any undesired interruption of operation during a product's expected lifecycle;
	Date-based functionality behaves consistently for dates prior to, during and after year 2000;
	In all interfaces and data storage, the century in any date is specified either explicitly or by unambiguous algorithms or inference rules; and
	Year 2000 is recognised as a leap year.

Before going any further, it is important to ask, "Is Year 2000 compliance important to you?" An initial four possible answers to this question:
 

	Yes - I have already checked out my system and it is OK;
	Yes - I have already checked out my system and it will require some upgrading;
	Yes - I haven't checked out my system and I don't know what to do; and
	No - I'm going to wait and see what happens on 01/01/2000;

Were supplemented from the audience during a vote with:
 

Yes – I have already checked out my system and it is not o.k. but there is nothing I can do about it.

Those who had not yet checked out their own systems often seemed to be asking the same questions of those around them who had somehow managed to acquire y2k duties, which could be answered in the following way:

Q:  Is my computer y2k compliant?

A: What computer do you have?;
 

Q: Is there anything else in my spectrometer that will give me problems?

A: What spectrometer and what options do you have?;
 

Q: What do I have to do to make sure nothing goes wrong?

A: Back-up your data and carry out checks now; and
 

Q: How do I fix things when they do go wrong?

A: See all of the above!

Behind those answers lies the fact that it is not difficult to check out your own system and identify potential problems and possible ways to overcome them, if required, as outlined in the rest of the presentation.

Firstly, check out manufacturers’ websites. Many of these are very comprehensive, particularly those belonging to computer hardware and software manufacturers. Often there is a complete listing of all the products they have ever made, with info about whether or not they are compliant. If this does not help, contact your organisation’s y2k officer.

Examples of y2k web sites were given (see http://www.uksaf.org/software.html#9 for links to these). The Kratos site was highlighted as being excellent, with a comprehensive list of systems back to the ES100 series. Information on the various operating systems and software versions made it very easy to work out whether a particular system would need any upgrades and what they were. This was illustrated with the example of an XSAM800 that had had its software upgraded and required a £160 software patch to make it fully compliant. Additionally, it contained many useful links to other sites. In contrast, Omicron had no y2k information available and Jeol only gave a basic disclosure statement and a list of contacts. There was no specific product information. VSW also had no specific y2k pages but did state that while their software was compliant, users should check out PCs themselves, since these had usually been bought by the user. Phi gave downloadable PDF files, including a disclosure statement, a chart of all the computer systems that had been used by PHI, including whether they were compliant and if not, whether/how they could be upgraded and a chart of all software produced by PHI and whether it was compliant, plus how to upgrade if necessary. VG’s site was limited, with a readiness disclosure, information on current software and operating systems and advice, with links, on where to go for help with older operating systems and computers. Contact details were provided if more information was required.

You can easily carry out your own system checks, and a 32-step testing schedule (available on the web at http://www.uksaf.org/y2k.doc) was presented, using a PDP11/microRSX11/VGS5250-powered VG Escascope as an example. Acquisition, plotting, quantification and x-ray shut-off were tested for an extensive series of dates, though it was noted that it was impractical to test every operating variable for all combinations of date and time.

The results of the test showed that, most importantly, the x-ray power supply never failed to be shut off. Secondly, the spectrometer never failed to acquire, save or read back a spectrum. The time was always correctly displayed though different parts of the operating system and software displayed dates differently, with incorrect displays usually limited to the main menu screen. Often, while rolling over from or to an awkward date, irregular displays were created, though these could be reset the next time a date was entered. Illegal dates, e.g. 29th. February 1998 and 31st. April 1998, could not be entered. The first problem came with 9th. September 1999, which could be entered but displayed incorrectly on the main menu screen. Quantification results printouts added the 19 in front of the year by default unless the computer had not been rebooted since 31-12-99 - a problem that will have to be lived with – and date-based directory listing commands were, obviously, confused, but I’ve never used them, so why worry?

In summary of this test, safety was not compromised by any lack in compliance, it would still be possible to acquire, store and process data, it was possible to have the correct two-digit year stored away with the data and displayed on output, except for quantification results, any problems with incorrect roll-overs would be fixed the next time the computer was rebooted (i.e. extremely often!) and no problems encountered would appear to warrant expenditure on hardware or software fixes, in the particular working environment of this spectrometer. However, the instrument will be off over the New Year anyway - Can we trust the water and power people?

Figure 1: The First Principle of y2k Preparedness

If you have a system that is not y2k compliant and cannot be upgraded, you may be able to trick it into being better behaved. The easiest way to avoid problems is to reset the system clock to an earlier date. If possible, resetting to 1972 provides a leap year and also the same days-of-the-week sequence as for dates as in the year 2000. However, this is not always possible, highlighted by the example of a PDP11 running TSX, which cannot be reset to 1972, but does not record the day of the week anyway.

And finally (and here you have to use your imagination slightly to recall those big, friendly letters:)

Don't Panic!
  

< Previous | Index | Next >

Last updated 24 February, 2001

Simon Morton
Advanced Light Source
Lawrence Berkeley Laboratory
Berkeley
CA 94720

Comments or enquiries to S.Morton@uksaf.org

© UK Surface Analysis Forum 1998