FREE ESSAY ON THE YEAR 2000

THE YEAR 2000

Introduction Many may dismiss the predictions that there would be a worldwide chaos on
January 1, 2000 as many computers programmed with two-digit year fields would mistake it
to be 1900 and breakdown. However, we need not wait for the turn of the century for the
trouble. Signs of early troubles are already everywhere to sufficiently warrant both IT
and business managers to take the issue seriously, if they have not already done so. What
seemed as a reasonable solution to costly storage problem in past, would now cost, by
some estimates, 600 Billion dollars to organizations worldwide. No matter what the final
cost comes out to be, even at conservative 300 billion dollars, it is no pocket change.
All concern parties must have thorough understanding of the problem, its solutions, and
possible ramifications. Importance of the Issue IT managers are not the only one who
needs to understand the depth of Y2K problem. Business managers probably has more in
stake here than any one else. If timely solutions are not achieved, many business stands
to lose many billions of dollars in form of lost revenues. This loss does not include
possible losses resulting from litigation and out-of-court settlements. Many firms,
including some large ones, have continued to drag their feet on fixing Y2K related
problems. Companies with Y2K problems now often cannot find people to work on those
problems. Shortages of qualified people to work on Y2K projects are very evident
globally. January 1st, 2000 is a non-flexible date that is sure to come without any mercy
and possibility of extension. If companies are not addressing it by now, they are simply
playing catch-up(14). The good news is that the technical know-how exists and many tools
are available. For many organizations, problem can be adequately addressed even if they
start now - but for a higher cost, of course. Historical Perspective In 1956, Howard
Aiken, a computer pioneer from Harvard University remarked: If it should ever turn out
that basic logic of a machine design for numerical solution of differential equations
coincide with the logic of a machine intended to make bills for a department store, I
would regard this as the most amazing coincidence that I have ever encountered.(1) First,
it was truly an amazing coincidence. Second, the first generation of computer programmers
were also right by recording years as two digit numbers. It saved costly storage
capacity. Third, by another amazing chance, the result of a correct decision will be an
expensive (may be the most expensive) industrial accident of our time. Many articles have
included stories that show the date problem surfacing as early as 1993: 
In 1993, associated Press reported that Mary Bandar of Minnesota was invited to attend
kindergarten classes, since she was born in 88. She was born in 1888 and was 104 years
old. 
C.G. Blodgett's auto insurance premium tripled when he was reclassified as youthful
high-risk driver. He turned 101. 
What is the Year 2000 problem? It is not one, but series of problems. It Involves
software, computer hardware, data, people, and large amounts of money. Nature of these
problems can be explained simply: until 1989, all of the standards followed to create
computer programs stated that only last two digits would be used to identify the year. As
the millennium nears, most computers would regard 2000 as 1900. In late 1800s, Mr.
Hollerith invented the punch card with 80 columns to help the U.S. Census done on time.
Same cards has been in use for programming until recent time. Eighty characters of
information was barely enough for a full name and address. To save space for more
important information, programmers designated two-digit year field assuming all years
would have same prefix of 19. Even when computers were later equipped with larger storage
capacities in magnetic form, memory was the most expensive part of the machine and
programmers continued to use two-digit year field to save memory. How the problem
continued Programmers of 1960s and 1970s assumed that these program would long be
replaced with new ones before the turn of the century. Though the computer hardware has
come a long ways in past 30 years, the mainframe machine is still with us - only faster
and able to run old programs cheaply. Many of these programs were written for a specific
company to do a specific job and over the years more features have been added but little
has changed at the core level, including two-digit dates. Scope of the problem Solving
the problem, looking from the top, is as simple as telling the computer to change all
existing dates to four digits and only to accept four-digits dates from now on. But few
dates are easy to find in 'date = MM/DD/YY format'. Many programmers used conventions
such as john - mary = sue to calculate differences between two dates -- making it harder
to find the date code if one is not familiar with the convention (3). But that is only
the part of the problem. Over the years large amounts of data has been stored on disks
and tapes and there are lots of duplicate data. In most part these data are stored in
large files in a date sequence of collection. Many programs that handles these physical
resources cannot handle four-digit year. Business applications that depends on these
systems to figure out person's age, length of unpaid invoices, interest due on bank
deposits and so on are in for plenty of trouble. (14). Furthermore, many businesses have
used date stamping -- a method that use embedded dates in the records. Date stamps are
automatically placed on the record by the system in many transaction tracing systems.
Brian Hayes in January/February 1995 American Scientist used the following examples to
describe the date stamping problem: 
At the local dairy, the oldest milk on hand is supposed to be shipped first, but in the
early weeks of the new millennium milk from year 00 is given precedence. Indeed, any milk
remaining from December 1999 will not be scheduled until the end of 2099. Meanwhile, at
the bakery across town a computer calculates the bread dated 01-01-00 must be a century
old, and sends it to the landfill. 
Where Are We Now? 
If the companies and governments were to do nothing about the problem, unthinkable crisis
would certainly follow. However, for a change, we have the media to thank for. Numerous
reports, stories, and articles presented to people is likely to save us from such a
disastrous possibility. No one can now say that they were not warned. 
Problem hits early 
The problems associated with the millennium bug have already started to prop up and many
are expected to strike harder well before January 1, 1999. A report published by Cutter
Consortium outlines some Significant Milestones Prior to 2000 (2): 
Jan 1, 1999: reservation systems that accept booking one year ahead and business planning
systems projecting forward one year. 
April 1, 1999: NY State and some companies 2000 fiscal year begins, affecting all fiscal
systems 
July 1, 1999: 44 more states and other companies begin their fiscal years. 
Sept. 9, 1999: Programmers use 9999 as an end of file indicator, so date may confuse
system. 
Oct. 1, 1999: federal government and many other companies begin fiscal year 2000. 
Management reactions 
Unfortunately, all companies are not reacting accordingly. While many addressed the
problem in somewhat timely manner, others are dragging their feet. Many are taking wrong
positions. As stated by William McDonough, President of Federal Reserve Bank of New York,
they are(3): 
Denial. The year 2000 is not an issue for our organization. 
No resource problems. Our organization can handle the year 2000 with its existing
resources and within current budgets. 
Vendors will address the issue. Our outside vendors and service providers won't let us
down. 
Covered by contract. Our lawyers have determined that we are appropriately protected by
our legal agreements. 
On the other hand, Some companies decided to be silent. Management of these companies are
fearful of shareholder suites claiming negligence. Many fears that acknowledgement of a
serious Y2K problem within a business unit or across an enterprise may cause clients to
flee and competitors to flock. The legal ramifications remain unclear for consulting
services companies that have provided hardware and software solutions that did not
include Year 2000 fixes in the recent past. Others are awaiting the leadership of
regulatory agencies and/or financial accounting standard bodies within the federal
government for this unique event(3). 
News for late starters 
A new survey conducted by International Data corp., of Farmingham, Mass., found that
small companies are more likely than the larger firms to neglect the year 2000
projects(10). Out of the 400 firms surveyed, 23% percent had not started the conversion
project. A vast majority of these firms (88%) has annual revenue of $25 million or less.
In the same survey CIOs and CFOs were asked to rate their concerns about year 2000
conversion. They rated impact on customers first, followed by their competitive position
against other companies. Impact on the business partners was rated third, and financial
impact was rated fourth. 
If companies are not addressing the problem right now, they may be in for a lot of
trouble. Only viable solutions are to retire and replace, or to repair the system.
Ignoring the problem is not an alternative. 
They need to take an inventory of the software on a system and identify where Y2K will
effect it and prioritize the order in which to fix problems. Organizations that did not
contract for Year 2000 services by 1997 can expect to pay up to 100% premium to obtain
services from leading service providers. 
Staffing and outsourcing 
Only 21 months to go, staffing the Year 2000 team could be a cause of major anxiety for
companies. According to Casper Jones, a noted year 2000 consultant, 1996 was the last
year in which a midsize corporation with a software portfolio of a half-million function
point could have finished work on time without extraordinary staffing measures. Those
include halting all but emergency and required work, assigning up to 85% of staff,
running round-the-clock efforts and partnering with consortia or industry groups.(6) 
Surveys show the growing staffing shortage and it will only continue to get worse. The
real shortage will come when federal government will get serious about year 2000 fixes.
Organizations with head start and adequate staff are not all that secure - they could be
the target of companies seeking ready-made expertise. The cost to repair codes stands at
$1.50 per line currently. Some expects it to at least double over the next few months. 
Experts say, there is still hope for late starters. If they act quickly. Late starters
still benefit from others' denial of the problems(6). Outsourcing still remains a option
for some. Some large and many small consulting firms are still seeking new businesses.
Off-shore providers can also provide some relief. More companies are also getting back to
their retirees for help. The retirees may have not only the necessary experience, but
they also may know the system better than the outsiders. What's in the Future? 
Companies that have their project 2000 well under control as well those who are starting
out -- both needs some future planning. If nothing else, they should review the legal
issues involving their business and have a well drawn contingency plan in place. 
Buying a liability insurance, just as other business insurance, may not be an option --
companies cannot insure out of this one. While some insurance coverage is available, the
cost of coverage and loopholes in policies make it prohibitive. Companies spending money
on insurance will never get return on their investment. Policies are likely to provide
false security and companies are better of putting their money and effort to solving
problems at hand (15). 
Legal issues 
Legal issues arising from year 2000 problem alone can put many organizations out of
business. By the turn of the century, business managers and IT vendors will be seeing lot
of year 2000 related lawsuits. Many has wrongfully believed the problem to be a primarily
a technical issue. But lot of companies will fail to conduct business even before the
deadline hits home. 
Produce Place International Inc. of Warren, Michigan recently had its newly installed
Unix Point-of-Sales system come to crashing halt when a customer tried to use a credit
card with 00 expiration date. All the register froze. Though the business could accept
cash or checks, lots of people walked out in frustration due to backed up line at the
registers. After many support calls to the vendor, the store has sued the manufacturer of
all American Cash Register Inc. for breach of warranty and breach of duty of good faith,
etc.(8). 
Vendors are not going to face the lawsuits alone -- IT managers who fail to meet the Y2K
compliance and would cause contamination in customers' and partners' systems may also
find themselves defending in court of law. Some experts asks IT managers to take it as a
legal issue as well and to document their Y2K repair efforts. 
There are other lawsuits pending in the Superior Court of the State of California. It is
likely that all these early cases will be settled out of court to avoid public attention.
Some companies are taking actions now. The big three auto manufacturers has joined
together to write to the suppliers to fix the problem or face litigation in future (8). 
The vendors are likely to use the theory that the risk was unforeseeable or there was a
disclaimer of warranty explicit or implied in the transaction. Another issue would be of
the statute of limitations. Generally warranties does not last as long as acceptance and
delivery of the goods. Many are discussing of alternatives to all possible litigation and
product liabilities. But, prudent business managers should not count on it to defend
themselves(11). 
Many experts say that disclosure is the best defense against Y2K litigation - the board
of directors and shareholders need to know. SEC advised companies to disclose internal
Y2K issues, relationships with customers and suppliers, a timetable for carrying out the
plans, and a total dollar amount the customer estimates will be spent on Y2K issues.(8) 
Some government agencies are trying to pass laws that may protect them. However, that is
not a choice for companies. In California, a bill has been proposed that, if passed, will
limit awards for year 2000 lawsuits to 'reasonably incurred costs regarding relevant
computers and software' and may weaken businesses' ability to recover actual damages (9).

