Year 2k Bug Essay Example

will seem like an ENTIRE century, FUTURE events will have
-- Duncan G. Connall; Global Software, Inc.

The problem at hand is vast in scope. The knowledge and data on this issue is expanding quickly, evident by the increasing amount of information found on the Internet. Searching for "year AND 2000 AND problem" on the Altavista index resulted in over 60,000 pages. However, this amount of information is still not enough to fully grasp the size of the problem.

Without running software patches, early IBM-PC machines and compatibles will become useless for date applications. This is because the system clocks on the hardware level cannot handle the four-letter date format.

The problem described is not only limited to personal computers and mainframes, but also applies to various electronic devices that use dates. This includes micro controllers found in car ignition control systems, clocks, microwaves, and even nuclear weapons. The issue stems from both the microprocessor used in the device and the compiler or linker that generates the code. When software encounters unexpected input, it can lead to a range of outcomes, from error messages to program crashes. These effects can have tangible consequences such as a computer failing to boot or a car not starting. The 2000-year field has already caused problems with certain PC programs, as they may default to 00 or 1900 when this input is entered. This poses a significant risk for home database and spreadsheet software, which may become obsolete unless patches are released. While some companies opt for complete software upgrades, this is far from an ideal solution for home users.

Various experts suggest that conducting an impact analysis of systems typically takes

about 6 months. This is followed by a period of pilot projects lasting between three to six months. The production phase can then span a couple of years, contingent upon the size of the business and availability of resources. Over time, these resources are expected to become increasingly scarce, whether they are in-house or external services.

In January 1996, Bruce Hall, an IT expert quoted in Datamation Magazine, advised individuals to secure their services by the second half of 1996. CACI Incorporated's "The Millennium Mess" provides estimated man hour replacement costs for a large corporation: approximately 1,200,000 lines of code and an estimated 2,000 man hours for manufacturing systems; and approximately 8,8000 lines of code and an estimated 116,300 man hours for COTS software providers.

It is important to note that some machines have already encountered issues due to the millennium bug. For instance, Unisys 2000 failed on January 1st, 1996 because it used a signed integer for the year field's eighth bit representation. Furthermore, credit card systems encounter problems with cards marked as invalid if they have a year listed as "00".Insurance companies face challenges when trying to sell annuities with a duration of five years because their systems have limitations regarding dates. Additionally, there has been a neglect in addressing hardware system problems associated with the year 2000 issue, and there are limited resources for evaluating the susceptibility of individual systems at a hardware level.

One crucial aspect of the year 2000 problem is persuading IT managers to take proactive measures. Despite the belief in a miraculous solution, all evidence points to the contrary. Moreover, the scarcity of skilled professionals exacerbates the issue. Analysts estimate that

most medium to large companies should have allocated resources by late 1996; however, regrettably, many companies remain inactive.

Staying in business is difficult to justify when it involves spending a large sum of money. IBM estimates that they will have to make changes to over 50 million lines of code, costing approximately $20 million. The main objective is to ensure that the software operates identically on January 1st, 2000 as it did on December 31st, 1999.

The media is worsening the situation by downplaying the potential disaster of the year 2000 problem. Despite widespread awareness, there has been minimal attention given to this issue, with only a few interesting "horror stories" being reported. These stories mostly focus on inconveniences rather than highlighting the serious consequences. The problem seems simple because it's just about the date difference between 99 and 2000. There hasn't been any news coverage of successful businesses going bankrupt due to lack of planning and preparation, which would compel managers to allocate necessary resources for effective problem-solving. Unfortunately, such stories won't be enough for most individuals.

Moreover, the extensive networking and interdependency among large computer systems further exacerbate these problems. Even external systems can cause significant losses if they are not updated properly. For example, if your widgets require titanium lugnuts but the lugnut supplier believes it's still 1900, you won't receive any lugnuts and will consequently be unable to produce widgets. Banking systems are particularly vulnerable as they consist of numerous interconnected nodes. Just think about how many Interact/Credit Card/Automated Teller systems currently exist! If one system malfunctions, it can disrupt the entire network causing widespread issues.

