INTRODUCTION
What Is The Year 2000 Problem?
Why Do We Have The Problem?
The Software Problem
Needle In A Haystack
Where Did I Leave That Source Code?
Take A Leap!
The PC Problem
The Network Problem
The Embedded Systems Problem
How Do We Fix IT?
What Am I Bid For This Programmer?
Summary
Appendix A
Case Study: Alex Lawrie
Appendix B
Estimated millennium compliance costs for UK
Appendix C
How The Year 2000 Problem Could Affect The Man On The Street
Appendix D
Reported Y2K War stories
Appendix E
Where Are Your Embedded Systems? *

Some people believe that the world will end on December 31, 1999. Many IT Managers and computer programmers are praying fervently that they are right!

The reason for that is that come January 1, 2000, some of their computer-based systems are going to stop working � or at least stop working properly. If they get their act together early enough (and even starting right now doesn�t leave much time) then the effects of the variously named "Year 2000 Problem" or "Millennium Time Bomb" can be minimised, or even completely eliminated. But for some, New Year�s Eve in 1999 is going to be anything other than a cause for celebration.

The reason for this � as I am sure everyone who hasn�t been on another planet for the last couple of years will know � is that many computer systems are programmed to accept dates in the format DD/MM/YY, allowing two digits for the day (no problems there), two digits for the month (OK so far) and two digits for the year (�.oh!). See the problem yet?

If they had computers in 1900, New Year�s Day would have been represented as 01/01/00. On New Year�s Day in the year 2000, all dates using two-digit year fields will also be represented as 01/01/00 � now do you see the problem?

But that is only part of it. On this evidence alone, you would be right to suppose that the Millennium Time Bomb is nothing more than a damp squib � after all, we will know when we read 06/05/00 on the screen that it is really talking about the year 2000 and not 1900 won�t we?

But to understand the real implications of this computerised cock-up, we need to consider how the computer itself will look at these dates. It doesn�t have the wherewithal to realise that we are now in the 21^st century rather than the 20^th � it simply applies some basic maths to the problem, and the results don�t look too healthy.

For instance, consider two events separated by almost 33 years - the child born on June 23, 2002 and Neil Armstrong�s historic moon walk on July 20, 1969. To us, the chronological order is evident, but if we ask the computer which happened first, how will it answer? Our fictitious child is born on 03/06/02, whilst Neil Armstrong didn�t perform his feat until as late as 20/07/69 � some 67 years after the child was born!

Let�s have a quick look at another example. A common calculation in many computer systems is to determine a person�s age � perhaps in order to calculate a retirement date, work out if a driving licence is still valid, or allow someone to vote. Assuming I was born on November 20, 1961 (this may or may not be true � I am admitting to nothing), my birth date would be represented as 20/11/61.

A computer working out my age this year would perform some basic math, deduct 61 from 97 and come up with the frightening answer of 36. Nothing untoward in that, you may think (except I want to know where the last ten years went!)

However, that same calculation performed in the Year 2001 would yield a slightly different result � instead of calculating 2001-1961 and coming up with the even more horrifying figure of 40, it would work out 01-61 and make me a bizarre �60 years old. Is this some terrible scheme perpetrated by the Government to withhold pension payments? After all, at 40 years old and with another 125 years to go before I retire (according to the computers), I am never likely to draw my old age pension at all, am I?

In some situations, we don�t even have to wait until the year 2000. Take the example of the credit card with an expiry date of 2000 � a common site at the moment given that most cards last for around three years. But what happens if your card gets swiped through a system that is not Year 2000 compliant? The computer checks the expiry date (12/00) against the current date (12/97) and determines that the card expired some 97 years ago! No purchase allowed, and a whole queue of sniggering shoppers behind you as you exit the establishment red faced and indignant.

Many of you must be sitting there thinking a couple of key questions: "why did the problem occur in the first place?", and "surely it can�t be that difficult to stick a couple of extra figures in all the computer dates?"

To answer the first question, we need to go back to the early sixties, when external storage devices and computer memory were prohibitively expensive, and data entry was labour intensive. Both of these factors combined to place rigid constraints on the type and content of data fields stored on computer. When designing computer systems, there is always a compromise to be made � usually between functionality and performance, or functionality and cost.

One of the earliest means of storing data was by punching holes in a piece of card known as a Hollerith Card. As these cards were passed through card reading devices, light was shone from below and the data could be read by sensors detecting the ordered light patterns.

Each of these cards were limited to storing just eighty characters of data, which is not a great deal when you think of how much personal information could be stored on an employee record, for instance. When every character counts in such situations, it is hardly surprising that programmers resorted to truncating the full date from 12/06/1969 to 120669, a significant saving of four characters.

Even where hard disks were used to store data, the same constraints existed due to the incredibly high cost of both memory and disk storage media. In those days, a 1GB disk was considered huge and was often used to store all the data needed to run an entire business � compare that to today when a 1GB disk is barely enough for our desktop machines.

