The Year 2000 18512 Essay Example

machine for solving differential equations coincided with the logic of a machine designed for processing transactions in a department store, it would be an exceptional coincidence. Truly, it was an impressive coincidence.

The initial cohort of computer programmers made the wise choice to use two-digit numbers for years, which helped save storage capacity. Surprisingly, this decision would eventually lead to a highly expensive industrial accident in modern history. Numerous articles have documented incidents where the date issue first emerged as early as 1993. For example, an Associated Press article from that year tells the story of Mary Bandar from Minnesota, who was mistakenly enrolled in kindergarten because her birth year was recorded as '88'. In reality, she was born in 1888 and was actually 104 years old at that time.

Blodgett saw his auto insurance premium tripled after he was reclassified as a high-risk driver due to his youthful age of 101. As for the Year 2000 problem, it is not merely a single issue but rather a set of problems involving software, computer hardware, data, people, and substantial financial implications.

The reason for these problems is as follows: before 1989, computer programs used a standard wherein only the last two digits were used to represent the year. As the year 2000 approached, most computers would mistake it for the year 1900. In the late 1800s, Mr. Hollerith devised an 80-column punch card to aid the United States.

The census was completed on schedule, using the same cards for programming as in the past. The limited capacity of eighty characters per card made it difficult to include a person's full name and address. In order to prioritize important data,

programmers decided to allocate a two-digit field for the year, assuming that all years would share the 19 prefix.

Despite the advancement of technology and the availability of larger storage capacities, memory remained the most expensive component of early computers. Consequently, programmers opted to use two-digit year fields in order to save memory. Furthermore, programmers in the 1960s and 1970s expected these programs to be replaced before the turn of the century. However, the mainframe machine, though faster and capable of running old programs inexpensively, persists today. Many of these programs were initially designed for specific companies and tasks, and while additional features have been added over time, the fundamental structure—including two-digit dates—has remained largely unchanged. As for addressing this issue, from a high-level perspective, it would be as simple as instructing the computer to convert existing dates to four digits and only accepting four-digit dates going forward.

Locating dates in the 'date = MM/DD/YY format' is not a simple task. Some programmers have chosen alternative approaches, such as utilizing "john - mary = sue," to calculate the difference between two dates. This complicates the search for date codes for those who are unfamiliar with this convention (3). However, this is just one facet of the issue. Over time, large amounts of data have been stored on disks and tapes, leading to numerous occurrences of duplicated data.

Most of the data is stored in large files organized by date. However, many programs that handle these files cannot process four-digit years. This creates challenges for business applications that use these systems to calculate age, unpaid invoice duration, interest on bank deposits, and similar information. Furthermore, many businesses use date

stamping techniques that involve embedding dates within records.

Date stamps are automatically placed on the record by the system in many transaction tracing systems. According to Brian Hayes in the January/February 1995 edition of American Scientist, he provided examples to illustrate the issue with date stamping. For instance, at a local dairy, the oldest milk is supposed to be shipped first. However, during the early weeks of the new millennium, milk from the year 2000 is prioritized instead. In fact, any remaining milk from December 1999 will not be scheduled until the end of 2099. In another example, at a bakery across town, a computer determines that bread dated 01-01-00 must be a hundred years old and disposes of it in a landfill.

Where Are We Now?

If no action is taken by companies and governments, an unimaginable crisis is bound to occur.

However, the media has played a crucial role in raising awareness about the millennium bug and its potential disastrous consequences. Through numerous reports, stories, and articles, they have informed us about the issue. Therefore, no one can claim ignorance.

Problem Hits Early

The issues related to the millennium bug have already begun to surface and are expected to worsen before January 1, 1999. A report from Cutter Consortium highlights several important milestones prior to 2000 (2):

• Jan 1, 1999: reservation systems that accept bookings one year in advance and business planning systems projecting one year ahead.
• April 1, 1999: NY State and certain companies begin their fiscal year 2000, impacting all fiscal systems.
• July 1, 1999: an additional 44 states and other companies start their fiscal years.
• Sept. 9, 1999: Programmers use "9999" as an end of file indicator
  

which may cause confusion with the system's date.

Management Reactions

Unfortunately not all companies are responding appropriately. While some have taken steps to address the problem promptly and adequately others are delaying or adopting incorrect stances.

According to William McDonough, the President of Federal Reserve Bank of New York, their organization has three beliefs about the year 2000 issue: denial that it is not a problem for them, confidence in handling it using existing resources and budgets, and trust in vendors to address the problem. They also rely on their legal agreements for protection. However, some companies have chosen to remain silent due to concerns about shareholder lawsuits and potential client loss. These companies are also uncertain about the legal consequences faced by consulting services firms that provided solutions without Year 2000 fixes in the past.