These issues can include problems with money not being

correctly added or deducted from accounts, difficulties with interest and financial forecast scenarios, or even a complete network crash. Additionally, it should be noted that 2000 is a leap year and certain programs (such as Lotus and Lotus-Compatible worksheets) may not recognize February 29th, 2000. (Source: Datamation Magazine, January)

The problem at hand has an important aspect that requires attention. Providing a definite answer to the question "what will happen to my program?" is impossible, as it varies depending on various factors. Some operating systems, like MS-Windows 3.1 (1990) and MS-DOS machines (1980), may revert back to their creation date. Certain programs might interpret the year as 2000 or function inconsistently, generating random data, while others could crash completely.

Moreover, there are client-server based applications where the server can potentially be modified to accommodate a larger year field. However, the client programs, often pre-built and unsupported, cannot be altered. This issue is subjective and ambiguous in nature.

As aptly stated by Peter de Jager, a Year 2000 Consultant quoted in Datamation magazine: "For once in our lives, it doesn't matter the size of the project, how many resources or how much money you have - the deadline."

Alongside this problem lies multiple concerns regarding software, insurance coverage, and potential liability for program failures of such magnitude. A frequently asked question posed to information technology managers regarding the year 2000 situation revolves around determining who should bear responsibility.

Despite limited information on new developments in addressing the millennium bug field , external contractors who supplied software could potentially face expensive lawsuits due to inevitable product failures.The insurance industry has analyzed the matter and concluded that unless software malfunctions, like the millennium

bug, are explicitly classified as unforeseen or unpreventable flaws, companies will typically not receive reimbursement. Nonetheless, programmers who possess consulting insurance policies pertaining to "professional oversight or neglect" may have the option to file a claim in case of a lawsuit. Companies impacted by the millennium bug are expected to explore other options for transferring financial liability onto others so as to prevent major disruptions to their operations.

Assigning blame and negligence in this matter will be part of a corporation's solution matrix, especially if their software development contracts clearly specify this. Other personnel who may be held liable for failure to act could face termination or disciplinary actions. This is also likely to occur when upper management is forced to address a significant failure or shutdown caused by a failure to act on the estimated cost to correct the Year 2000 problem worldwide, which is projected to range from $300 billion to $600 billion according to the Gartner Group, Inc., an information technology research firm (Legal Issues Surrounding the 2000 Bug, by Jeff Jinnet). The U.S. Department of Defense, for instance, plans to solve the problem by adopting ISO 8601 Standard Date Formats as the key solution (Possible Solutions to the 2000 Problem). Writing software to these standards is the true solution for preventing such issues. The computer industry offers multiple standards to choose from, but in this case, it is important to adhere to the format set forth by the International Standards Organization for electronic computing devices' date and time formatting. Making software compliant with this international standard is the objective.If the programmers had followed accepted standards and been aware of them, then this

dilemma would not exist. Unfortunately, the difficult part is getting the software in line with these standards from the start.

The ISO 8601 standard is crucial for consistent date information interchange between systems, as some systems provide incomplete date information. To solve this issue, the standard offers a complete date format solution. Implementing this solution involves defining a date class and using a date object to represent chronological information, such as the Java.util.date class in Sun Microsystems JDK 1.0 package. This approach allows dynamic sharing of relevant information between systems in a platform-independent manner.

In larger corporations, there is often more value in the data itself rather than the program. This presents an opportunity to develop enterprise-wide replacements for flawed applications, addressing two major problems simultaneously. Upgrading software not only increases productivity but also encourages independent startups to offer innovative solutions that IT managers are willing to invest in, especially as the millennium approaches its end. However, developing these programs on a large scale incurs significant costs in terms of research and development.However, the importance of these programs cannot be underestimated in small Point-of-Sale terminals and embedded firmware applications. The complexity and long development time of these programs contribute to high expenses. Implementing these programs can be costly unless done on a large scale, which is possible for corporations with large IT departments. By re-engineering current source code, corporations can create applications that support the 2000 format while incorporating new features and improving hardware compatibility. This approach has its advantages and disadvantages as it relies on existing source code and requires in-house expertise and access to compilers. Conversion tools are now available for various mainframe languages like