Back in the sixties, resultant savings in hardware costs would have represented many many thousands of pounds. Undoubtedly the cost of storage media coupled with the data preparation costs (someone had to key all those dates into the computer � that�s what the Data Preparation Departments were for) were a significant factor in establishing the DDMMYY "standard". Over the lifetime of a system, the relatively small saving of four characters per date must certainly have seemed reason enough to justify the legacy of the Millennium Problem.

But what about 20 years later, when the price performance ratio was a lot more attractive? I was involved in a project around 10 years ago where we had to make the decision on whether to go with two or four digit years � I chose two! The scary bit about my personal contribution to the Year 2000 Problem was that I don�t think I ever actually considered the cost savings � after all, we already had a huge 2GB hard drive in our server! No, I had four other main considerations:

1. Performance. Processors and disks were still slow by today�s standards, and given that we had to index some huge files on dates, it made sense to minimise the size of those indices to maximise performance.

2. Visible output. Computer screens were 80 characters wide and printouts were 132 characters wide, and these were undeniable physical limitations. We didn�t have wonderful pop-up windowing environments, so we had to make everything fit on a single screen or page if it was to be easy to read. Reducing the size of the date field helped.

3. The default was two characters! Yes, although the language we used handled 4 digit dates quite happily, the default (a legacy of that sixties "standard" no doubt) was two characters. Anything for an easy life!

4. It was a long time to 2000! Oh dear. I think this is the main reason most of our legacy code cannot handle four-digit dates, and is the main reason that systems were being written only a year or two ago that will still not survive the year 2000 intact. The computer industry tends to be a little volatile, and most programmers will try to move around every two to three years to get a decent salary increase and acquire a new skill set. Why not, therefore, make life easy at the design stage and let someone else worry about the Millennium? You can certainly see why those "beat generation" programmers didn�t worry about it. They would expect their system to be replaced long before two-digit dates became an issue, and they themselves would probably be approaching retirement by the time it became a serious problem.

Now that you all understand and sympathise with the reasons we have the problem, it is time for the second question I posed earlier - "surely it can�t be that difficult to stick a couple of extra figures in all the computer dates?"

Anyone with even a rudimentary knowledge of programming will give you the frustratingly ambiguous answer of "well�it all depends". Any programmer can look back over the source code he or she has written and find the date references, at which point it is a simple matter to change them from two digit years to four digit years. Sounds simple enough, but this scenario makes a number of dangerous assumptions.

Firstly, it assumes the programmer who wrote the code is still around. As I have already intimated, programmers are a mobile bunch, changing jobs every few years to keep their skills fresh, keep their salary at the going rate, or to avoid a boring Year 200 project. If the programmer has moved on, it falls to another to plough through his former colleagues work in an attempt to locate all the dates � and this is not always as easy as it may sound.

The problem is that program code dealing with dates looks very much like program code dealing with polar bears � in other words it can be like looking for a needle in a haystack.

Perhaps if programmers were forced to adhere to some sort of standard, where all dates were prefaced by the word DATE, then the job would be reasonably straightforward. Some companies do attempt to enforce such standards, and many programmers even adhere to them.

Even so, you still get the occasional rebel who will prefix all birth dates with BDATE instead of DATE, or will simply call all his dates FRED just for the hell of it. Then again, you cannot legislate for simple spelling mistakes � DATTE instead of DATE will really mess up your automated search and replace routine � and in those sites where no programming standards were enforced, your guess is as good as mine as to how the dates are referenced.

Assuming you can track down all the dates in the program code, you then have to consider how the program output is handled. Many screens will have been designed with space constraints � usually limited by paper or screen size for reports and enquiries.

Do we leave the output as two digit years and let the users judge for themselves what the century should be (it is usually fairly obvious, after all)? Or do we go the whole hog and put four digit year fields everywhere and swallow the fact that there will have to be a major redesign of many of our screens and reports?

It is hard to imaging the size of today�s business systems in terms of lines of code, but we could be talking anything from 10 million to 200 million or more � we�ve been producing this code for over 30 years now, don�t forget. If you think that without the original programmers or a set of rigid standards to help things along you are faced with the task of scanning almost every one of those millions of lines of code, you can begin to appreciate the size of the problem.

For those companies whose systems consist of less than readable source code the task is even more Herculean. Analysing IBM assembler language programs, for instance, is far more difficult than analysing 3^rd generation languages such as COBOL. The eight character limit for identifiers means that they are not as meaningful as later languages, and assembler allows the programmer much more freedom in the use of low-level programming techniques.

As a result, following code logic and finding date values hidden in registers and memory areas are challenging propositions, to say the least. Trying to "fix the date problem" in assembler language code is extremely complicated, and is one area which benefits from advanced tools.

For those with this sort of requirement, there are a fully integrated workbench products available for analysing and repairing IBM mainframe assembler programs to obtain Year 2000 compliance. Similar tools are also available for COBOL environments too, as you would expect.

Product specific tool-kits abound too. There is one for Mantis users, which has the added attraction of providing a range of approaches to the date conversion process. Full date expansion is the obvious and most permanent solution, but it carries the downside of having the maximum impact on data files and interfacing systems.

