Year 2000
One second after midnight December 31, 1999 data stored in non 2000 compliant software will become unusable, the old will be young again, bank vaults will open prematurely, and traffic lights will operate erratically. The problems listed above all have one thing in common, they all use the date field for arithmetic operations. Whether or not such problems will occur depends upon action taken now, but one thing is for certain, the cause of these problems is the millennium bug. What specifically is the millennium bug? In a nutshell, when the Y2K arrives, software that uses only 2-digits to calculate dates, will interpret dates after 1999, as 100 years before the actual date. The first 2-digits of the date, recording the century, were assumed to be "19" and not stored. Any software programs using 2-digit date fields to perform arithmetic calculations will only be valid for the period 1900 to 1999. The Y2K problem arises from programmers decisions to store only the last 2-digits of the year, in order to save space. The reasoning behind this decision appears to have been primarily cost based, with other factors contributing. Storage space on mainframes at the time was very expensive, so any measures that could be taken to reduce the size of programs and data stored were used. With less data being stored to record dates, the overhead required for search times and disk access were reduced. It is also apparent that many software applications developed, have outlived their intended life span. When December 31, 1999, 11:59:59 p.m. ticks over to January 1, 2000 the problems illustrated above and many more will occur unless action is taken. The scope of the Y2K problem is not confined to software or hardware, but includes many legal issues. It is said that lawyers are waiting in anticipation, for the lawsuits to begin. Court cases have already begun to appear in the U.S., and their outcome may set a precedence for the cases to follow. While the solution to the Y2K problem is not technically challenging, it is on a global scale and very complex. The actual modification of date variables to accommodate 4-digit dates is not that difficult, the real problem, is being 100% certain that all systems in the organisation have been modified for compliance. In order to be Y2K compliant before 1/1/2000, organisations must prepare well in advance. Organisations should follow project management guidelines set out to aid them in solving the problem. Organisations small and large must deal with the problem, as it will not go away.In one way or another everyone, will be affected by the Y2K problem. Vendors must supply Y2K compliant hardware and software, or go out of business. Companies must have their software Y2K compliant or risk losing all their customers. The Government especially, must be Y2K compliant for social, economic and political reasons. Imagine the chaos that will occur if the IRD, do not become Y2K compliant. PC's running 16-bit Windows are believed to have the problem, and if not upgraded risk losing all data. Dozens of 16-bit Windows applications are said to have the Y2K bug just waiting to explode. Microsoft claims that many of their products are Y2K compliant. However, Microsoft Access 97 converts all 2-digit dates in imported files to "19xx" dates. Microsoft recommend that "all legacy data sources be updated to 4-digit years to avoid possible incorrect conversions." The true nightmare exists at the application level. Custom software developed may have to be examined line by line to find any date references. If one piece of hardware or software is made Y2K compliant all other systems integrated must be changed accordingly to accommodate the new operations. Each change may have a multitude of effects, that must be found, investigated and tested.
Y2K compliance means that neither performance nor functionality will be affected by dates prior to, during and after Y2K. Specifically, as set out by the British Standards Institution committee; Rule 1. "No value for current date will cause any interruption in operation." Rule 2. "Date based functionality must behave consistently for dates prior to, during and after Y2K." Rule 3. "In all interfaces and data storage, the century in any date must be specified either explicitly or by unambiguous algorithms or inferencing rules." Rule 4. "Y2K must be recognised as a leap year." Unless these rules are enforced the following types of problems will occur. Software applications may only recognise years that begin with a "1", so any data during or after Y2K will be discarded. Some random number generators use the system date and divide by the last two numbers. During 2000 this will result in a division by zero, causing the application to crash. If the date defaults back to 1900, software applications that perform activities based on the date, will cause irregular events to occur, since January 1, 1900, falls on a Monday, but a Saturday in the Y2K. In this unfortunate event, bank vaults around the country may open on a Saturday. Y2K is also a leap year, and must be recognised as such, if not February 29, 2000 will not exist.
Some BIOS's (Basic Input Output System, software contained in the microprocessor itself) have the problem, and so do the chips containing the time keeping clocks in some older PC's. PC's that contain a BIOS that defaults back to 1980, 1990, or 00, will see future sales plummet. Computers aren't the only things that have chips in them. Animals, cars, VCR's and other machines have chips of some kind in them. Most do not use dates for critical operation's and the date problem will be more of an inconvenience. Those that do use the date as part of the critical operation of a business, are of more concern.
There are two legal implications associated with the Y2K problem; tort and contract. When Y2K arrives, and most likely before, companies and individuals will be before the court alleging cases of negligence or breach of contract. Plaintiffs may claim that defendants either (1) "were negligent in failing to anticipate and avoid the Y2K problem, thereby causing damage" or (2) "breached a contractual term because of a failure to deal correctly with the turn of the millennium and thereby caused damage." Lawyers are among the few people that are certain to profit from the millennium bug, while programmers are assured of a job at least until the turn of the century. Software developers 20 or 30 years ago, with available technology and programmer practices, would not be liable for negligence. Vendor developed software today, in light of the Y2K problem, that is not fully tested and Y2K compliant, may be liable for negligence. "Under tort law, if the actor is negligent, he is liable to the full extent of the damage caused by his negligence. If the type of damage was foreseeable, then he will be liable even if the full extent of the damage was not foreseeable." Contract liability also exists. In the contract of purchasing or licensing of a computer or computer software, there exists warranties of performance. General warrantees state that the product will perform to some specification. Separate warrantees state that the product is free of "bugs". As knowledge of the Y2K bug has spread, specific clauses have appeared, such as "the product under this agreement shall conform to Millennium Certification Standards.". With contracts such as this, if suppliers do not provide products that accurately process dates falling after December 31 1999, breaches of contract will be plain for all to see. In providing a solution to the Y2K problem, companies must be careful not to infringe the intellectual property rights of vendors. Vendors often retain the IP rights, and copyrights to the software source code. Modification of a substantial part of the programs source code, or hiring vendors others than the original developers to do the work, may infringe upon the copyright owner's rights. Vendors may also treat their source code as a trade secret. Therefore before any modifications are done or planned, companies should review the software licenses for each product, and determine what they can and can't do. Another key legal issue, concerns the staffing of IT departments to do the Y2K analysis, development, testing and implementation. Companies will be required to hire more staff for a short period of time, then let them go. A result of this will be labour and employment claims, unless legal steps are put in place before-hand. For organisations with legacy applications a considerable amount of time and money will be required to solve the Y2K problem. Without strict project management processes in place, a fully Y2K compliant system is unlikely. The Federal Financial Institutions Examination Council (FFIEC) have released an outline on the project management process for financial institutions, necessary to avoid the Y2K problem. The FFIEC release outlines five phases for Y2K project management; 1. Awareness, 2. Assessment, 3. Renovation, 4. Validation, 5. Implementation. The first step is to educate everyone in the organisation. If people are still producing code that is not Y2K compliant, they are not only wasting their time, but creating more work for themselves and others. Management must be made aware of the scope of the Y2K problem, so they can provide sufficient resources. Poorly informed management may not see the Y2K problem as a major threat until it is too late. Organisations must establish a Y2K strategy, involving in-house and/or outsourced systems analysis and design. A team may be set aside to work specifically on the problem.
It is vital that an assessment of the Y2K problem on the organisation be made early. In order to discover the true scope of the problem, an inventory assessment of hardware, software and site facilities must be made. Documentation produced should contain an evaluation of the following organisational components; hardware, software, operating systems, programming languages, tools and the pool of staff skills available. For each application internal and external features should be recorded including; whether source code exists, where source code is stored, software written in-house or purchased, whether vendor code can be changed, and in what ways the date fields are used. This assessment should be done whether or not the conversion is going to be done in-house or by external consultants. Once an inventory assessment has been made, decisions can be made about the impact of the items on the business. Inventory items should be classified as critical or non-critical to the business operation, with those deemed critical given priority over others. It may be found that some applications are no longer used, and can be removed. The resources required to solve the problems should identified and acquired. Skilled people capable of completing the tasks, should be included as resources. Depending upon the size of the organisation, available personnel time, and skill base, outsourcing is an option to be considered. Project management should set goals, and establish time-frames, then ensure these are adhered to. Unlike most projects, this one has a fixed deadline that cannot be extended.
The renovation phase involves the conversion or replacement of existing hardware and software to Y2K compliant standards. Any changes made, in conversion or replacement must be documented, to make the development process visible to management. Interdependencies between applications, databases, interfaces and hardware should be carefully examined before modifications are made, with any changes confirmed by change control management, to ensure co-ordination and consistency throughout the organisation. For those organisations outsourcing their requirements, the vendors should be closely monitored. Regular deliverables should be produced to ensure continual interaction. Through re-engineering existing source code, developers can fix the date format in software applications, making them Y2K compliant. Advantages of re-engineering include, making use of existing source code. New features can be added to give extra functionality, requiring less external assistance leading to a cheaper solution. Vendors will have to produce software patches or upgrades for their applications, to ensure customers continue to use their products in the future. Patches to make hardware Y2K compliant must be used if companies choose to remain with current hardware. These simply require some software patch to be run on every machine affected. There are many tools appearing, that can scan, modify and test source code. Such automated tools are very expensive, but provide software with consistency, repeatability, and reduced manual effort. Since testing will make up 50% to 60% of the overall solution, automation should be used whenever possible. As the deadline draws near tools such as these will be in great demand. When the changes have been made they must be communicated to the internal and external users.
The validation phase, may be the most difficult, and will undoubtedly be under estimated. Validation of the converted or replaced systems for Y2K compliance is paramount to the success of the organisation. Organisations should assess testing procedures and tools to be used, prior to testing, to ensure that organisational standards are conformed to, and converted system components are Y2K compliant. Individual applications must not only be tested to ensure they are Y2K compliant and function as required, but also operate successfully when connected to other replaced or converted systems. Year 2000 test facilities may need to be run in parallel to production systems, if systems cannot be shut down for testing. When testing is complete all changes should have been accepted by all users.
All business systems should be certified as Y2K compliant, and accepted by all users. An implementation schedule and contingency plan should be. The implementation of converted and replaced systems must be carefully planned, since it is likely that components will be implemented one at a time, and integrated into the working environment. Upon failure of any components, project management should be notified immediately so contingency plans can be implemented.
The main point that this paper is trying to get across is that there is no "silver bullet" with which to kill this particular bug. Because of the complexity and number of different business applications, platforms, languages, technologies, programming styles and business scenarios, it is impossible to come up with a one-time, fix all solution. The problem needs to be addressed by each company individually. Companies that say they are not affected have not fully evaluated their situation. Organisations with legacy applications involving databases or some form of inventory control, will have to deal with re-engineering or replacement of their existing systems. Organisations must plan their strategies well in advance of the absolute deadline of 1/1/2000, as problems will inevitably arise that have not been allowed for. Companies that confront the problem in creative ways, can re-evaluate their information technology strategies, and set new long-term goals. The competitive advantage that can be gained over other companies, may be such that new markets can be entered.. The sheer magnitude of the effects will make the up and coming years very interesting in the information technology field. One thing is for sure - there will be a swift judgement of organisations readiness on December 31, 1999, 23:59:59.