The Millennium Bug

Jeyakody Kesavan

Arasnath Kimis



A SURPRISE 1997 Presentation


Table of Contents



  1. Introduction
  2. Root Causes of the Year 2000 problem
    1. Hazardous Implications
    2. Beneficial Implications
    3. Fallacies
  3. Size of the Year 2000 Problem
    1. Efforts in the UK
    2. Taskforce 2000
    3. Function Points
    4. Year 2000 Repairs by Industry
    5. Year 2000 Repairs by Company Size
    6. Year 2000 Repairs by Programming Language
    7. Global Year 2000 Repairs
  4.  Solutions to the Year 2000 problem
    1. Criteria of the comprehensive solution to the Year 2000 problem
    2. Different solutions from a programming perspective
    3. Comparison between procedural and data change
    4. Case studies for different computer hardwares and softwares
    5. Emergence of the Year 2000 Repair Industry
  5. Action Plan for a company to achieve 2000-compliance
    1. Vulnerability Check
    2. The Year 2000 Office
  6.  Litigation Potential for the Year 2000 Problem
  7.  Conclusion
  8.  Acknowledgements
  9.  Appendix
    1. Evaluation of the tools and services of a proposed year 2000 vendor
    2. Year 2000 Conversion checklist



The year 2000 software problem concerns the widespread practice of storing calendar year dates in two digit form, so that the year 1997 would be stored as 97. At the end of the 20th century, many software applications will stop working or create erroneous results when the year switches from 1999 to 2000 at midnight on December 31. This is because many applications use dates for time-sensitive calculations, and the sequence of 99 followed by 00 can cause software crashes or incorrect results for many important calculations such as interest rates and mortgage payments.

The year 2000 problem will be one of the most expensive problems in human history. For the UK, more than four months of effort may be needed on the part of every software professional in the country to repair the year 2000 problem. The year 2000 repair costs may exceed £1300 for every working person in the UK, or more than £600 for every citizen of the UK.

The year 2000 problem is not trivial and will not go away if ignored. Failure to correct the year 2000 problem can lead to serious consequences, including several kinds of litigation, possible bankruptcy, and possible economic disaster. Software and corporate executives may be held personally liable for some of the consequences of the year 2000 problem unless prompt and serious actions are taken to correct the problem. The year 2000 problem may lead to lawsuits against corporate executives for violation of fiduciary duty, and against software executives for professional malpractice.

A variety of tools and services are now available to assist in finding and repairing the year 2000 problem. However, October of the year 1997 is the last month and year in which there is a reasonable possibility of finding and repairing all year 2000 instances before the end of 1999. Executives and managers are urged to explore the year 2000 situation in their own enterprises as rapidly as possible.

Although the year 2000 problem is very serious, the companies and organisations that are able to resolve the problem will find some significant benefits too. Software applications that are year 2000 compliant should be much easier to extend and maintain that their predecessors. Also, the work of solving the year 2000 problem will give enterprises a much better understanding of how much software they own and its business value than has yet been possible.


Chapter -1 Introduction

Gives a detailed introduction to the entire issue of the millennium bug or century rollover.

This is from John Dexter on the newsgroup.
... For some reason, this put me in mind of the story about God deciding to destroy the world. He talks to St Peter about this, and Pete suggests summoning three of the most important men on Earth to forewarn them. So Clinton, Yeltsin and Bill Gates duly turn up at the Pearly Portals, where God tells them he is going to destroy mankind in 1999.

Back home, Clinton calls a press conference - "I've got good news and bad news. The good news is there is a god. The bad news is he's going to destroy the earth"

Yeltsin calls a press conference - "I've got good news and bad news. The bad news is there is a god. The good news is he's going to destroy the earth"

Gates calls a meeting of Microsoft employees - "I've got great news and wonderful news. God agrees that I'm one of the three most important people on Earth, and we don't have to make our software Y2K compliant"

1. Introduction
In popular detective-story fiction, it is well known that poisons such as arsenic accumulate slowly in the body. Tiny doses, each harmless in itself, can slowly accumulate until the victim perishes. In some ways, the "year 2000 software problem" resembles the slow accumulation of arsenic. For many years, software applications have been built with two-digit fields for year dates; i.e. the year 1990 would be stored as 90. To understand the implications of this method of storage, let us look at an age calculation:

I was born 13th February 1976. If I ask the computer how old I am, it subtracts my date of birth from the current date. So it'll perform a calculation similar to 96-76 (using 2 digits for the year information) and gives me the answer of 21 years old. On January 1st 2000, the calculation will be exactly the same. Subtract my birth year from the current year, 00-76 and the computer will proclaim that I'm -76 years old which is wrong.

Year by year these two-digit fields have been accumulating in software packages all over the world. The time is rapidly approaching when the slow and steady accumulation of these two-digit date fields will cause the applications containing them to perish. It may be that some companies will perish with them! Unfortunately this is not harmless fiction. This is the real world.

Since fiscal years are often not concurrent with calendar years, even before the end of calendar year 1999 many applications will stop or will begin to produce incorrect results. Already in 1996 some credit card companies whose cards are valid for five years have encountered the Year 2000 problem.

Computers and hardware devices will be affected by the Year 2000 problem too, since heir internal clocks contain built-in calendar functions. Computers and software now drive the main operating components of every major company, government, and military organisation in the world. Therefore the year 2000 problem is very likely to be one of the most expensive single problems in human history. There are four major aspects of the costs of the year 2000 problem that need to be considered:

The Year 2000 problem will not stop abruptly in the Year 2000 either. Continuing costs for the cases mentioned previously can be anticipated at least through 2005 AD and some will probably run even further.

One surprising aspect of the year 2000 problem is that some benefits can be envisioned as well as costs. Once the problem is fixed, enterprises will have far better data dictionaries than ever before. They will also have a much better understanding of the size, age, and complexity of their software portfolios and data bases. In particular, organisations will begin to know how much of the contents of their portfolios are active applications, and how many applications are dormant and have stopped being used. Recall that major disasters such as the San Francisco fire and the Tokyo earthquake led to significant improvements in architecture and construction so that buildings are now much safer than they were prior to these disasters. It is likely that software applications constructed after the year 2000 crisis will be much safer and more stable than those built in the past. Just as earthquakes and disasters tend to destroy unsafe structures, the year 2000 problem will probably destroy or eliminate a host of poorly structured, poorly maintained applications because it is impossible to change them.