This product can also adopt the "sliding window" technique, which does not require any changes to data files, but has the downside that it can only be applied to dates within a maximum 100 year period at any one time. The sliding window technique uses a self-advancing interval that removes the need for annual adjustments, and the tool-kit is flexible enough to allow for hybrid solutions where necessary.

Despite the availability of such tools, however, there is still an awful lot of manual searching and remedial work to be carried out, and the less rigid the programming environment, the greater the problem.

Once we begin altering the source code, of course, we must also consider the problem of the data files. These files have been storing dates in a two digit year format for a long time now, and you obviously cannot alter the source code to handle four digit years without converting the existing data.

If you miss one date field in your data files, or one date reference in one of your programs, you could be left with some major data corruption on your hands � if the problem lies in one of your year end routines or your quarterly sales analysis programs, then it could be some time before it surfaces, too.

Data file conversion brings about its own set of problems, unfortunately (you didn�t really expect it to be simple, did you?) Some database systems will allow you to increase the size of a data field on a live file in order to take account of the extra digits, following which you will have to write, test and run a conversion program which scans the database and adds the extra two century digits to all the date fields. That is the easy option � and you need a fairly sophisticated Database Management System (DBMS) in order to be able to modify the schema of a live system on the fly in this manner (the schema is that part of a database system which describes what the data files look like, i.e. whether they have two digit or four digit years).

Most systems deployed at the moment will force you into the slightly more long-winded and ever-so-slightly-scarier approach of dumping your entire database in order to update the schema. In essence, what we are talking about here is the requirement to define a new schema or file structure which includes four digit years instead of two digits. Following this, we run through the old database, copying every record and writing it out to the new one, substituting our new format dates as we go.

It is not hard to see the potential problems here � namely the fact that we are going to double our storage requirements in one hit, since we effectively need to create a copy of all our data files. Given the size of some of the databases out there at the moment (airline reservation systems or the Marks & Spencer customer account list) this becomes a very expensive proposition.

Some companies will have taken advantage of modern Hierarchical Storage Management (HSM) techniques to gradually move some of their historical data off expensive disk storage and onto slower but cheaper WORM (Write Once Read Many) storage. The definition of WORM means that you can only write to it once, therefore you cannot change the dates which are already written to it � you would have to completely regenerate the archive disks from scratch.

A possible way around situations where full date expansion is not a viable proposition might be to "fudge" the program logic in order to fool the system into believing it is dealing with four digit years when, in fact, the data files themselves only contain two digit years.

One means of handling this I with a centrally stored "century indicator", which could be set to �0� to indicate 20^th century dates, and �1� to indicate 21^st century dates. Thus the program logic could be changed so that every time it retrieved a date from the old database, it could check the century indicator to determine how it should be handled.

Another method would be to build some "intelligent" date handling into the applications to try and determine which century dates belonged to automatically. For instance, if we are talking about a personnel system and the program is retrieving a birth date from the file, it would be 100 per cent certain that such a date would be a 20^th century one � after all a 21^st century start date would not make much sense until around the year 2016 (when the company starts employing the first batch of sixteen year olds born in the new millennium) and a start date in the 19^th century date would be unlikely given today�s pension arrangements!

The program logic could also include a sort of "sliding window" whereby each year it "reassigns" the older dates from the 19^th to the 20^th century, until eventually it can be sure that all two digit dates are post-2000 � hence this is often referred to as the "sliding windows" technique.

Such work-arounds should be considered as temporary, of course, but they could buy some time if there was no other option, reducing the pressure to get all that historical data converted before the millennium hits us. However, the fact that the fixes mentioned so far (both the permanent and temporary varieties) require changes to the program logic, brings us neatly on to the second assumption � the assumption that the source code itself is available.

At first sight, this might seem to be a ridiculous obstacle to put in the way, but it is a very real problem to many companies. Admittedly, there are not many who have simply "lost" the original source code � that would be too bizarre � but there are some who are running packages provided by companies which have long since gone out of business. Bespoke systems produced by local computer companies are often provided without source code to ensure that all future changes must be performed (at a cost) by the supplier. It also prevent unscrupulous clients from changing a few lines of code and then reselling that software as its own.

This, therefore, could be considered a sensible precaution by the supplier, but what about protection for the customer? If the company is large enough and the bespoke deal is worth enough money, the customer can often insist on supply of the source code. If not, the only recourse is some sort of escrow deal, whereby the source is held secure by a trusted third party until such time as the supplier goes out of business, at which time it is released to the customer.

The National Computing Centre has recently launched its Escrow2000 service, giving organisations the ability to recover, fix and maintain a normal working system in the event of a Year 2000-related failure. The service will see the NCC acting as an independent, third-party holder of mission-critical source code on behalf of software users and vendors. Without the protection of escrow, many smaller companies find themselves with a mission-critical package, but no means of accessing the original source to ensure Year 2000 compliance.