Some smaller companies are waiting for guidance from regulatory agencies and financial accounting organizations within the federal government for the unique event (3).
News for those who are starting late
A recent survey conducted by International Data Corp., of Farmingham, Mass., discovered that smaller companies are more likely to overlook year 2000 projects (10). Out of the 400 firms surveyed, 23% had not yet initiated the conversion project. The majority of these firms (88%) have annual revenue of $25 million or less. The same survey asked CIOs and CFOs to rate their concerns regarding year 2000 conversion.

They prioritized the impact on customers as their primary consideration, followed by their competitive position compared to other companies. The impact on business partners was ranked third, and the financial impact was ranked fourth. Companies that

are not currently addressing the problem may face significant trouble. The only workable solutions are to retire and replace or to repair the system. Ignoring the problem is not a viable alternative.

They need to take an inventory of the software on a system and identify where Y2K will affect 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

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 true shortage will happen when the federal government takes substantial action to address the year 2000 problem. Merely having a head start and enough staff is not adequate for organizations, as they can be targeted by companies seeking pre-existing expertise. At present, the cost of fixing codes is $1.50 per line, but it may increase in the future. Experts advise that there is still hope for those who are starting late, but they must act quickly.

Late starters can benefit from the denial of problems by others(6), as outsourcing is still an option for some. Both large and small consulting firms continue to seek new business,

and off-shore providers can offer relief. Additionally, more companies are turning to their retirees for assistance, who not only possess the necessary experience but may also have a better understanding of the system than outsiders.

Companies, whether they are well-established or just starting out, should engage in future planning. One crucial aspect of this planning is examining the legal issues relevant to their business and devising a contingency plan. While some companies may consider purchasing liability insurance or other business insurance, this may not be possible as they cannot avoid these issues through insurance alone. Even if some insurance coverage is available, the expenses associated with it and the limitations in policies make it impractical. Therefore, companies that invest in insurance will not receive a beneficial return on their investment.

Policies provide a sense of false security, and it is more effective for companies to invest their resources in solving current issues (15).

Legal Issues

The year 2000 problem can lead to legal complications that have the potential to bankrupt numerous organizations. As we approach the new millennium, business managers and IT vendors can anticipate an influx of lawsuits related to the year 2000 issue. There has been a misguided belief that this problem is primarily a technical matter. However, many companies will struggle to continue operations even before the deadline arrives. One such example is Produce Place International Inc.

The newly installed Unix Point-of-Sales system at a store in Warren, Michigan experienced a major issue when a customer tried to use a credit card with an "00" expiration date. As a result, all the registers froze, causing frustration for customers who had to wait in

long lines. Despite the store's ability to accept cash or checks, many people left without making a purchase. To resolve the problem, the store made numerous support calls to the vendor but ultimately decided to file a lawsuit against American Cash Register Inc., the manufacturer, for various breaches including breach of warranty and breach of duty of good faith (8).

Failure to meet Y2K compliance could result in lawsuits for vendors and IT managers, posing a risk of contaminating customers' and partners' systems. Legal experts recommend that IT managers document their efforts to address Y2K issues and acknowledge the legal consequences. Currently, there are ongoing lawsuits in the Superior Court of the State of California, although it is likely that these cases will be settled outside of court to avoid public scrutiny. Some companies have already begun implementing proactive measures.

The major auto companies have united to send a letter to their suppliers, urging them to address the issue or face potential legal action in the future (8). The suppliers may argue that the risk was unexpected or that there was a clear or implied disclaimer of warranty during the transaction. Another concern is the statute of limitations, as warranties typically expire before the acceptance and delivery of goods. Many are considering alternative solutions to minimize litigation and product liability.

Prudent business managers should not rely on it as a defense against Y2K litigation. Experts recommend disclosure as the best defense - the board of directors and shareholders should be aware. The SEC has advised companies to disclose internal Y2K issues, relationships with customers and suppliers, a timetable for executing plans, and the total amount estimated to be

spent on Y2K issues. While some government agencies are attempting to pass protective laws, companies do not have that option. In California, a proposed bill may restrict awards for year 2000 lawsuits to "reasonably incurred costs regarding relevant computers and software," potentially weakening businesses' ability to recover actual damages.

The Importance of Contingency Planning

When the information system group in Washington state performed a standard disaster recovery plan test, they also decided to examine their year 2000 issue. However, setting the system date forward to 2000 caused the entire test to crash on the mainframe. The computer indicated that the testers' passwords had expired (4). This incident highlights the need for not only developing contingency plans but also thoroughly testing them. Unfortunately, many companies do not embrace this concept.