In addition, enterprises will learn much more about their future software needs and the costs of both building and maintaining software than they know today. An unexpected by-product of the year 2000 problem is that software may finally become a commodity with tangible economic aspects.

1.1 Root Causes of the Year 2000 Problem
This can be traced back to the early days of computers, when information was stored on punched cards. Data storage was so limited and so expensive that any method that could save storage was readily adopted. Since no one in the 1950’s or 1960’s had any idea how long software would last, it seemed natural to store dates in two-digit form; i.e. 1965 would be stored simply as 65. This method was convenient and seemingly effective.

When magnetic storage was first introduced the cost of data storage declined slightly, but the early tape and disk based systems still were limited in capacity. Also, many card-based systems were transferred to tape or disk. But the original versions of the source code and the two-digit date logic continued to be used since there was no immediate reason to change it.

By the late 1970’s and early 1980’s it started to be noted that software applications were sometimes having remarkably long lives. For example, IBM’s MVS operating system was approaching 20 years of age, as were a number of other widely used applications. Some tremors of alarm about date limits began to show up, but there was still no immediate serious alarm since the end of the century was 20 years away.

It was not until the early 1990’s and the advent of optical storage that data storage costs declined to such a level as to be almost irrelevant. The early 1990’s would have been the best time for addressing the Year 2000 problem, but for sociological reasons the human species is not very effective in disaster prevention.

Also, by the 1990’s quite a significant amount of the damage had long been done. Millions of applications with two-digit date fields had already been written and many of them were in daily use throughout the world.

1.2 Hazardous Implications
Many applications will be affected by the year 2000 problem but the problem is not restricted to ageing legacy applications. The year 2000 problem is also common in modern personal computer applications, and even embedded in the hardware of both mainframes and personal computers. Any software package that uses dates or has calendar routines as embedded functions is likely to be affected by the year 2000 problem. Some common applications that will have to be modified include:

The most serious implications are the litigation consequences of the failure of calendar routines. Many important financial applications will be affected. Worse, some of the consequences may even threaten human lives and safety.

The end of the 20th century is likely to be a very hazardous time for many executives, and for almost all software executives. Any executive who is in a position of fiduciary responsibility should by now be taking energetic actions to solve the year 2000 problem. These same executives should also be in discussion with their legal counsels regarding the probable liabilities that they and their companies will be facing over the next 48 months and on into the 21st century.

Governments are not immune from the year 2000 problem. All government agencies associated with revenues such tax offices are probably going to have major year 2000 problems. This is also true of offices such as social security that deal with benefits. While national government will be the most heavily impacted by the Year 2000 problem in terms of the volume of changes needed, the host of provincial, and local government bodies that use computers are likely to be damaged also. It can be anticipated that major errors are likely to occur in a variety of governmental applications dealing with welfare, unemployment, taxation, even mundane accounts payable and receivable. A very likely by-product of the Year 2000 problem will be sharp increases in local taxes to defray some of the Year 2000 expenses.

Although the military implications of the year 2000 problem are not widely discussed in the software press, the on-board computers in many weapons systems, ships, tanks, and military aircraft are going to be affected by the year 2000 problem. Logistics systems and various command and control systems will also be affected. Since the UK military services are one of the most automated and computerised armed forces in the world, the Ministry of Defence (MoD) will be facing one of the largest military expenses in human history.

1.3 Beneficial Implications
Since the magnitude of the year 2000 hazards are so enormous, most of the software literature has focused on the negative side of the problem. What is somewhat surprising until considered, is that there will be some significant benefits associated with solving the year 2000 problem.

Most companies do not really know how much software they currently own, and do not even have a clue as to how much software they truly need. Even worse, most companies do not know how many of the application they own are active and still being used, or dormant and simply taking up space because there is no mechanism for retiring unused applications.

These statements are true of data bases and information owned by enterprises. Also, both data bases and legacy applications tend to be added in a patchwork fashion in response to random but urgent needs. Very few enterprises have really effective data dictionaries and some do not even know how many data bases they own. As a result, two of the most vital and expensive resources we have, software and data, have no solid economic understanding.

In order to solve the year 2000 problem and minimise the hazards, enterprises will be forced to develop a very detailed inventory of the software applications and databases which they own. In addition, it will be necessary to develop a very detailed enterprise wide data dictionary. Therefore as companies begin to solve the year 2000 problem, they will find that they have much better knowledge and control over their software than they have ever had before. Within a few years after the end of the century, the companies that have solved their year 2000 problems will be in a very strong position to plan new applications and business strategies.

Not only that, but the year 2000 problem itself is really only the tip of the iceberg. Date fields are not the only kinds of fields that were arbitrarily truncated to save space. Many applications also have trouble with financial calculations, name fields, and other kinds of information because not enough space was allocated when the applications were built. The same tools and methods being applied to the year 2000 problem can also be applied to similar topics. Thus software created after the end of the 20th century should be far better structured and more robust than software typically created before the end of the 20th century.


1.4 Fallacies
Problems of the magnitude and seriousness of the Year 2000 problem are difficult to encompass mentally, and hence many executives are in what psychologists call the "denial phase" or asserting that the problem is not really going to occur. The software trade press has alternated between denial and exaggeration of the problem, with some articles asserting that the Year 2000 problem will blow over, while others assert that the problem is severe enough to trigger a business depression and cause bankruptcy of a significant percentage of UK corporations.

One major fallacy is that there is no particular hurry associated with seeking out and fixing the year 2000 problem. Unfortunately, the year 1996 is the last year in which "average" programmers working without sophisticated automation could have had a reasonable chance of finding and fixing the year 2000 problem in a typical mid-sized corporate portfolio of 500,000 function points (the areas where calculations are carried out) in size. Roughly October, 1997 is the last time at which even specialists with automated search engines have a high probability of finding, fixing, and testing the year 2000 problem in a typical 500,000 function point (refer to Chapter 2) corporate application portfolio and finishing prior to midnight on December 31, 1998. This problem must be solved by the end of 1998 so that the companies will have at least one full year to test out the system before implementing it on all the companies' activities. Many corporations will, most probably, be working on this problem right to the eleventh hour of 31st December 1999.