It is not just bespoke systems that can cause problems either � there are many commercial packages which were originally widely available, but are now no longer supported for a number of reasons. These too are unlikely to be Year 2000 compliant, and there is little chance of gaining access to the original source code to make the necessary changes. Once again, escrow (used by many leading software vendors) is the only option open to users.

Before we move on from the software problem, there is one final bug in the ointment which needs to be considered. Everyone is aware that there are actually 365.25 days in each year, which is why every four years we have a leap year, resulting in an extra day in February.

Computers will usually check for a leap year by dividing the year by four � only numbers which divide exactly by four are considered leap years (i.e. 1996). However, there is a little-known convention which states that the first year of any century is not a leap year, even though it is clearly divisible by four. Unless, that is, the century is exactly divisible by 400 � that�s right, every fourth century is a leap year. And the year 2000 just happens to be one!

Lots of programs were written by people who didn't know this, and not just the COBOL legacy programs written by trainee programmers in your organisation. Many commercially available packaged programs suffer from the same failing.

The date functions in the first releases of Lotus, Excel, and Quattro Pro did not handle February 29, 2000 correctly. Lotus simply made an error, and the others followed suit to maintain "Lotus compatibility" in their products. Currently, Microsoft Excel shows correctly that the day after February 28, 2000 is February 29. Strangely, though possibly it is not that important, it also thinks that the day after February 28, 1900 is February 29, instead of March 1.

Now is the time to check all your word processors, spreadsheets, desktop databases, appointment calendars, and other off-the-shelf packages for both the year 2000 problem (which they should all be able to handle) and the leap year problem (which some cannot).

If you thought the millennium bug only infected legacy mainframe systems, however, you can think again. Another area which has received huge amounts of publicity � probably because it is one of the few areas that can have an automated "quick fix" applied � is that of your desktop PC.

An incorrect system date on a PC may well cause processing errors even in applications which are certified as Year 2000 compliant.

For instance, it is no good having an interest calculation routing that handles 21^st century dates if the PC on which it is running suddenly starts reporting that it is the beginning of the 20^th century again. A system clock that cannot correctly handle the change to the year 2000 has the potential to create havoc in your organisation.

At the end of the day, you see, we are still talking about errors in software, whether that software is part of a huge COBOL legacy system or whether it is lurking in the BIOS of our PC.

With the introduction of the IBM PC/AT in 1984 came two wonderful innovations: CMOS RAM to store configuration information, and the inclusion of a Real Time Clock (RTC). Both of these were integrated in a Motorola MC146818 chip which provided 64 bytes of CMOS RAM (14 for the RTC plus 50 for configuration data) powered by an external battery.

It is the job of the RTC to keep track of date and time information in the system, even when the PC is powered off. However, the PC does not actually use the RTC when it is running, since the BIOS reads the date and passes it to the operating system at boot time. Unfortunately, the Motorola chip and its replacements (like the DS1287 which combines the clock, CMOS and battery in a single module) contain the same basic flaw � they do not update the century byte.

Only the last two digits of the year are maintained, whilst the century byte itself is always stored as a �19�. As the year passes from �99� to �00� the RTC updates itself correctly, but the CMOS will retain the �19� for the century, thus rolling the date to January 1, 1900.

Depending on the capabilities of the BIOS, there are a number of possible problems that can manifest themselves under the "Millennium Bug" label. The first scenario is that the BIOS does nothing, and thus informs the operating system that it is January 1, 1900. The usual response to this is for the operating system to set the date so some arbitrary value like January 4, 1980 (the earliest date the OS can understand).

A more capable BIOS, which could be said to be Year 2000-compliant, will recognise the date is incorrect (since a date of 1900 is clearly unfeasible), and will correct the century as it passes the date to the OS. The century indicator in the CMOS, however, remains set at �19�.

The true Year 2000-compliant PC will contain a BIOS which not only passes the correct date to the OS the first time the problem occurs, but then patches the century byte in the CMOS from �19� to �20� so that the problem does not arise again.

The good news is that even if your PC proves not to be compliant, it is not necessary to throw it away. For one thing, the chances of it doing something critical that is date related during boot up are pretty remote in most circumstances, leaving you with the relatively minor task of manually correcting the date via the operating system.

Of course, this is not exactly convenient. A much more acceptable solution � the one employed by most of the automated Year 2000 test tools � is to install a small memory resident routing that ensures the correct century is returned every time a date is requested.

There are a huge number of vendors producing automated "quick fix" programs at the moment. These are designed to run a battery of tests on your PC to determine Year 2000 compliance, produce a report highlighting problems found, and even apply the appropriate fix if possible.

Some are better than others � it is not enough to simply check the date rollover, for instance - and I would stay well clear of any freebies you find on the Internet, some of which have been programmed by well-meaning but less-than-knowledgeable amateurs. Unfortunately I have also seen some commercially available products which are even worse, so it really is a case of caveat emptor.

