The Year 2000 (Y2K) problem is being considered as the hottest topic these days. It is a potentially disastrous implication for most of the computer-based system and electronic devices that use clock-embedded microprocessors. This problem will mainly affect computer systems with date-reference such as transaction processing systems for banking, horse racing and ticketing. The systems with date-reference functionality will completely or partially be out of order.
The Y2K problem is caused by some simple reasons that are not difficult to understand. The Y2K problem mainly stems from the use of 2-digit date representation in software systems. This problem is so challenging due to the extent of affected systems and business transactions involving frequent date manipulations.
Before the 90's, when computer memory was incredibly expensive, computer programmers wanted to conserve memory to achieve lower hardware cost and higher processing performance. They used 2 bytes to represent the date. Since 2 bytes in the binary term can effectively represent the meaning of DDMMYY, the year was represented and stored by using 2 digits, YY. For example, "90" means "1990" with the century digits "19" implicitly prefixed. With the advent of PCs later, modern computer systems have inherited this 2-digit memory conservation practice. Ironically, this practice is still commonly used due to its convenience.
The 2-digit year representation is only feasible before the year 2000. As we stride into the next century, 2-digit year will cause confusion and failure in manipulating the data with date reference. It is because all non Y2K compliant software systems will assume the maximum of a year as "1999" and will not roll the systems over to "2000". The Year 2000 will be misinterpreted as the Year 1900. This misinterpretation will literally lead to chaos. For example, if a pensioner was born in 1930, his age in the Year 2000 will be miscalculated as 1900-1930 = -30 which will cause a semantic error to a computer system. This may result in stopping his pension immediately on the first day of the Year 2000. Similarly, if this misinterpretation happens in banking system, the interests for saving accounts will be calculated wrongly.
Since the Year 2000 would be misinterpreted as the year 1900, the computer system would use the calendar of the Year 1900 for the Year 2000. Unfortunately, the calendar of the Year 1900 is different from the Year 2000 calendar. This would lead to chaos.
In relation to the calendar, there is another major problem which comes from the wrong determination of a leap year. The leap years can be determined based on the 3 rules:
Rule 1: Years divisible by 4 are leap years, unless
Rule 2: Years also divisible by 100 are not leap years, except
Rule 3: Years divisible by 400 are leap years.
Some computer systems may not recognize the Year 2000 as a leap year as they use a faulty algorithm based on Rule 1 and Rule 2 only. Therefore, the wrong leap year calculation will assume that there are only 365 days rather than 366 in the Year 2000, causing all dates that follow February 29, 2000 to be incorrectly offset by 1 day.
To demonstrate the correct leap year determination method, we can look at 1991, 1992 and 2000 as examples. The year 1991 is not a leap year as it does not satisfy Rule 1. The Year 1992 is a leap year as it satisfies all the 3 rules. Although the Year 2000 violates Rule 2 but satisfies Rule 3, therefore it is a leap year.
The final potential problem in the Y2K issue relates to some specially used numbers in software programs. Sometimes, programmers like to use hardcoded values in software programs to identify special condition. For example, the software developer can program the computer to consider that a record is being deleted if the year of a date of the record equals to "00". This approach is very common in some temporal constrained applications. There are many magic numbers being used by programmers in determining special conditions in their programs.
2. Definition of Year 2000 Compliance
Currently, different organizations have their own definitions of Year 2000 compliance. However, their differences are subtle and without any conflict in essence. For reference purpose, the definition given by British Standards Institute (BSI) is discussed here.
Year 2000 compliance shall mean that neither performance nor functionality is affected by dates prior to, during and after the Year 2000. In particular:
Rule 1: No value for current date will cause any interruption in operation.
Rule 2: Dated-based functionality must behave consistently for dates prior to, during and after the Year 2000.
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: Year 2000 must be recognized as a leap year.
3. The Key Elements of the Y2K Problem
If the Y2K problem actually causes computer systems to completely breakdown, that would be regrettable but not irreplaceable. However, there are may cases that computer systems may run as usual but behave abnormally only in some Y2K conditions. Multiyear projections have already begun to yield spurious results in insurance, bond maturities and demographics because subtracting a date in the 90s from a date ending in 00 gives a negative value. In this section, we investigate the major components of computer systems that are susceptible to Y2K problems.
Workstation and Servers
Network Operating System
Off-the-Shelf Software Applications
Tailor-made Software Applications
Network Management Software
Bridges, Routers, Hubs, Switches
Workstation and Servers: Workstations or PCs and Servers are at risk due to the problem in the Basic Input/Output System (BIOS). Most computer manufacturers did not develop their BIOS with the ability to automatically adjust the incorrect year generated by the real time clock on January 1, 2000. Users still using older PCs such as 386 and 486, may have to enter the correct date every time they reboot their systems. The BIOS problem is not limited to older PCs. Some server models released as late as 1997 have a BIOS that will not correct the system date unless updated. Therefore, the BIOS of new and old systems must be inspected to determine whether they are Y2K complaint.
The necessity of having a Y2K compliant BIOS on a PC is underscored by both desktop and network operating systems. Most major operating systems were coded to support 4-digit years while others can with a patch. But this ability is useless if a non-compliant BIOS transfers an incorrect year to the operating systems date stamp. Each time the OS or network operating system transfers an incorrect year to an application that requests it, any number of errors can occur.>
Operating Systems: Some operating systems, such as Window NT 4.0, keep a date stamp and have the ability to correct erroneous dates from the BIOS. However, old operating systems, such as MS-DOS, will interpret 1900 as an invalid date and store 1/1/80 as the system date since this is the earliest date it can recognize. Novell Netware 3.12, IntranetWare 4.11 and both Micorsoft Windows 3.1 and Windows 95 will behave the same.
Networking Equipment: Networking equip-ment, such as routers, hubs and switches, are also the sources of the Y2K problem. This is mainly due to the protocol management firmware and software of networking equipment that only store 2-digit year. As a result, the entire network segments may be isolated from one another after the century rollover because a non-compliant network device failed. For example, Cisco 2500 Router IS only compliant if it has IOS version 11.X or later installed.
Off-the-Shelf Development Software: Most organizations will develop application software by using off-the-Shelf development software, such as dBase, Clipper, FoxPro, Cbasic, VisualBasic, PowerBuilder. These developmentsoftware may also be Y2K non-compliant. Again, the problem is how the development software handle the dates internally.
Application Software: If an organization is using an off-the-shelf application software, they should check the date arrangement of the software to determine whether it is Y2K compliant. In some cases, we can check whether the application software was developed by an Y2K compliant development software and operating system.
Most large-scale tailor-made application software, such as banking system, horse racing system, enterprise resource system and transportation system will present a more serious problem to an organization. Normally, these software systems were developed a long time ago and evolved to a large scale in a long period of time. In a large scale system, different modules may be developed by different development teams using different development software tools. The Y2K compliance depends on how the programmers specified the way to store, represent, and manipulate dates in the application programs. Sometimes, the developments may lack centralized development management. As a result, making tailor-made application software Y2K compliant will be very costly.
4. Tackling the Y2K Problem
With the complexity of the Y2K problem, it is essential to establish a well thought strategy before taking any action. Based on the experienced gained in a number of system conversion and reengineering projects, Crossland suggest a methodology with five stages for tackling the Y2K problem.
Stage 1: Awareness
The Y2K problem requires a high degree of awareness from different levels of management. The organizations that face the Y2K problem should understand that the scope of the Y2K problem covers hardware, system software, application software, networking equipment and any clock embedded electronic devices. Based on the overall understanding of the Y2K impact, relevant parties should be involved in preparing an inventory list which includes all Y2K affected elements. One can follow the key elements discussed in Section 3 of this paper. It is also essential to form a special task force to tackle the Y2K problem. The team leader will coordinate with relevant departments and report the progress to the top management regularly.
Stage 2: Assessment
Once the inventory list is completed. The Y2K team has to conduct hardware and software assessments. It is essential to include the compliance testing and the impact analysis in the assessment process.
The compliance testing should identify the compliance status of each element in the inventory list. For compliance testing, the following ratings can be used.
"C" - This means that the equipment satisfies the Y2K compliant definition.
"NC-WUP" - This means that the equipment is not Y2K compliant but with an upgrade path.
"NC-NUP" - This means that the equipment is not Y2K compliant and without an upgrade path.
The risk assessment should indicate the potential impact of a Y2K non compliant element to an organization. The following rating can be applied to the impact analysis.
"Disastrous" - The element will cause serious loss, such as human life or bankruptcy.
"Critical" - The element will cause serious business operational problems.
"Important" - The element will affect the operation of a business unit.
"Trivial" - The element will not cause significant damage to the business but may cause inconvenience to the business operation.
For the software assessment, the Y2K team must understand the functionalities and data flows of the software modules so that the interdependence of the software modules can be identified. Complex software systems that consist of highly interrelated software modules are hard to be upgraded. This is because changing a single software module will lead to inconsistency in other software modules.
Stage 3: Planning
The Y2K solution planning involves decision making based on the analysis from the assessment stage. All identified disastrous and mission critical systems and software modules should receive the highest priority to address the Y2K issue. The approach for Y2K compliance depends very much on the cost-benefit analysis. We can replace some old equipment if the replacement cost is reasonable. In some occasions, replacing old equipment can more cost effective and operationally efficient as maintenance cost can be very low and processing throughput are normally much higher for new equipment. If the equipment is not a crucial part for the functions in the business operation, the organization may consider retiring the equipment.
If the top management would like to take the opportunity to improve the business system while performing the Y2K conversion, the planning team should put in resources to perform systems reengineering.
All system upgrades require an associated contingency plan in case any unexpected failures occur.
Stage 4: Modification and Testing
A software system normally consists of a number of software modules and in turn a software module may consist of a number of programs. Y2K modifications can be very complicated if the software system has a complex connectivity. In the assessment stage, the Y2K team would study the interdependence of the software modules so that they can determine the complexity of the problem. In the modification stage, it is essential to study the data flow and logic of all programs further before the modification is started. This task should be accomplished by the Y2K team and the programmers who have knowledge about the programs. Crossland introduces the following software engineering approach to perform software modification and testing.
Step 1: Scanning the software programs to identify all major date related elements.
Step 2: Analyzing the functional requirements to identify all mutually exclusive program units of a software module.
Step 3: Prioritizing the modification sequence of the program units.
Step 4: Modifying the independent groups of program units.
Step 5: Testing the independent groups of program units
Step 6: Performing integrated testing of all locally tested program units.
Step 7: Performing integrated testing of all related software modules.
Step 8: Performing integrated testing of the completely modified system.
Stage 5: Implementation
Implementation must be preceded by an entire system backup. Specifically, system backup needs to be performed before installation of any new component to the system. In the implementation stage, it is essential to establish a good approach for system recovery if failure occurs after the addition of any new component.
After implementation, we need to confirm the Y2K compliance status by testing new items recently purchased since they are not necessarily immune to Y2K concerns. Moreover, technical training and support will be provided to the users with respect to the new or upgraded system.
The millennium bug is just round the corner. Hopefully most of the Y2K problems will be sorted out in time. But we know many will not. Consider the chaos with just everyday activities that are now completely controlled by computer. Y2K problems will not happen on the stroke of midnight. Their cumulative effect will begin to pile up and may seriously damage the supply chain. Do whatever you can to safeguard yourself and your organization. Nevertheless, I shall not fly on the first day of the Year 2000.