COBOL and Assembler. However, significant code manipulation is still necessary to ensure proper functionality of the product.

While these programs can handle retrieving the date from the operating system, they are unable to handle instances where the date is a crucial component of a numerical algorithm. Consequently, this issue still necessitates manual code analysis and frequently demands less external aid and support. Consequently, this results in a more cost-effective resolution for businesses. However, this approach requires meticulous advanced planning and is often not feasible for ventures that have not yet commenced their 2000 conversions.

Some hardware systems are experiencing issues with their date functionality, specifically after the year 2000. IBM has released patches for its S390 processor machines running VMS 5.1 or later. Intel-based personal computers without BIOS support for the 2000 format will face a problem where a DATE command must be manually entered upon machine startup. This is not practical for applications reliant on accurate dates, as there is a risk of operators forgetting to enter the date. The software patches are a temporary solution and will ultimately require a firmware upgrade for the hardware. After 2000, the demand for BIOS chips with proper functionality is expected to grow rapidly due to the large number of these machines in use. All IBM PCs manufactured before 1996 will encounter this date issue, but IBM assures that all machines shipped after 1996 will function correctly beyond 2000, although still not an ideal solution.

(Jan 1996 Datamation article by Joe Celko) The solution for most companies to solve the 2000 Problem will involve a combination of strategies. The implementation, whether it be in-house, contracted, or a mix of both,

will determine how these strategies are carried out. IT managers responsible for creating a transition strategy for their company to smoothly move past the year 2000 face the primary challenge of identifying the problem at hand.

They must determine how much software will be affected and what consequences may arise if no action is taken. Additionally, they need to assess whether the centralized database software can handle the necessary changes and consider the impact on client applications. Answering these questions is crucial before making an assessment based on a reasonable estimate of the problem's scope.

The question at hand is whether it is more cost-effective to repair or replace the system. Several factors must be considered in this situation. For a mainframe computer, you need to determine if the source code is still available and if there is a supported compiler without Y2K issues. If these conditions are met, you then need to assess if you have personnel who can internally modify the code. If not, it is crucial to determine if there are qualified individuals available for this task.

Analyzing the expenses and benefits associated with repairing the existing system may lead to the conclusion that replacing your system entirely is a better option. However, careful planning and foresight are necessary for making this decision. If your system has been significantly impacted, it may be appropriate to consider replacing your current processing applications with new ones that can convert your old data.

What steps are your suppliers and customers taking? If your systems rely on each other, it is important to reach an agreement on a format and plan of action. Choosing unbiased standards is clearly the

rational choice, and regardless of the agreed-upon format, all parties impacted by your internal changes must adopt it.

Having a strategy for deployment and testing is crucial once a plan of action has been committed to. A schedule must be in place for the deployment and testing of the new system, keeping in mind that the deadline cannot be extended regardless of available resources. To avoid encountering the year 2000 problem, it is necessary for the system to be operational by January 1, 2000. The year 2000 problem is a complex programming project with tight deadlines, a broad scope, and compatibility issues that often cause delays and setbacks. It is advised to hire a separate project manager who specializes in these types of applications to ensure timely completion of plans. It can be challenging for many companies to find experienced individuals with expertise in year 2000 conversions. Testing the software also presents its own unique challenges and difficulties.

Ensuring compatibility with post-millennium code and prior code and data is a time-consuming task. It requires extensive manual testing, as parallel testing equipment is usually not available. This manual testing process is prone to errors and consumes a significant amount of time.