Stick to solutions from the better known sources which will thoroughly test and identify the PC's BIOS revealing whether the date roll-over process is supported or not. These utilities then go on to perform the correction to the century value, and a small patch is then executed in the PC's start-up process correcting the century if it has passed while the machine was disconnected from the power, or as the date is subsequently requested from the BIOS.

Some will advocate a spot of DIY testing, but beware. Testing millennium compliance just by changing the time and date in the operating system will not verify that the RTC and ROM BIOS are Year 2000 compliant, as the operating system itself also maintains its own internal time and date clock. In fact, DOS and Windows have always been able to perform century roll-over.

However, if you leave the date set to January 1, 2000 and reset your computer, you may notice that the date has magically changed back to January 1980, indicating non-compliant hardware. But because DOS and Windows maintain their own representation of the time and date, they can mask errant behaviour at a lower level from a casual investigation. This is especially true if DOS' or Windows' own tools are used (for example the 'time' and 'date' commands). Remember that neither DOS or Windows has any control over a PC once the power is removed, following which both must return to the lower level (CMOS) clock the next time the machine is started.

One solution which is often mentioned but should only be attempted by the very brave is the BIOS upgrade. It is possible to install new BIOS code in our PCs by means of a flash update, but this could cause more problems than it solves. Although you may think you have an �Award 5.1� BIOS in your PC, it may nevertheless be unique to your PC�s manufacturer. At any given moment in time, a particular version of BIOS code is licensed by a number of manufacturers, each of which are free to make any changes necessary to work in their own particular design of PC. One vendor might handle the interface to the disk controller slightly differently to another, for example.

If you apply a generic BIOS upgrade to your PC, you will overwrite those vendor-specific changes, and may well render your machine unusable. If you really want to go the flash upgrade route, please be very careful that you get exactly the right version of BIOS code directly from the manufacturer of your PC � otherwise it just ain�t worth the risk.

Whichever way you look at it, you don�t have to worry about having to throw away your PC � they are all fixable. Of course that is no excuse for selling non-compliant kit at this late stage. You would expect all PCs sold today to be Year 2000 compliant, but according to Karl Fielder, founder of Year 2000 consultancy Greenwich Mean Time, this is not the case.

When his company looked at 500 BIOS, they found that 93 per cent of those made before 1997 would fail in the next century. "Seventy-nine per cent could not roll over from 1999, and fourteen per cent did not know that the year 2000 was a leap year," said Fielder.

Things improved enormously, however, when he looked at 1997 BIOS'. "Only 47 per cent of the BIOS failed," he said. So in 1997 users have about a 50:50 chance of buying a PC that will still work in 2000.

What proportion of PC�s currently in retail outlets, however, have recently-manufactured BIOS? A report in the Sunday Times recently tested 26 PC�s and laptops in Dixons, Harrods, John Lewis, PC World and Tempo, and in every store its reporters were given every assurance that the machines were Year 2000 compliant. On testing, however, it turned out that 88 per cent of them failed!

It is clear that retailers are somewhat behind the times as far as this problem is concerned, yet surely under the Sale Of Goods Act "fitness for purpose" requirement there is a legal obligation to ensure that PC�s sold this close to the millennium deadline are fully compliant?

So, the good news is that most PC�s can be updated to correctly handle the turn of the century. However, identifying which PCs in your organisation will experience year 2000 problems and fixing them can be a time consuming, resource intensive and costly project.

I touched on the unpalatable idea of DIY compliance testing earlier, but even with an automated testing tool, the requirement to visit every single PC an the network to check compliance � especially since it involves rebooting a couple of times, thus keeping your users idle while you carry out the tests � has most network managers breaking out in a cold sweat.

Not only that, but once the PC�s have been made year 2000 compliant they should also be monitored regularly to ensure they stay compliant. If you have installed a patch which kicks in on January 1, 2000 to correct the century problem, for instance, you do not want your "helpful" user to wipe this out whilst doing a spot of housekeeping.

Given the scale of the problem, it is surprising that those vendors already producing network-wide hardware auditing software have not added a Year 2000 compliance-checking element to them. Instead, it is the Year 2000-specific tools vendors which have got there first.

At the time of writing, however, there is only one Year 2000 tool that can deal effectively with network environments. This is a process-driven audit, update and monitoring package, where each stage of the process is controlled from a central console and completed as users log on to the network.

The extensive audit tests include checking for Year 2000 BIOS, RTC and leap year compliance; PC manufacturer and processor type; operating system and version, BIOS ID, date and manufacturer; PC memory size; hard disk drives, capacities, and free space; and the CD-ROM drive, thus providing a complete hardware audit as well as checking for compliance. If the BIOS can be positively identified and an upgrade is possible, a flash BIOS update is performed automatically. Where this is not advisable, a software fix is applied

Where the product really scores is in its network-based centralised administration in the Enterprise version (there also is a Lite version available for stand-alone machines). This is performed via the Control Centre, through which network administrators can specify the auditing of PC�s by individual, department or other organisation units from a single console. This approach provides full automation of the testing process on all your networked PC�s, even those at remote sites or on the road.