The year 2000 problem may be advantageous for countries such as India and the Ukraine which have a large surplus of software talent that could be applied to either fixing the year 2000 problem or to outsourcing other kinds of work while the UK software personnel are mired down in year 2000 repairs. This problem will also help many developing countries catch up with the developed nations in terms of automation and computerisation. As they are not heavily automated or computerised as we are, they can simply avoid the year 2000 pitfall by buying 2000-compliant software and hardware which are available at the moment and spend proportionately less on repairing their ailing hardware and software.

The most dangerous fallacy about the year 2000 problem is that it will be solved primarily by scrapping ageing legacy applications that embody the year 2000 problem, and replacing them with modern applications that are year 2000 compliant. A look at average software development schedules will illustrate why that assertion is sheer folly. It is now early 1997 and the only applications that could be built and deployed between now and the end of 1998 are those that are less than 1000 function points in size. Any software development project larger than about 1000 function points that starts in 1997 will not be completed until sometime after the year 1999 problem has already occurred. Indeed, for every day that passes the maximum size of software applications that could be completed by the end of 1999 goes down. By the end of 1997, for example, the maximum size would be only 1000 function points rather than 2000 function points if the deadline is the end of 1999 rather than the end of 1998.

Indeed, some applications with year 2000 problems are in the size range of 100,000 function points and would take more than 10 years to redevelop. In other words, none of the major software applications in either the UK or the rest of the world can be replaced between now and the end of the century. You have to fix the year 2000 problem in your current applications, like it or not.

Another fallacy associated with the year 2000 problem is that it can be solved by simply buying software that is already compliant, or even by merging with another company whose software is year 2000 compliant for large corporations. This approach may work in a few rare cases, but is not an effective overall solution to the year 2000 problem. Further, there are many kinds of software where neither packages nor mergers are possible; i.e. weapons systems, defence applications, municipal and provincial government software, embedded software in physical devices such as medical instruments, and a host of other kinds of software where there is no alternative but to actually fix the year 2000 problem in place.

The year 2000 problem is an interesting example of a problem that exerts a strong psychological and sociological impact as well as having a technical impact. No doubt the year 2000 software problem will serve as the basis for many masters and doctoral theses in psychology and sociology in the 21st century.

Chapter 2 - Size of the Year 2000 Problem

Gives the statistics on the extent of the millennium problem and the effort and cost needed to remedy the situation

This is from Paul Schlyter whose home site is
There was once a COBOL programmer in the mid to late 1990s. For the sake of this story, we'll call him Jack. After years of being taken for granted and treated as a technological dinosaur by all the UNIX programmers and Client/Server programmers and website developers, Jack was finally getting some respect. He'd become a private consultant specialising in Year 2000 conversions. He was working short-term assignments for prestige companies, travelling all over the world on different assignments. He was working 70 and 80 and even 90 hour weeks, but it was worth it.

Several years of this relentless, mind-numbing work had taken its toll on Jack. He had problems sleeping and began having anxiety dreams about the Year 2000. It had reached a point where even the thought of the year 2000 made him nearly violent. He must have suffered some sort of breakdown, because all he could think about was how he could avoid the year 2000 and all that came with it. Jack decided to contact a company that specialised in cryogenics.

He made a deal to have himself frozen until March 15th, 2000. This was a very expensive process and totally automated. He was thrilled. The next thing he would know is he'd wake up in the year 2000; after the New Year celebrations and computer debacles; after the leap day. Nothing else to worry about except getting on with his life. He was put into his cryogenic receptacle, the technicians set the revive date, he was given injections to slow his heartbeat to a bare minimum, and that was that.

