Jeyakody Kesavan
Arasnath Kimis
A SURPRISE 1997 Presentation
Table of Contents
Overview
Overview
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 comp.software.year-2000
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:
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 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 http://spitfire.ausys.se/psr
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:
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 100450.3153@compuserve.com
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:
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.
|
Industry
|
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 |
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 $ |
|
5
|
6,000
|
23
|
197,784
|
33
|
|
10
|
11,500
|
45
|
379,087
|
33
|
|
25
|
27,500
|
107
|
906,511
|
33
|
|
50
|
50,000
|
194
|
1,648,203
|
33
|
|
100
|
95,000
|
416
|
3,523,033
|
37
|
|
500
|
450,000
|
1,969
|
16,688,051
|
37
|
|
1000
|
900,000
|
4,200
|
35,601,176
|
40
|
|
5000
|
4,500,000
|
21,000
|
178,005,882
|
40
|
|
10000
|
9,000,000
|
42,000
|
356,011,765
|
40
|
|
20000
|
18,000,000
|
84,000
|
712,023,529
|
40
|
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.
|
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 |
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 |
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:
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:
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.
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
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.
VAX/VMS
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. (http://www.year2000.com). Some of the year 2000 concerns that must be addressed are listed below again:
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 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:
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:
5. Implementing the tested
system
When the tested system is made live, consider:
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
Dilbert
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:
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.
|
Industry
|
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 |
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
Dilbert
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.
Acknowledgements
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
References
Viasoft Inc http://www.viasoft.com
Computing Services and Software Association
http://www.cssa.co.uk
Computer Associates Limited http://www.cai.com
Federation of Electronic Industries http://www.fei.org.uk/fei
Cap Gemini http://www.hoskyns.co.uk
Confederation of British Industry http://www.cbi.org.uk./reg/cbi
Delphi Horizons 2000 http://www.chccorp.com
British Computer Society http://www.bcs.org.uk/
Year 2000 Information Centre http://www.year2000.com/
Institution of Electrical Engineers http://www.iee.org.uk/2000risk
UCISA (an association of UK universities)
http://www.ucisa.ac.uk/docs/y2k.htm
Y2K Watch -Digital Plague Oozes across
the Planet
A report by Charles E. Phillip mailto:Chasp@ms.com
and William Farrell mailto:Farrellw@ms.com
who are working in Morgan Stanley - US Investment Research Section
Appendix
8.1 Evaluation of
the tools and services of a proposed year 2000 vendor
The following checklist of key capabilities
may be of use:
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.