This product will also correct the non-compliant systems, provide detailed audit reports, and continue to monitor each PC automatically to ensure continued year 2000 compliance. This level of functionality is essential if managers of large PC networks are to be expected to get to grips with the problem.

There is one other item which needs considering before we leave the topic of networks, and that is the software contained in the various network hardware devices, such as bridges, routers, switches and hubs. Some of these devices will not depend on dates, of course, and will therefore not need updating. But how can you be sure? Devices which implement Quality Of Service may use date and time stamps to prioritise traffic. Routers may use date and time fields in their router tables. Make sure you obtain guarantees from all your network hardware vendors on Year 2000 compliance if you do not want your network to come crashing around your ears on New Year�s Day 2000.

Along similar lines, and one area with which it is proving very difficult to get to grips, is the issue of embedded systems. By this, I mean the computer chips which are part and parcel of most of today�s machinery, everything from your car engine to your local nuclear power station.

Embedded systems consist of micro-controllers running a very specific piece of code to control the machine of which they form a part. If the machine has a very limited range of non-date specific functions � such as a microwave oven � then it is unlikely to be affected by the millennium bug. If, however, it relies on dates to perform some of its tasks � such as a video recorder timer � then you may have problems.

Of course, if microwave ovens and video recorders start to fail, it is not the end of the world (although, once again, it raises some interesting legal issues, particularly if the device in question is no longer under warranty).

But embedded systems are literally everywhere, and that means they are contained in much more vital devices, such as engine control systems on planes, trains and automobiles and, of course, medical equipment designed to keep people alive.

In Christchurch, New Zealand, a recently completed audit by Canterbury Health found that dialysis patients may be at risk from the Year 2000 date bug. According to Year 2000 Project Manager, Chris Goodyer, "dialysis machines were among about 1500 pieces of medical equipment, of 4500 checked, that are likely to need enhancements to be used past the year 2000. Dialysis units use electronics to monitor cycles and blood flow, and are thus time-dependent."

Embedded systems are also to be found in they are in engineering control system keeping our nuclear reactors safe and our power plants running efficiently, and in military control systems, designed to kill people! The most worrying thing is that many of the military systems are as much as fifteen to twenty years old � what money would you put on those being Year 2000 compliant? Given all the fundamental problems with the Mir space station, for instance, do we really expect it to still be in the skies come January 1, 2000?

"There were 3.5 billion programmable micro-controllers shipped in 1995, and seven billion last year," says Margaret Joachim, assistant executive director of Taskforce 2000. "No one knows where they all are, no one knows if they are compliant."

As with the missing source code, a major part of the problem is the huge number of embedded systems out there in what is basically obsolete equipment, purchased from companies long since out of business, or who are unable to support the older kit which was discontinued years ago. How do you determine whether such devices are Year 2000 compliant � or even if it really matters either way?

The other half of the problem is simply the huge number of devices containing embedded systems. They are so ubiquitous, that it would be very easy to overlook many of them. Some are also extremely hard to access � things like the signal repeaters on undersea telecommunications cables, the flow meters on underground pipes, even the pacemakers in patients' hearts.

When it comes to testing these things, you really have your job cut out. There are no tools to help with this part of the Year 2000 problem, so you are left with having to test everything manually. This does not bode well for heavy users of embedded system in process and manufacturing industries, who cannot simply power down their plant for a day while they test the machinery.

Nor is type testing any guarantee of compliance. Type testing is where you thoroughly test a representative sample of a piece of machinery and assume that every other machine of the same type will behave in the same manner. The problem is, that two machines manufactured on the same day by the same vendor can actually contain chips from different manufacturers � one Year 2000 compliant and the other not.

Unfortunately, documentation down to the level of detail required to predict such failures is often not available, so the only recourse is to test every single piece of kit � and that takes time and manpower.

This brings us neatly on to the topic of how we resolve the problem. Unfortunately, no matter what the marketing people tell you, there is no "magic bullet" for this � you cannot wait for Bill Gates to solve the problem for you, and you cannot wave a bit of software at it and hope that everything will be OK.

Time is of the essence in this, so you need to act now if you have not already started. You also need to appoint or reassign someone full-time to be responsible for the Year 2000 project � taking a half-hearted approach simply will not work. Louis G. Zapatero is the Year 2000 Co-ordinator for California-based health-care organisation Kaiser Permanente, and he and his colleagues are following a four-phase plan: assessment, impact, date conversion, and testing/implementation.

"We started out in July 1996 with a presentation to senior Southern California management," Zapatero recalls. "At the same time, the IT team began the assessment phase, through a company-wide inventory of every software application. At its most basic, this means simply pulling together a list of every software program in use, detailing the purpose, technical characteristics (such as platform), and users of each."

Amazingly, completing the inventory took less than a month, the results of which were nine reports that segmented and analysed all the applications. Internal assessment then took two months, followed by a further month of analysis by an outside consultant.