The next thing that Jack saw was an enormous and very modern room filled with excited people. They were all shouting "I can't believe it!" and "It's a miracle" and "He's alive!". There were cameras (unlike any he'd ever seen) and equipment that looked like it came out of a science fiction movie. Someone who was obviously a spokesperson for the group stepped forward.

Jack couldn't contain his enthusiasm. "It is over?" he asked. "Is 2000 already here? Are all the millennial parties and promotions and crises all over and done with?" The spokesman explained that there had been a problem with the programming of the timer on Jack's cryogenic receptacle, it hadn't been year 2000 compliant. It was actually eight thousand years later, not the year 2000. But the spokesman told Jack that he shouldn't get excited; someone important wanted to speak to him.

Suddenly a wall-sized projection screen displayed the image of a man that looked very much like Bill Gates. This man was Prime Minister of Earth. He told Jack not to be upset. That this was a wonderful time to be alive. That there was world peace and no more starvation. That the space program had been reinstated and there were colonies on the moon and on Mars. That technology had advanced to such a degree that everyone had virtual reality interfaces which allowed them to contact anyone else on the planet, or to watch any entertainment, or to hear any music recorded anywhere.

"That sounds terrific," said Jack. "But I'm curious. Why is everybody so interested in me?" "Well," said the Prime Minister. "The year 10000 is just around the corner, and it says in your files that you know COBOL".

2. Size of the Year 2000 Problem
To some, this might seem a simple issue of replacing all the two-digit year values to four-digits to contain the century value as well. However, there are many hurdles to be overcome in order to achieve 2000-compliance. Below are a few of the more common barriers which make the cost and effort of making systems 2000-compliant astronomical:

The reasons mentioned cause the huge cost of repairing the year 2000 problem. The cost and effort needed are, however, reducing by the growing plethora of tools which detect the presence of date functions in programs written in particular languages. A the moment, the tools available for COBOL programs outnumber the tools available for all other languages.

With the issues mentioned above in mind, this chapter will outline the effort taken by all sections locally and globally and the cost of the expenditure of the effort.

2.1 Efforts in the UK
To address this monumental issue in the UK, a committee called Taskforce 2000 was established by industry at the invitation of Ian Taylor, the former M.P. Minister for Science and Technology. It has received backing from a broad range of organisations in both the private and public sectors and is co-sponsored by the Confederation of British Industry and the Computing Services and Software Association with an initial fund of £170,000 provided by the Department of Trade and Industry. The Taskforce is headed by a Chief Executive, Robin Guenier, and who may be contacted at

The primary role of the Taskforce is to raise awareness of the year 2000 problem, co-ordinate activities and look for ways forward. The Taskforce has set its first objective - "to ensure that, by the end of March 1997, main board level executives in every company in the UK are aware of the problem." To achieve this goal the Task Force will develop a communication and education programme which will include a helpline, newsletter, a World Wide Web Internet site, workshops, conferences and videos.

In the government sector, Mr. Taylor had asked the government departments to draw up action plans to show how they will deal with the problem internally and to assess how much of a problem there might be for any industrial sectors they sponsor. Due to his actions, many government departments have finished carrying out impact analysis on their system. In the case of the Home Office, only 4/5 of their systems will be completed by the end of 1999 while the remaining 1/5 will be solved at a later on. This will, however, not affect the Office as all their mission-critical systems will be in perfect working order. The UK has also taken the initiative over the millennium date change within Europe, and had put the issue on the agenda for the European Telecommunications Council which took place on the 27 June 1996.

Due to the late start of the year 2000-compliance repairs in the UK, it has been difficult to obtain statistics on the problem. In America, however, where the efforts began a year or two before us, much research has been conducted and some hard data is available. Although the data is US-centric, I believe that the data is relevant to us without much compromise. But before we plunge into the numbers, there is a need to explain the use of function points (FP) versus lines of code (LOC)in the calculations of cost.

It is the belief of many experts in the software field that the LOC metric is not accurate enough for serious economic analysis of software problems. According to a recent survey of software journals carried out by Software Productivity Research Inc, based in the US, one third of the software literature used physical line as the basis for determining lines of code, one third used logical statements, and the remaining third did not identify which method was used. This is not acceptable as the physical lines and logical statements vary great among the 500 more commonly used languages. For example, it is very difficult to enumerate LOC for languages for languages such as query-by-example (QBE), the control functions of Visual Basic, spreadsheets such as Lotus and Excel, database and a host of others. In COBOL (the language in which most legacy applications are written and most research has been done), the difference between the number of physical lines and logical statements can amount to more than 300%. Thus it can be seen that the ambiguity associated with using LOC is far too great for a economic study.

In turn, the data in this report uses function point metric. This originated in the 70’s within IBM and has become the most widely used (although the Gartner Group has published extensive reports using LOC) metric in the software world. The International Function Point User Group (IFPUG) is the largest software measurement association in the world. The function point count of a software application is based on enumerating five external attributes of the application:

These five attributes are assigned various weighting factors and there are also adjustments for complexity. For further clarification, please refer to Applied Software Measurement (McGraw Hill, 1996).

By an interesting coincidence, each reference to a calendar date in a software application seems to require approximately one function point to encode in quite a large variety of programming languages. This coincidence makes expressing the effort and costs in terms of workhours per function point, FP per staff month and cost per FP comparatively simple.

The following sections will examine the year 2000 repair efforts with respect to the different industries, company sizes and programming languages.

2.2 Year 2000 Repair by Industry
The year 2000 problem may well be one of the largest and most expensive technical problems in all of human history as it appears that the problem is large enough for every technical worker in the software domain to be fully engaged for more than four months between now and 1999. The following table shows the approximate effort in terms of expended person months and costs between now and the end of the century on a per capita basis for the different industries.




Months per staff member Costs per capita $
Military 9.55 71591
Insurance 5.00 46000
Communications 4.24 42353
National Govt. 5.33 42133
Retail  5.50 41250
Wholesale 5.18 38824
Services 4.44 35556
Municipal 5.00 35000
Other 4.00 33600
Finance 3.00 33000
Health Care 3.72 29750
Defence 2.67 29333
Energy 3.50 28000
Transportation 3.28 26250
Software 2.58 23211
Manufacturing 2.22 18867
AVERAGE 4.41 36851
Source: SPR, USA


2.3 Year 2000 Repairs by Company Size
This section gives the cost to an enterprises rather than the country or industry and would be of interest to many. To calculate such a cost for a particular enterprise would require an on-site study of each enterprise to quantify the exact costs. However, by making a few general assumptions, it is possible to state the approximate overall costs of fixing the year 2000 problem for enterprises of various sizes. Table below is based on the total number of technical software staff employed, and shows approximate costs for enterprises with as few as five technical personnel, up to enterprises with as many as 10,000 technical personnel.

Some of the background assumptions going into table 11 include:
· A generic burdened cost per staff month of $8400 is assumed.
· Large enterprises are geographically dispersed, and this raises repair costs.
· Large enterprises have more large systems, and they are harder to fix.
Software Staff Portfolio size in FP Effort in Months Total costs $ Cost per FP $
Source: SPR, USA

The data above has a significant error and is not a substitute for through on-site analysis of the company’s portfolio. To get more accurate data, the analysis should be carried out using the guidelines below:

1) Quantify the size of your portfolio of legacy applications.
2) Quantify the size of your software data bases and repositories.
3) Explore the incidence of year 2000 references in your legacy applications.
4) Explore the incidence of year 2000 references in your current data bases.
5) Estimate the effort to repair each year 2000 reference.
6) Estimate the effort to test and validate each year 2000 reference.
7) Estimate the "bad fix" injection potential of faulty year 2000 repairs

2.4 Year 2000 Repair by Languages
It is also interesting to consider the approximate costs of the year 2000 problem for selected programming languages. The table below gives the cost per language.





Function Points


$ per FP


Total Cost

COBOL 605,000,000 $28 $16,940,000,000
Spreadsheets 54,000,000 $35 $1,890,000,000
C 156,000,000 $35 $5,460,000,000
V-Basic 45,000,000 $30 $1,350,000,000
Query 29, 250,000 $40 $1,170,000,000
Data Base 120,000,000 $45 $5,400,000,000
C++ 105,000,000 $35 $3,675,000,000
PASCAL 54,000,000 $40 $2,160,000,000
Assembly 93,750,000 $80 $7,500,000,000
Ada83 54,000,000 $35 $1,890,000,000
FORTRAN 28,750,000 $35 $1,006,250,000
PL/I 13,500,000 $65 $877,500,000
Jovial 7,875,000 $60 $472,500,000
Other 336,000,000 $60 $20,160,000,000
TOTAL 1,702,125,000 $45 $69,951,250,000
Source: SPR, USA

Although COBOL is the language with the greatest number of year 2000 "hits" it will probably be among the least expensive to modify due to the large numbers of specialised tools and consulting groups in the COBOL domain.
Dr. Tom Love of the Worldstreet Journal software company and a well-known expert on OO topics reports that object-oriented languages such as Objective C, Smalltalk, Eiffel, etc. should be among the least expensive if the applications are well formed and the date calculations are handled by formal class libraries. Indeed, since object-oriented business applications are comparatively recent, many may already use adequate space for all date digits and hence the year 2000 problem may not be present in some OO applications. On the other hand, the OO paradigm has a steep learning curve and there may also be OO applications with incorrect date calculations "hard coded" into the application just as they would be in procedural languages.