Contingency planning for the Year 2000 is crucial and should not be overlooked. Research indicates that companies that require contingency plans are the least likely to have them. The Department of Social and Health Services in Washington is currently testing a commercial accounts payable package that can be activated quickly if necessary. This is presumably their solution to the Year 2000 problem. However, the department is already well-progressed in fixing their 12-year-old mission critical system. The Prudential Insurance Company of America has an extensive contingency plan that includes application software, internal infrastructure, and external partners.

Both these area and Geico Corp. of Maryland have plans for various scenarios, including not meeting the January 1 deadline, failure after January 1, and problems discovered later. Geico Corp. of Maryland specifically plans to have manual backups for certain automated processes by keeping paper copies of data for cross-checking

in case of disputes arising from online transactions (4). It is essential for companies to have Year 2000 contingency plans and to also test them.

Regardless of the success of remediation programs, it is important for companies to have contingency plans due to the unpredictable nature of systems. Murphy's law suggests that even with careful precautions, some systems will unexpectedly fail. BankBoston serves as a prime example of this situation. With operations in 24 countries and electronic information exchange with approximately 500 institutions, there is always a risk that BankBoston's system could be compromised if its partners have not adequately prepared.

Furthermore, BankBoston also provides loans to other businesses that must also comply with Year 2000 regulations. It should not be assumed that suppliers and partners will not experience Year 2000 issues that could affect the business(5). In addition to existing disaster recovery plans, contingency plans specifically for Year 2000 should be developed. Like all disaster recovery plans, the Year 2000 plans must be tested under realistic conditions.

Companies should have a contingency plan in place that covers application software, internal infrastructure, and external partners. While many companies tend to prioritize application software, other infrastructure issues can potentially be equally problematic. For instance, what happens if the lock on the premises won't open or if the system is down and someone needs to make phone calls? Additionally, it is essential not to overlook external partners, especially in the context of EDI in today's age. If EDI partners are not Year 2000 compliant, the entire system could easily collapse.

It is essential to formally document the plan, distribute it widely, and conduct tests. All members of the organization should be

aware of the contingency plan. Legal aspects should be taken into consideration in contingency planning. It is important to be prepared for claims for damages from customers, partners, and shareholders. Insufficient disclosure of Year 2000 problems may lead to lawsuits from shareholders.

And Document Y2K remediation efforts well.

A Case For Testing

As the January 1, 2000 approaches, it is highly likely that the testing phase of the Y2K fixes will be ignored. However, testing is crucial as it ensures that the fixes are effective. The Securities Industry Association has planned for four testing sessions before the final date arrives.

Starting on March 6, 1999, the system will undergo testing for all members on four consecutive Saturdays. The initial test will simulate December 29, 1999, and it will be followed by tests simulating December 30, December 31, and January 3, 2000(13). Eric Hammond, a technology analyst, suggests that a comprehensive year 2000 fix should be tested in three phases: functionality testing, year 2000 testing, and system testing. It is recommended to prioritize testing for mission critical systems(12).

During functional testing, the aim is to ensure that modified codes function correctly with the current date. Year 2000 testing involves testing the functionality of the system with an aging data of the current date. In the system testing phase, all components of the system are tested together to ensure their compliance. This phase is often the most time-consuming of the three and is sometimes neglected due to time constraints(12).

Conclusions

Management must have a thorough understanding of the extent of the Y2K problem within their organization. Simply relying on return on investment

and cost-benefit analysis may not be sufficient when considering potential consequences resulting from failure to comply.

It is crucial for organizations to address problems promptly or risk going out of business. Even organizations that are proactive in their management still need contingency plans for potential issues. This is in accordance with Murphy's law, which states that if something can go wrong, it will. Listed below are 10 Y2K reminders from Greenwich Mean Time, a Y2K software company in Arlington, VA:

- Don't panic; the Y2K problem has a definite end date.
- Be aware of the legal implications; neglecting Y2K compliance may result in negligence claims and lawsuits if systems fail.
- Develop an action plan to ease concerns from business partners, auditors, bankers, and insurers.
- Consider the domino effect; even if your company is prepared, risks persist if customers and suppliers have not addressed the issue in their own systems.
- Realize that there are no easy solutions; while there are tools to expedite repairs, no single fix will automatically solve the problem.
- Do not underestimate the magnitude of the problem; it affects all companies and all systems, including PCs.
- Concentrate on business survival rather than just IT survival; establish backup plans such as making physical copies of essential documents.
- Start taking action immediately; delays can jeopardize bonuses, profits, and share prices.

• 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

1. "The Millennium-bug Muddle", The Economist, October 4, 1997, p.17.
2. Radosevich, L. "Millennium bug already taking its toll,"
   

Infoworld, January 12, 1998, p.1 ;p.19.

80.

"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.

"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.

84.