A case for contingency planning 
When an information system group at the state of Washington performed a routine test of
its disaster recovery plan two years ago, it also decided to take a look at its year 2000
problem. But when they set the mainframe's system date forward to 2000, it caused the
entire test to crash. The computer informed that testers' passwords has expired (4). 
The moral of the story is that the companies not only need contingency plans, it also
needs to test those plans thoroughly. But it remains an idea that many companies do not
adopt. Preparing for the Year 2000, contingency planning is not only a good idea, but one
that should not be ignored. Study shows that companies that need contingency plans are
least likely to have them. 
Washington's Department Social and health Services is field testing a commercial accounts
payable package that can be turned on quickly if needed. One would suppose that it is
their solutions to Year 2000 problem. In the contrary, the department is far along in
remediation of their 12 year old mission critical system. The Prudential Insurance
Company of America has a broad contingency plan that covers application software,
internal infrastructure, and external partners. Each of these area has a plan for not
meeting January 1 deadline, if it fails after January 1, and if a problem is not
discovered until later. Similarly, Geico Corp. of Maryland plans to include manual
backups for some mission critical automated processes by keeping paper copies of data
that would allow cross-checking of data if disputes arises from online transactions (4).

Not only companies need Year 2000 contingency plans, but also needs to test those plans.
Even if remediation programs are going well, companies should have contingency plans. No
matter how much care is taken, some systems will break unexpectedly, as Murphy's law
predicts. 
Take BankBoston for example. It operates in 24 countries and exchanges information
electronically with about 500 institutions. There is always the potential that its own
system would be corrupted if these partners have not prepared adequately. Furthermore,
BankBoston lends money to other businesses that must also be Year 2000 complaint. 
One cannot assume suppliers and partners won't have Year 2000 problems that will impact
the business(5). Build year 2000 contingency plans on top of existing disaster recovery
plans. Like all disaster recovery plans, the Year 2000 plans should be tested under as
realistic conditions as possible. 
Companies looking to establish a contingency plan should(4): 
Cover application software, internal infrastructure and external partners. Most companies
are focussing on application software. But the other infrastructure problems can be as
big a problem - how does get into premises if lock would not open or places phone calls
when the system is out? 
External partners should not be ignored at this age EDI. The whole system will fall as
easily if EDI partners are not Year 2000 compliant when you are. 
Formally document the plan, widely distribute and test the plans. Everyone in the
organization needs to know what the contingency plan is. 
3. Contingency planning should include legal considerations as well. Prepare for damage
claims from customers, partners and shareholders. Shareholder lawsuits will be encouraged
if management does not adequately disclose Year 2000 problems. And Document Y2K
remediation efforts well. 
A case for testing 
With passing of time and as the January 1, 2000 nears, testing phase of the Y2K fixes are
most likely to be the one to be ignored. The payoff of testing is great and once
completed, one can rest easy that all are well. It is not the most fun part of the
project by any means but a very important one -- a fix is no good if it does not work. 
Securities Industry Association is planning for four testing before the final date gets
here. Starting March 6, 1999 it will test all members system on four consecutive
Saturdays. The first test will mimic Dec 29, 1999, followed in order by Dec. 30, 31, and
Jan. 3, 2000(13). 
According to a Eric Hammond, a technology Analyst, thoroughly testing a year 2000 fix
requires that one runs it through three tests: functionality testing, year 2000 testing,
and system testing. Mission critical systems should be tested first(12). 
In the functional testing one makes sure that altered codes work with current date. In
the year 2000 testing, an aging data of current data should be tested. In system testing
phase all system components are brought together to insure their compliance. System
testing is the most time consuming of all the three and generally left behind when time
is short(12). 
Conclusions 
Management needs to fully understand the depth of the Y2K problem in their organization.
Simple return on investment and cost-benefit analysis may not be adequate without
considering other repercussions that may result due to failure to comply. For many
organizations, it may be as simple as either fix the problem while it can or else be out
of business. Organizations that are on top of everything will still need contingency
planning. As Murphy's law state: If something can go wrong, it will. 
It may be appropriate to conclude by listing Don't Forget the Basics, 10 Y2K reminders
from Greenwich Mean Time, a Y2K software company in Arlington, VA(7): 
Don't panic. While 2000 is an unavoidable deadline, the problem is finite. 
Be aware of your liability. Business executives who brush off Y2K compliance may be
considered negligent and face huge lawsuits when system fail. 
Develop an action plan. If you don't have one, business partners auditors, bankers and
insurers will begin to worry. 
Remember the domino effect. Even if your company is Y2K compliant, it is at risk if its
customers and suppliers have not addressed the issue in their own systems. 
Don't look for a silver bullet. While tools exist to speed up the repair work, none will
automatically solve the problem. 
Don't underestimate the scope of the problem. It affects all companies, regardless of
size, an impacts all systems, including PCs. 
Focus on business survival, not IT survival. Create backup plan, even if it is as simple
as making printed copies of every document you use. 
Start now. Otherwise bonuses, profits and share price will be jeopardized by the delay. 
Don't rely on anyone else to solve the problem - they have their hands full with their
own year 2000 problems. 
Don't bet your business on promises. Make suppliers guarantee compliance of their systems
in writing. 
Bibliography 
The Millennium-bug Muddle, The Economist, October 4, 1997, p.17. 
Radosevich, L. Millennium bug already taking its toll, Infoworld, January 12, 1998, p. 1
& p. 19. 
Please panic early: it may not be the end of world as we know it, but the year-2000 bug
is already a very expensive nuisance.(Cover Story), The Economist, Oct 4, 1997, p. 25. 
Anthes, G. Contingency planning when disaster strikes, Computerworld, January 19, 1998,
p. 80. 
Beware the Millennium, The Economist, March 8, 1997p. 86. 
Maglitta, J. Fair Warning, Computerworld, January 19, 1998, p. 94. 
Don't forget the basics, PC Week, March 2, 1998, p. 87. 
Neil, S. 2000 reasons to sue: CIOs are standing up for their rights on Y2K problems, but
they may face liability themselves, PC Week, March 8, 1998, p. 83. 
Benson, M. 2000 bug: group seeks damages cap, The Wall Street Journal, December 10, 1997,
p. CA1. 
Madden, J. Smaller Companies Run Big Y2K Risks, PC Week, March 8, 1998, p. 88. 
Zirin, J. Bugs bite, and lawyers litigate, Forbes, July 7, 1997, p. 100. 
Hammond, E. Year-2000 testing issues: Cure for the uncommon test, Infoworld, December 29,
1997, p. 58. 
DiDio, L. Wall Street to test y2K readiness, Computerworld, February 9, 1998, p. 1. 
Jagger, D. and Bergeon, R., Managing 00: Surviving the Year 2000, Wiley Computer
Publishing, 1997. 
Neil, S. Y2K: You Can't Insure Your Way Out of This One, PC Week, March 8, 1998, p. 84.