The most expensive languages will probably be assembly language and PL/I, both of which have shortages of tools and trained personnel.

2.5 Global Year 2000 Repairs
The Year 2000 problem is an interesting one because it affects industrialised nations more severely than those which are less dependent upon computers and software for business and government operations. Although the year 2000 problem is of global concern, it is starting to appear that the most heavily industrialised and computer-intensive countries are going to bear the brunt of the expenses: The United States, Japan, Germany, France, the United Kingdom, and Brazil will probably be the most heavily impacted. Conversely, countries such as India and the Ukraine may find themselves in an advantageous position as a result of the year 2000 problem, since they will probably have a surplus of skilled programming personnel available during a period that the heavy software countries are mired down in year 2000 repair work.

The following table gives a rough approximation of Year 2000 software repair effort in some countries .
Country Software Staff  Portfolio in Function Points Year 2000 hits in Function Points Year 2000 Repair (Months) Year 200 Repair Costs $
United States 1,920,000 1,570,560,000 149,203,200 9,325,200 74,601,600,000
Japan 900,000 738,000,000 70,110,000 4,381,875 42,066,000,000
Russia 770,000 539,000,000 51,205,000 3,200,313 12,801,250,000
Germany 550,000 440,000,000 41,800,000 2,612,500 24,035,000,000
UK 390,000 312,000,000 29,640,000 1,852,500 17,043,000,000
Brazil 475,000 308,750,000 29,331,250 1,833,203 14,225,656,250
France 385,000 308,000,000 29,260,000 1,828,750 16,824,500,000
China 990,000 297,000,000 28,215,000 1,763,438 1,763,437,500
Italy 375,000 290,625,000 27,609,375 1,725,586 13,390,546,875
India 750,000 225,000,000 21,375,000 1,335,938 1,603,125,875
South Korea 300,000 210,000,000 19,950,000 1,246,875 8,977,500,000
Ukraine 260,000 195,000,000 18,525,000 1,157,813 4,168,125,000
Mexico 275,000 178,750,000 16,981,250 1,061,328 7,641,562,500
Spain 235,000 170,375,000 16,185,625 1,011,602 6,878,890,625
Canada 185,000 144,300,000 13,708,500 856,781 7,196,962,500
Turkey 210,000 141,750,000 13,466,250 841,641 6,228,140,625
Thailand 175,000 105,000,000 9,975,000 623,438 3,241,875,000
Source: SPR, USA

On a global scale, the cost of repairing the year 2000 problem is around $600 billion (£400 billion). Although these figures are incredulous, they are the only data available and only suitable for discussion and for preliminary analysis. However, the importance of the year 2000 problem is such that publishing preliminary data with a high margin of error may be better than waiting for corrected data, since the end of the 20th century is approaching very rapidly.

From the data, we see that the U.S. is the country with the largest software portfolio and thus it will be the most heavily impacted by year 2000 repairs. This fact may give other countries a chance to make significant headway in global software markets in several fashions:  

A possible business outcome of the Year 2000 problem is that the United States will lose its dominant market position in the software industry, while countries such as India, China, Russia, and the Ukraine gain market shares since they are not as heavily impacted by Year 2000 work and will have a substantial surplus of software technical personnel while the U.S. enters a period of shortage.


Chapter 3 - Solutions to the Year 2000 Problem

Gives the various technical solutions available and the state of computer hardware and software in terms of the century rollover

From an ex-field sales/support survivor:
'I used to work in a computer store and one day we had a gentleman call in with a Year 2000 date problem. The telephone support representative was having a bit of trouble convincing this guy that he had a BIOS problem.

Service Rep: 'Sir, your BIOS needs an update.'

Customer: 'I just bet that there is some command that I can put into the AUTOEXEC.BAT file that will take care of this.'

Service Rep: 'There is nothing that Operating System or Application Software can do to help you with this problem.'

Customer: 'I know that there is something I can put in... some command... 'maybe it should go into the CONFIG.SYS.'

After a few minutes of going round and round...

Service Rep: 'OK, I am not supposed to tell anyone this but there is a hidden command in some versions of DOS and WINDOWS that you can use. I want you to edit your AUTOEXEC.BAT file and add the last line as C:\DOS\FIXBIOS and reboot your computer.'

Customer does this.

Customer: 'It is still going back to 1984.'

Service Rep: 'I guess you'll need to call Microsoft and ask them for a patch for the FIXBIOS.EXE.'

The customer then hung up. We thought that we had heard the last of this guy. But NO; he called back four hours later!

Service Rep: 'Hello, Sir, how is your computer?'

Customer: 'I called Microsoft and they said that my BIOS is incompatible with their FIXBIOS.EXE and that I need to get a new one. I was wondering when I can have that done and how much it will cost...

3. Solution to the Year 2000 Problem
Despite the size of the cost and effort required to overcome the problem, it must not be forgotten that this is mainly a managerial problem rather than a technical issue. Effective planning, delegation and monitoring of the year 2000 project will lead to a satisfactory conclusion. This chapter will however deal with the technical solution issues of the year 2000 and the managerial solution aspects of the problem will be dealt with in the next chapter.

3.1 Criteria of a solution to the year 2000 problem
The criteria mentioned below have been taken from a Joan Morgan’s winning entry in the Gilbert & Tobin’s ‘Millennium Bug-off’ competition held in Australia. She is the Project Leader Information Technology of TABCORP in Melbourne. For a further detail on the legal clauses regarding the entire year 2000 issue, please look at the Gilbert and Tobin homepage.

Criteria which a product or solution must satisfy:

  1. deal properly with the transition from 31st December 1999 to 1st January 2000;
  2. deal properly with leap years;
  3. deal properly with all calculations based on dates, including calculations such as subtractions, additions, percentages, sequences, comparisons;
  4. deal properly with functions that are programmed to commence or end on a particular date.
Thus any solution implemented in programs must ensure that it does not fail any of the criteria mentioned.

The next section will speak of the more commonly used techniques in eradicating the year 2000 bug.