Next comes the impact phase, during which it is necessary to identify the mission critical systems. These are the systems that must work each and every day, otherwise you cannot do business. When are they likely to fail? That is a key question, given that many could actually begin to fail before the Year 2000 arrives, usually because they are performing date calculations in the future (mortgage calculations, bank loans, and so on).

Once you have the information from the impact analysis you can begin to create the project plan. Which applications must be changed? When must they be ready? How many people will you need at each phase of the project? What are your critical deadlines, and what will you do as you begin to miss them?

One of the big problems with software development is the fact that computer programmers are not used to absolute deadlines. Deadlines are always treated as a "moveable feast", something to be aspired to but never actually achieved, except on the very smallest of projects (and even then only if the wind is in the right direction).

Unlike every other project you've ever worked on, however, this one has immovable targets. You cannot miss the January 1st 2000 deadline - it will not be postponed.

On that date your systems could go on strike and will not work again until fixed. If your accounting system fails, then you will be unable to produce any invoices. How long can your business survive without the ability to bill for its services?

We have mentioned several different type of tools throughout this article, and given the difficulty in checking every piece of software and hardware in a large organisation it is inevitable that some sort of automated help will be required. Despite what I said earlier about the difficulties in identifying dates in source code, there are some very good tools available to perform automated inventories, and some will even change your code automatically.

Zapatero, from Kaiser Permanente, feels that such tools are essential. "Without them, manual scanning would take years" he says, although he does admit that "the tools will never give you 100 per cent accuracy". The ability of these tools to help in any significant way depends greatly on what language you used to develop your applications, and you are unlikely to find tools to cover all of your systems.

There are close to 500 programming languages used to develop applications, and most of the conversion or inventory tools currently available are directed toward a very small subset of those. The majority are focused on COBOL, hardly surprising given the popularity of this language (particularly through the 60�s and 70�s) and the number of legacy applications written in it. In sharp contrast, very few tools, if any, have been designed to help in the area of APL or JOVIAL, for example.

Once you've selected a vendor from the hordes entering the fray, you'll be ready to perform your first impact analysis, during which every single application is scanned by a Y2K application scanner (and/or manually) to determine just how many lines of code are at risk.

Once the scanning phase has been completed, date conversion can begin, but there will always be an element of manual scanning required to catch the ones that slipped through the automated process. It is important to carefully analyse the resources necessary to achieve the conversion, and set realistic time scales accordingly.

As with most organisations, Kaiser Permanente is aiming to have testing completed and the implementation phase underway by the end of 1998. This comes as something of a shock to many organisations who still consider they have three years left before D-Day. The stark reality, however, is that the smart ones are aiming for a deadline less than two years in the future, to give themselves a full fiscal year to test every aspect of their conversion thoroughly.

This must be completed � and thoroughly - before the year 2000, because it is risking the business to discover errors when you have no idea how long it will take to fix them. If that should happen, your production line is stopped, and you are unable to bill your clients or ship your product, because the programs which drive these functions are no longer working.

There has already been some talk of insurance companies refusing cover for those organisations which cannot prove beyond a shadow of a doubt that their Year 2000 systems are fully compliant. This puts a much greater emphasis on the testing phase, since it is no longer just about satisfying yourselves that your systems are compliant. Proving your case will involve a technique called Time Dimensional Testing (TDT), which basically involves "simulating" the future followed by running a full day�s transactions and observing the results � there is more to it than simply setting your system clock forward, however.

The first stage is to capture a full day�s transactions and results under the current system to use as a baseline, following which the clock is set into the future and all directly affected and related test data is aged accordingly. This is a huge job, but is necessary to ensure that identical results are obtained under the test conditions as for the baseline, and are not skewed in any way by the test data suddenly appearing to be "older" from the applications viewpoint. Given that you would need to run tests for all key dates in your corporate calendar (month, quarter and year-end processing, for example) the use of automated tools for this phase of the project is almost essential.

One thing to bear in mind during all this is that you may not have to change everything, even if it is date related. Try to identify the essential changes during the assessment phase: those which will not accept a date of �00�, or those which will accept it but then process it incorrectly, treating it as �1900�. These are the critical areas. But there are many examples of date fields within computer systems that will quite happily continue to work with two digit years�� mainly in reports and output screens.

For example, some day-to-day operational reports will end up showing "00" as a representation for the year 2000, in a context everyone will understand. As long as the date is processed correctly internally, there is little point in wasting energy on such red herrings. Some Year 2000 tool-kits currently available actually take this approach.

Of course, you can only complete a project of this size if you have the resources available. The key factors about your Year 2000 project, of course, are that you have a finite amount of time in which to complete it, an absolute deadline, and everyone else is working on the same project at the same time. Can you imagine what effect this has on the market for programmers and consultants? If you don't already have various your Y2K consultants and programmers in place, you have precious little time to act, and their price is going up every minute.

Holding onto your own internal Y2K team, particularly technical IT experts and COBOL programmers, will be critical in the coming months and, indeed, the next couple of years. As word gets around of established projects, the head-hunters will be looking to make generous offers to your team to persuade them to jump ship and share their knowledge with others. Many organisations are instituting bonus retention programs, to keep their programmers and technical experts in place until project completion.