"To ensure that functionality has not been changed in any program as a result of the date changes, systems must undergo thorough testing. This includes conducting a unit test of the program, performing a system test using a test bed that covers all functions, simulating future dates that may affect the system by moving data and adjusting the system date, and finally, testing the system with historical data to ensure processing of old data is successful after the

changes have been implemented."

Developing a test bed for the changes is a significant task. The testing stage represents 40% of the effort for the entire project. According to Brenda McKelvey, from a report on the "Year 2000: Blueprint for Success" conference in Orlando, Florida, November 1995, this project is going to be extremely expensive for some companies. The projected figures for money spent on converting or re-engineering computer systems, as well as money lost due to millennium bugs causing downtime, are enormous. If you have already been planning, you may have established a fund that can be used for consultation and bug fix implementation. However, if you haven't, you will need to find resources to fully implement these changes before downtime starts costing your company money.

If your company had software developed and it suffers from the specifications you provided, is it stated in the development contract that there could be inherent system failure for your systems? If so, is it possible to take legal action to recover some of the costs associated with re-engineering or repairing your computer network? Start implementing your plan of action. The repairs and replacements need to be done urgently, so make sure to plan and have regular meetings to review progress and code to ensure that you can stay online for the foreseeable future - or at least until the next software upgrade.

An Example: Case Study - MicroCorp Widget Producers, Inc.

Scenario: A small corporation employs customized PC-based sales software for Windows 95 and a larger, custom-programmed database/retrieval system (old). This larger system connects with their supplier's computer to automatically ship source materials when they are running low. The solution for

Microcarpa Widgets is multi-faceted. It begins with testing their PCs to determine if the BIOS will support the year 2000. Without this support, all software, including the operating system, will display incorrect dates. Next, the sales software is analyzed to ensure it can handle the year 2000 accurately. If the source code is accessible, manipulating the software to accommodate the chosen date format (IS 8601) should not be difficult. If the source code cannot be obtained, a re-write of the software will be necessary. Additionally, discussions with suppliers are necessary to implement an IS compliant or mutually agreed-upon standard to avoid disrupting normal business operations. The mainframe situation also requires evaluation to determine the availability of source code, compatible tools, and compilers. If these resources are accessible, are there programmers available to facilitate the conversion? Lastly, it is important to assess whether transitioning to a more modern and flexible system would be an attractive and necessary move.Based on the analysis of the impact, a concise and clear strategy should be developed to transition the company to a new setup. This common setup poses numerous potential problems and can be quite expensive if not handled efficiently. The main challenge for this widget producer lies in convincing its managers that there is an issue that needs to be addressed. This paper must demonstrate that there is no easy solution for most medium and small enterprises. Any corporation with internally developed software for inventory or database control will inevitably face this situation, which will require re-engineering or replacement and incur significant costs in terms of both money and time. Additionally, potential downtime could result in even greater expenses.

The problem is further aggravated by its magnitude - there will also be a global scarcity of individuals capable of addressing this issue.

A comprehensive solution is the only effective approach to deal with this issue. It is crucial to carefully plan and implement strategies before the absolute deadline of 01/01/2000, which many IT experts have already deemed as passed. Managers should now focus on plans that minimize downtime. However, from an entrepreneur's perspective, this situation presents a great opportunity. "Plug and play" solutions could be developed using existing data formats for conversion, enhancing functionality and speed. The impact of this situation will make the upcoming years in the IT field very intriguing.

Your preparedness will face swift judgment on December 31st. The bibliography includes various sources related to legal issues surrounding the Year 2000 by Jeff Jigget [http://www.year2000.com/archive/], ISO 8601 Standard for Numerical Representation of Dates by International Standards Organization [http://www.cl.cam.ac.uk/mgk25/], Year 2000 Issues List by Serge Bouwens, PTT Telecom Netherlands [http://www.year2000.com], The Millennium Mess by CACI Incorporated [http://www.caci.com], and Experts Call Year 2000 Bug a Real Threat by Reuters News, Inc.

http://www.reuters.com/
Datamation Magazine
http://www.datamation.com