3.2 Programming solutions
The most common method of solving the problem is to simply look for all occurrences of dates and change the year digits from two to four. There other methods as well, some of which are much more esoteric. Two of the less profound methods are outlined below.

3.3 Comparison between procedural and data change
The solutions mentioned above belong to the two classes of procedural and data change. The data change is updating the year information from two digits to four and the procedural solution is using programming techniques to infer the century without updating the year information.

Arguments supporting each approach typically presume that only one can be the right answer. Supporters of the data solution will argue that the mathematics were always correct, but the data was incomplete. Supporters of the procedural solution will counter that the century is usually inferable and that the code should have been written better. It matters little whether you determine that the bridge was too low, or the load was too high, when altering either or both will get you past the obstacle.

The choice between the data and procedural approaches should be a cost-benefit trade-off rather than dogmatic adherence to either. Each offers advantages and disadvantages. Rarely would either be categorically favourable for all of an organisation’s software. Below is the list of arguments for and against procedural and data change.

Arguments For the Data Approach

Arguments Against the Data Approach Arguments For the Procedural Approach Arguments Against the Procedural Approach 3.4 Case studies for different hardwares and softwares
This section outlines the problems faced by the many computer hardwares and softwares and some of the solutions used to overcome the millennium difficulty.

Personal Computers (PC)
The computers referred to here are the IBM-compatible PC’s. Most of the personal computers in operation today will be unable to advance their hardware-based system dates to the year 2000 without intervention through the system BIOS.

It is most likely to happen to PCs that are powered off at the time of the century rollover, and then powered up on January 1, 2000 or after. Unlike the larger software applications problem, the hardware date problem is quite easily remedied with a change of the CMOS that stores the BIOS. If the PC is not switched off at the century rollover, the BIOS will register a date of 1900 while the operating system will most likely have the accurate post-2000 date. However, if the computer is rebooted again in the year 2000, the operating system will give a pre-2000 date; in the case of MS-DOS, the date becomes January 4th 1980 while the BIOS would still report 1900. This problem, of course, only applies to non 2000-compliant operating systems. Although the hardware part is solved with merely the switch to a new CMOS, the ramifications of not fixing it, however, can be major.

There is a software solution to the CMOS problem. A software patch can be created that will intercept every call to the operating system date and add 100 to the year that is passed back to the software making the date request. However, the trouble is that the software patch cannot update the date when the call is made at a ‘low level’ and the request is not trapped by the operating system (OS).

Apple Macintosh
The MacOS operating system and Apple Macintosh computers do not have problems with the year 2000. All MacOS operating system date and time utilities have correctly handled the year 2000 since the introduction of the Macintosh. The original date and time utilities (introduced with the original Macintosh 128K in 1984) used a long word to store seconds, starting at January 1, 1904. Starting with a long word of seconds since January 1, 1904 means that dates run out at 6:28:15 a.m. on February 6, 2040.

VMS is YEAR 2000 Compliant. VMS uses a time format that stores microseconds. It allocates 64 bits of information. Because 64 bits is so large, even with microsecond resolution this timer won't overflow for another 584,000-odd years.

UNIX and C/C++
UNIX/ANSI C defines a "struct tm" structure for broken-out time fields. The year is offset from 1900 and some libraries have improperly handled years outside of the range [00..99]. Many application programs also, have problems with this. Some accept "100" to indicate 2000. Some will print back dates like "01-01-100" (instead of "01-01-00"). Others will complain about the user’s ignorance -- years should be two digits only. Other than that, this time structure has no meaningful "important" dates where doomsday occurs.

The systems do sometimes achieve odd things in the year 2000. Some dates come up as 01/02/100 on the screen when the record is created, but are stored as 01/02/10. For example, assume an application is using tm_year to retrieve the current year. Just so happens that tm_year starts in 1900, where 2000 is year 100. The application is probably using a sprintf into a char[2] field. This will not print the correct result.

UNIX keeps the date and time as the number of seconds that have elapsed since 0000 hours UTC, January 1, 1970. It keeps this count in a 32-bit signed integer. The count will overflow on January 19, 2038, when the number of seconds reaches 2,147,483,647, the maximum number that can be represented in a 32-bit signed integer. All versions of C and C++ use this same format for certain library functions. This [rollover in 2038] is more serious than the year 2000 problem. UNIX is too heavily embedded in our infrastructure, and this format is now standard for most C/C++ programs. That means it is extremely widespread and repair would mean unravelling the entire computing infrastructure that has been built up.

Chapter 4 - Action Plan for a company to achieve      2000-compliance



4. Action Plan for a company to achieve 2000-compliance
The year 2000 (Y2K) debugging project is like no other project that any corporation or large organisation has ever had to face. The result of this project will determine the possible future existence and success of the corporation. This project requires the full co-operation of all levels of management within all departments in the organisation to win the battle to become year 2000 compliant and to insure that outside entities do not affect your products or services.