According to Kevin Schick, research director for the Gartner Group, "the alternative to addressing the Year 2000 will be going out of business." His is not a lone voice, either, and all companies, no matter how large or small, need to take the threat seriously.

There are those who predict even more dire consequences than a few businesses going to the wall. It is a fact that unless they are fixed, computer systems all over the world will begin to malfunction on the run up to the cusp of the millennium. Come New Year�s Day in the year 2000, a huge number of computer systems will simply stop working.

"Can you imagine, just for a moment, the chaos this would cause?", asks Gary North, predictor of the Year 2000 Apocalypse. "There would be no air traffic, no traffic lights, no lights in your company. Companies could not produce goods, no goods delivered to the stores. Stores could not send you bills, you could not send bills to anyone else. Business would come to a halt".

Beyond that, he goes on to predict widespread panic amongst customers of financial institutions, resulting in a massive withdrawal of funds and the collapse of the banking system. He predicts failure of plant management systems in manufacturing, power and communications industries, leaving us back in the dark ages, with no heating or lighting, no food and no means to communicate.

He predicts head-on train collisions and planes falling out of the sky, along with a total failure of all transport systems � even our cars will give up the ghost on us.

In theory, I suppose all of this could happen, but it assumes that no-one is going to do anything about the problem between now and 2000.

Undoubtedly, any company that is foolish enough to ignore the problem that completely will stand a very good chance of disappearing almost as quickly as the champagne on New Year�s Eve.

But providing we tackle the problem early enough and devote sufficient resources to it, we can all spend New Year�s Eve 1999 doing what we are supposed to be doing � partying like there is no tomorrow (pardon the unfortunate turn of phrase) � rather than worrying whether the lights are about to go out all over the world.

Alex Lawrie, part of the Lloyds-TSB Group and the UK�s market leader in Sales-Linked Finance (factoring), is currently undergoing a complete Year 2000 conversion project comprising hardware and systems software upgrades together with the application code changes, in partnership with Logica.

The company has chosen Compuware�s suite of testing tools as its standard for Year 2000 compliance testing. Alex Lawrie�s application, which operates in much the same way as a standard sales ledger and resides on an IBM mainframe, handles up to 375,000 invoices a month from a client base of 4,000. Additionally, the system issues up to 15,000 cheques a day.

"Our application comprises in the region of 1,500,000 lines of COBOL, and therefore we required heavy-duty testing tools," says John Howe, IT manager at Alex Lawrie. "Additionally, we were looking for an integrated tool set from a single supplier, with a common look-and-feel; as Compuware�s testing tools had gained a great reputation in other parts of the Lloyds-TSB Group, and fulfilled all our requirements, it was the obvious choice for us."

John Howe continues; "We feel that testing represents around 60% of the whole Year 2000 compliance project, so buying a "best-of-breed" solution was a pre-requisite. Compuware has robust and flexible technology and its tools will not only allow us to complete our Year 2000 project, but will also produce a re-usable test baseline for our upcoming EMU compliance project."

Ian Meakin, product marketing manager at Compuware, concludes, "The only way to maximise confidence in the success of a Year 2000 compliance project is through reliable and rigorous testing. Alex Lawrie�s choice of Compuware�s automated testing tools to underpin the success of its Year 2000 project is a measure of Compuware�s ability to meet these requirements."

The estimated costs of fixing the Year 2000 problem are upwards of �400 billion world-wide, with the UK facing a bill of at least �10 billion. Almost half of the cost will be borne by the largest companies, with Government IT accounting for almost three quarters of a billion pounds of it.

These figures have been compiled by Sean O�Reilly, managing director of Year 2000 Conference Europe, and are positively heart-warming compared to the �24 billion cost estimated by Cap Gemini. "Organisations that have not yet started work must get on the fast track to Year 2000 compliance or risk disaster," warned Jacky Olivier, director of TransMillennium Services at Cap Gemini. The company estimates that one in ten companies will fail to meet the deadline for ensuring their computer systems are Year 2000 compliant, and such a failure could put as much as 29 per cent of Gross Domestic Product (GDP) at risk. It goes on to say that if the timetable to fix the problem slips by just three months, as many as one in four companies would fail to meet the deadline, representing 37 per cent of GDP. Strong stuff indeed.

O�Reilly�s slightly more optimistic figures are based on the estimated total millions of lines of code in the UK, with an estimated conversion cost of about 37p per line:

Private sector
Company name Estimated cost (�m)

BT 350
Big 4 banks 480
Top 10 insurers 800
Top 10 building societies 500
Utilities 1,000
900 smaller companies 5,820
Total 8,950

Public Sector
Government dept Estimated cost (�m)

Health service 120
Social Security 130
Inland Revenue 130
Defence 110
MAFF 45
Others 240
Total 775

Source: Sean O'Reilly, managing director of Year 2000 Conference Europe