The initiative, as for most schemes in most organisations, has to come from the top i.e. the Chief Executive Office (CEO). It is the task of the Information Systems (IS) manager or risk manager to make the CEO and other executive personnel aware of the problem and its all-encompassing effect on the business. Many well-written background articles about the millennium bug are available for distribution at the Year 2000 Information Centre, set up by a consultant, Paul de Jager, and Tenagra Corp. ( Some of the year 2000 concerns that must be addressed are listed below again:

Only the CEO has the power to organise the company resources to prepare appropriate risk management and marketing strategies to deal with these corporate threats or take advantage of market opportunities. Enlisting the full support and commitment of the CEO's office into this effort will be the gateway to removing this threat. In order to convince the executives, it is important to look beyond the year 2000 hype and identify factual evidence that will convince them. The coverage the problem is currently receiving (press, seminars, Internet, personal contacts) may be enough to convince the executives to allocate budget and authority to solve the problem. If this isn’t the case, a vulnerability check must be done.

Vulnerability Check
The aim of a vulnerability check is to gain evidence of how seriously the organisation could be affected by the year 2000 problem. This is not a full assessment of all the systems. To run a vulnerability check, one needs to:

There are many possible tests. One of the simplest amongst these is to enter a post-2000 date into every date field on the system and another is to reset the underlying system clock on the computer. Examine also the treatment of leap years in the business processes together with items such as payment dates, ages and the order in which output is sorted.

There need not be much testing; only a reasonable amount of evidence is needed to convince the executives that a serious problem needs addressing. Concentrate on finding financial errors, incorrect rejection of valid post-2000 input, complete system crashes. Tie-in the results of the vulnerability check into the organisation’s key business processes. The executives are most likely to be swayed by evidence of the year 2000 problem in terms of its impact on the business rather than the IS themselves. If the impact can be quantified in terms of lost income or lost profit - one will have a persuasive argument. The internal auditors within the organisation may be able to assist in presenting the test results in a manner that will convince the executives. The internal auditors tend to have alternate reporting lines that allow them to escalate issues of concern to the board very quickly. They also often have links with external auditors who might be able to bring pressure to bear on the board. If the actions of other organisations in the industry are publicly available, include this in the information put before the executives.

If the budget or resources to run tests on a development or disaster recovery facility are not available initially, one may need first to perform a paper-based exercise. Attempt to determine the financial impact on the organisation if each (or a combination) of the key systems were out of action for a range of time from a few hours to a number of days. By presenting this information you may be able to secure some budget to perform a vulnerability check.

Once the executives are aware of the gravity of the situation, the best way to facilitate and co-ordinate the company’s efforts to be year 2000 compliant is to establish a Y2K Office. Thus, the first action to take is to make the executives aware of the problem and then set-up a project office.

The Year 2000 Office
This office will be the single focal point within the company, that ensures that the company or organisation is year 2000 ready and survives beyond January 1, 2000. The office will co-ordinate year 2000 risk assessments, year 2000 marketing opportunities, and year 2000 action plans at all levels within the company and ensure the appropriate completions. The office should also co-ordinate year 2000 awareness and communications activities for employee's, external customers, shareholders, suppliers and government agencies.

The Y2K office manager will report directly to the CEO and provide the CEO and executive management with periodic status reports on the progress of all year 2000 efforts. Now let us examine the main concern areas for the office.

Information Systems concern
The role of Information Systems on the Year 2000 project has several dimensions: System conversion, issue tracking/resolution and consulting for non-IS supported risk areas.

The most important role is to ensure all the business application systems, and all the hardware, will process dates correctly. This starts with an inventory of business applications and hardware equipment, which is then assessed for date sensitivity.

The inventory might include the following categories below:

Next the conversion, replacement or retirement of the date sensitive business systems and hardware is planned. Before a pilot conversion can take place, the testing environment must be set-up, outside service arrangements made and then the first pilot conversion begins. After the first pilot conversion, the process is reviewed and improved. Then the remainder of the conversion effort starts. System replacement and retirement plans need to execute concurrently. If hardware and supporting software require upgrading or replacement these plans need to be set into motion. During all the conversions, replacements, retirements and upgrading, IS monitors the project's progress and reports status to executive management and the project office. The underlying technical changes are not particularly difficult, however the key challenge is managerial. Let us examine the procedures mentioned in greater detail. The main steps are:
  1. Performing triage
  2. Assessing the system
  3. Repairing the system
  4. Testing the fixed system
  5. Implementing the tested system
1. Performing triage
Performing triage on the systems is an approach to managing the overall project. Triage is essentially the classification and prioritisation of the systems in terms of their survival and the corresponding actions on the systems with the deadline and limited resources in mind. The three general categories for a system are: When performing triage, IS needs to find out how soon the system is likely to suffer from Year 2000 problems. Some systems have been using post-2000 dates for ages but that does not exclude the possibility of a crash in the near future.

2. Assessing the system
The aim of the assessment is to determine the state of a potentially vulnerable system in detail and identify the changes needed to make it Year 2000 compliant. There may be a need to acquire tools and/or services to perform assessment. To see details on how to choose reliable vendors, please refer to the Appendix. Vendors of such services should at a minimum be following a process that can be mapped onto these guidelines. The two main types of assessment are:

3. Repairing the system
Each system fix should be run as a separate project and there may also be a need to run an interconnection project and an external interface project. As for hardwares, it will be necessary to establish a hardware replacement or upgrade project. This stage will include:  
4. Testing the fixed system
There are many tests that must be done - at a minimum these should include:   The industry estimates suggest that testing may take 50% to 70% of the programme effort.

5. Implementing the tested system
When the tested system is made live, consider:

IS must monitor the systems to confirm that the fixes do work in practice and brief users on symptoms of possible problems and identify recovery scenarios if problems do arise with fixed systems.

These steps in the stages mentioned have to be taken across all the systems in the organisation for which IS responsible. IS must monitor the project's progress and reports status to executive management and the project office. The steps mentioned are not just restricted to IS systems but can be applied to all systems in most departments. They are the general guidelines to making a system 2000-compatible.

Ordinarily, IS is responsible for the conversion of the business application systems but because of the nature of this project they may have to offer their services in the co-ordination of the conversion efforts in areas of the company that IS does not support directly. It will be imperative that each department performs an inventory and a date sensitivity assessment on their computer-based tools, products and on their manual processes where dates might be used: i.e. pre-printed forms.

In this project there will be many issues, some political and some with costly solutions. Managing these issues to a successful resolution will be a large task. IS will be able to handle the issues related to business applications, but may not have visibility to non-IS supported areas unless involved with the co-ordination of the companies effort at the highest levels.

Marketing concern:
Corporate Marketing has two major areas to determine the real threats or opportunities. The first has to do with your customers. The second has to do with your competitors and your competitive advantages.

First, as a result of not taking corrective action in time, some of your customers will go out of business. This will result from several possibilities, but the root cause will be the inability to process dates correctly, thus causing their businesses to fail. Marketing must attempt to identify key customers and make sure they have a Year 2000 conversion plan in place and completed on time. This might involve contract re-negotiations and audits of the customers’ year 2000 conversion plans through their project office.

Second, by not taking corrective action in time, some of your competitors will go out of business. This will represent an opportunity to your company, IF you are prepared to seize it. An assessment of your competitors and their Year 2000 efforts and likely success needs to be performed. If they are in markets you want to improve on, then you can make action plans to focus on their year 2000 weaknesses.

A similar sort of accounting must also be made on the purchasing side. The office must ensure that supplies will be uninterrupted and year 2000 compliant. This will involve some communication with your supplier’s project office. Some of existing contracts might need renegotiations and all future contracts must have clauses concerning the YEAR 2000.

As a result of your company taking Year 2000 corrective action now, you will gain a competitive advantage over your competitors. This fact can be used to your advantage over the coming years. The office needs to assess these areas and determine whether or not these are real threats or opportunities that your company will need to address. As necessary actions plans must be developed and completed. Company wide activities will need to be co-ordinated.

Legal concern:
The Year 2000 issue is a matter that has many legal implications. All executive management and directors of a company can be held accountable if "Due Diligence" cannot be proved on a given matter in a lawsuit. Customers, vendors, the government and shareholders might sue your company and you might decide to sue some of them.

All customer, business partner and supplier contracts should be reviewed and possibly renegotiated with a Year 2000 focus as mentioned in the previous area of concern. The corporate Legal department must assess these risks and advise the CEO on the correct actions to be taking now, so that the company can't be sued later or can be defended successfully.

Internal/External Relations concern:
As the year 2000 draws closer the pressure from outside sources will be substantially more than what it is at the moment. Customers must be reassured that their service or product supplier company will be able to meet their needs beyond the year 2000. Your shareholders and financial partners will want similar assurances, internal management and/or employees will want to be informed of the activities going on and how they might be effected or what they might be asked to do to help.

There may need to be a newsletter published to shareholders, internal management and employees. Your customers might be able to have their concerns answered through a corporate web page focusing on your Year 2000 efforts within your company. A help desk may need to be created to respond to internal and external questions, both technical and general. The external Public Relations (PR) department could work with the marketing departments to present favourable information to external entities. The project office can help co-ordinate these efforts to insure their success.

Facilities and Security Management concern:
All environmental, telephone, and security systems must be inventoried and assessed for possible year 2000 risks. This may result in conversions or hardware and software replacements. Plans will need to be created, executed, and costs allocated for successful transition to year 2000 compliant business infrastructure systems.

As you can see this is not just an information systems issue. This could be a battle of survival for most enterprise. If after a cursory look you decide there is some validity to these risks or opportunities, then that is the time to set-up your year 2000 office, find someone to manage the office, and assign them the responsibility of resolving your year 2000 issues.


Chapter 5 - Litigation Potential for the Year 2000 Problem


5. Litigation Potential for the Year 2000 Problem
The most alarming component of the year 2000 problem are the potential expenses for litigation and possible damages for not fixing the year 2000 problem. Six kinds of litigation can be envisioned in the context of the year 2000 problems:

Potential litigation is not easy to predict. Furthermore, when litigation does occur the outcome is not easy to predict. It is possible that the litigation expenses (and any damages if suits are lost) for the year 2000 problem can exceed the direct costs of repairs by as much as 20 to 1 in cases where negligence and violation of fiduciary duty are proven or at least confirmed by jury decisions.

The table on the next page (given by Morgan Consultancy, US) shows the litigation potential for the industries discussed thus far for four of the six kinds of litigation. Suits against vendors are included under "client suits" rather than being shown separately. Suits against hardware vendors would be distributed across the other categories.




Client Suits Shareholder Suits Class Action Suits Injury Suits 


Military Low Low Very High Low
Finance High High Low High
Manufacturing High High High High
Communications High High Low High
Services High High Low High
Insurance High High Low High
Wholesale High High Low Low
National government High None High High
Defence High High High High
Retail High High Low High
Software High High Low High
Municipal High None Low High
Health Care High High High High
Energy High High Low High
Transportation  High 


High Very High High
Litigation Potential for Failure to Repair the Year 2000 Problem

The senior executives of corporations have what is called a fiduciary responsibility to act in the best interests of the shareholders of the companies they serve. Failure to take action to repair the year 2000 problem has at least the potential to damage or even end the careers of about half of the senior executives in the UK.

Legal fees and damage awards for the Year 2000 problem are difficult to estimate using any kind of historical data, since a problem of this magnitude has not occurred before. Since major companies are very likely to end up suing each other, the potential of damages paid out might be offset by damage payments that come in. However, it would be surprising if less than £10,000,000 per company ends up being paid out for Year 2000 damages among the Fortune 500 class of enterprises here in the UK according to Morgan & Stanley, a consultancy firm.


Chapter 6 - Conclusion


6. Conclusion
The year 2000 problem is rapidly approaching, and is one of the most critical issues ever faced by the software industry or by any industry for that matter. Because the year 2000 problem has been developing for 25 years and affects many ageing legacy applications, the one-time costs for year 2000 repairs are going to be alarmingly high.

However, the year 2000 problem cannot be ignored and will not go away by itself. The best response to the year 2000 problem is a rapid and energetic attack as early as possible. The worst response is to ignore the problem or to understate its importance.

Dr. Krysia Broda -Project supervisor
Thank you very much for your personal interest in this area and advising us when we missed the target

Hiran Sumanaweera –HTML programmer
Thanks the eleventh hour HTML debugging

Viasoft Inc
Computing Services and Software Association
Computer Associates Limited
Federation of Electronic Industries
Cap Gemini
Confederation of British Industry
Delphi Horizons 2000
British Computer Society
Year 2000 Information Centre
Institution of Electrical Engineers
UCISA (an association of UK universities)
Y2K Watch -Digital Plague Oozes across the Planet
A report by Charles E. Phillip and William Farrell who are working in Morgan Stanley - US Investment Research Section


8.1 Evaluation of the tools and services of a proposed year 2000 vendor
The following checklist of key capabilities may be of use:

The year 2000 consulting, repair, and tool business is so new that a full evaluation of its effectiveness is still largely unknown. Hopefully the major vendors in this domain are fully qualified and capable for the work at hand.

However, a strong caution is indicated. Problems of the seriousness of the year 2000 problem will attract many vendors with marginal capabilities. You should exercise due diligence in selecting an outsource vendor for performing year 2000 repairs. If the vendor fails to safely repair the year 2000 problem in your portfolio, it will be too late to resolve the problem via arbitration or litigation.

8.2 Year 2000 Conversion Checklist
The objective of the Year 2000 Conversion Checklist acts as a simple guiding principle of the core issues that need to be addressed when organisations undertake the strategic Year 2000 Conversion. The checklist is provided by Singapore National Computer Board.

  1. Top Management Awareness, Commitment and Support
  2. Year 2000 Conversion Project Budgeting
  3. Project Planning and Scheduling
  4. System Development Life Cycle
  5. Outsourcing
    1. Benefits of Outsourcing
    2. If organisation does decide to outsource it should be selective in what it chooses to outsource.
    3. Points to Note