Solutions for the Year 2000
Y2K Site Map | Terms of Use | Problem | Steps | Certification | Briefings | Compliance | Solutions | BIOS | Test & Evaluation | Cost
The following Y2K material has been kept available by MITRE for historical purposes only and has not been updated unless noted.
|
Dealing with Dates: Solutions for the Year 2000 |
The Year 2000 (Y2K) problem is the software problem of the 20th century. This article defines the concepts, terminology, and individual aspects of the Y2K effort and presents a process an organization can use to address its own Y2K challenge in a forthright and level-headed manner. Solutions, compliance definition, testing, and costs are also addressed in this article.
lthough Sigmund
Freud completed his Interpretation of Dreams in late 1899 and copies were already circulating, he postdated the title page to the first of the year
because he wanted to establish psychoanalysis as a
20th-century science. Computer scientists working today on the
"Misinterpretation of Dates," more commonly known as the Y2K problem, probably wish they could postpone the
unveiling of their work as easily and avoid the establishment of system disaster recovery as a
21st-century science.
The Y2K problem is real, though we still do not have a true sense of how extensive it is. Studies to define the
scope of the problem and the costs to fix it have produced widely varying results, which causes confusion and concern.
The Y2K problem has caught the media's attention and the public's imagination, and it has stimulated aggressive
vendor response. Approaches to resolve the problem and manage the risks tend to focus on how particular tools and
vendors can help. In this article, I first will discuss the concepts, terminology, and individual aspects of a Y2K effort, then I
will define a process an organization can use to address its own Y2K challenge in a forthright and level-headed manner.
Y2K Problem Defined
For whatever reason—to save precious memory in an era when memory was incredibly expensive, because
systems were not expected to last this long, or simply because the problem was not recognized—programmers long ago
adopted a two-digit convention to represent the year. This convention will cause failures as we approach the turn of the
century and beyond. The problem has precedent: few realized that the IBM 360 could not handle dates past Dec. 31, 1969
until IBM 360s all over Europe began to fail at midnight, local
time. As the failures progressed from time zone to time
zone around the globe, IBM identified the problem and was able to provide its American and Asian customers with a
temporary fix by telling them to lie to their computers about the date. Meanwhile, IBM created a longer-term patch
for the problem.
Briefly defined, the Y2K problem involves any or all of the following:
How Vast Is the Problem?
Just as today's railroad uses a rail standard derived from the width of a Roman chariot, modern computer systems
inherit their default conventions from the mainframe era, when it was common practice to encode the year as a two-digit field.
After all, workstations and personal computers were initially built to augment mainframe systems and use their data.
The Y2K problem is exceptionally widespread. It affects hardware (BIOS, real-time clocks), embedded firmware,
languages and compilers, operating systems, random number generators
and security services, database-management
systems, transaction-processing systems, electronic data interchange and banking systems, spreadsheets, PBXs (private branch
exchanges), telephone systems, and more. The Y2K problem is not merely an information systems (IS) problem.
Although the majority of Y2K problems are located in ISs, the sad truth is that systems anywhere that use dates may be
threatened.
It is naive to assume that new applications and systems are immune to the Y2K problem. It was only late last year that
a new version of Quicken, a popular personal finance package, was released that could handle dates beyond 1999 [1]. At
the January Federal Interagency Y2K meeting, it was reported that the National Institutes of Health received a shipment
of brand-new personal computers containing three versions of BIOS, two of which failed to correctly handle the century
transition.
What Makes It Unprecedented?
Although similar to other software problems, such as the four-digit ZIP code extension, the Y2K problem has some
peculiarities that make it more than a standard maintenance problem. First, it has a deadline that will not move and is
common to everyone. And we will all be competing for scarce resources—COBOL programmers and testing
personnel, for example. Second, it affects every system that has an external interface. Therefore, fixes for interrelated systems must be
fielded simultaneously; otherwise, systems could be inundated by the proposed changes from systems with which they
interface. Third, instead of the traditional reaction to a maintenance
problem—"Here's the problem, fix
it"—the reaction to a Y2K problem is "Where is the problem and what are the fixes?"
Testing, validation, and fielding will consume the lion's share of the costs associated with fixing the Y2K problem.
For some, the solutions may be influenced, complicated, or dictated by legislative or regulatory mandates. Other regulations
will simplify how a fix is fielded. For example, the new U.S. acquisition regulation interim rule mandates the use of Y2K
warranty language that defines compliance as "information technology that accurately processes date/time data (including but
not limited to calculating, comparing, and sequencing) from, into and between the [20th and 21st] centuries, and the years
1999 and 2000 and the leap year calculations."
[2]
How Much Will It Cost to Fix?
It is difficult to estimate the cost of the Y2K problem. The Gartner Group estimated that costs for the U.S. Department of
Defense (DoD) alone could start at upward of $30 billion, and worldwide costs could approach $600 billion. A more
detailed analysis of specific DoD systems in 1995 by MITRE looked at 5.4 million lines of DoD code from nine command and
control and two information systems [3]. The study found that only 1.16 percent—or about 62,600 lines of code—involved date
manipulation, and this code was contained in 10.03 percent of the modules in the systems. The MITRE study estimated that
corrective maintenance to these systems would cost between 75 cents and $1.70 per line for application information
systems and from $1 to $8.52 per line for command and control systems. Other experience reports suggest that between 10
percent and 15 percent of IT systems code is typically affected
[4].
These dollar rates can be used to calculate a rough order of magnitude (ROM), or first-cut estimate of
an organization's potential Y2K costs. ROM estimates use a cost multiplier to translate software size (in executable lines of code) into a
dollar estimate. The ROM-estimate approach is based on the assumption that there is a general correlation between the
application type and the density and distribution of dates in source code. These metrics can be used in conjunction with
maintenance productivity rates to model the cost and effort to fix these types of applications. These models are then used to derive
the cost multipliers.
ROM-based estimates do not reflect the costs to upgrade commercial-off-the-shelf (COTS) products, work around
inaccessible documentation for software or firmware, or produce and field new chips. You must quickly move beyond ROM
estimates to detailed cost estimates based on the actual problems and the planned solutions. Use an appropriate set of
work breakdown structure costs to make visible the necessary allocation of resources to critical areas. Answer "what-if"
questions concerning budget vs. technical trade-offs, justify future Y2K funding, and understand the business consequences
of your decisions.
When preparing Y2K solutions, every organization must be mindful of all relevant auditing criteria, accounting
standards, and financial disclosure requirements. More detailed cost estimates not only support formal audits and disclosure
but also provide input to the business plans and corporate strategies affected by the impact the Y2K problem can have on
cash flow and tax liabilities.
Y2K Solutions
The leap year, magic number, and date counter overflow problems can be repaired with straightforward corrections
wherever they are found.
The same is not true for the incorrect handling of the two-digit year. A variety of approaches are available and
should be evaluated to identify the one that best suits your organization's priorities, resources, and schedule. Bridging
mechanisms will be a major part of any solution approach. Bridges convert between old and new data formats and programs
or between external and internal formats. Some bridging will allow
updated components to be deployed separately,
while others will become long-term structural pieces of the systems.
To take special care in the design and functionality of the bridging pieces can prevent performance degradation.
There are at least seven major, viable courses of action that can be combined as appropriate to deal with an organization's
Y2K problems:
Expanding the Year Field to Four Digits
This solution requires all references to and uses of a two-digit year format (YY) be converted to a four-digit year
format (YYYY), and all programs must be converted to use the new format. The major risk in this approach is that a
program may directly access the internal structures of a date field; thus, changing the field size without also changing the
logic that accesses the internal structures will corrupt the revised
system.
This solution is complete, and it ensures the applications will operate correctly for the next 2,600 years. However,
it involves the modification of every program and every database that references date data; the adjustment of every
positional reference to data fields; changes to the format of every record that contains date data; and a reformat and rewrite
of every data file, including historic data files.
This approach may also require a change to the format of messages among systems. The changes will initiate a
chain of modifications that will require simultaneous testing and rollout of the new systems across organizations.
Encoding Century Information in a Six-Digit Space
Century information can be encoded into the same space currently occupied by the standard six-digit date
field (YYMMDD). This might be done to address disk performance tuning and balancing issues or because of rigidly
defined field sizes in standard messages. There are at least five ways to do this:
Figure 1. The 100-year sliding window [6].
The logic-window technique does require some extra overhead and code logic—dates, sorts, collations, literal
comparisons, and computations must be correctly mapped to the two-digit date to assure that computations are correctly
performed. However, this technique avoids most of the massive changes and interorganizational coordination associated
with the expansion approach. As long as old data is dropped and the 100-year span of dates is retained, applications that use
a 100-year sliding window will continue to unambiguously interpret date data and calculations for a long time.
Applications that have some large date spans may be corrected with a combination of the expansion and sliding
window approaches. Such a mixed approach requires that the uses of dates be modeled more precisely to distinguish between
fields that should be expanded and those that should not.
If an application deals with data that is more than 100 years apart, this approach cannot be used. However, many
systems do not have to deal with time spans of more than 100 years. For them, this solution is extremely attractive because it
requires no data changes—only programs are changed.
Data Bridge Using a Logic Window
This solution is popular because it allows for a fairly straightforward conversion of the applications to a four-digit year,
yet allows external interfaces to continue in two-digit formats. This is done with simple data bridges that map the internal
and external date data through a logic-window approach for all inputs and outputs.
Reverse the System Clock and Use a 28-Year Time Bridge
For systems whose source code is no longer available, cannot be replaced, or whose purchased components are not
century ready, there is an option other than replacement: the system clock can be reversed by 28 years and bridging scripts can
be written to add or subtract 28 years from the date data. The number is 28 because this offset retains the same days of the
week and month. When 28 years are added to Saturday, Jan. 1, 1972, it will generate Saturday, Jan. 1, 2000. Note that this
works only for periods that have a leap year every four years (1901-2100), which means this approach is good only until Feb.
28, 2100.
Replace or Retire the System
For some systems, the best option may be to replace them with Y2K-safe commercial products that do most of what you
need. An interesting alternative to the purchase of a commercial product is to merge with or buy a company that has Y2K-safe
systems and retire yours.
Do Nothing
In some cases, the best option may be to do nothing. This is not the same as to ignore the problem. Rather, it involves
an analysis of the risks to determine that the Y2K problem will either not cause a problem or cause such minor problems
that users can work around them and compensate. For example, a system might sort something out of sequence for one
reporting period or produce only minor errors that have no impact on functionality. In a world without resource constraints, this
kind of system would probably be fixed, but in the real world it is advisable to reserve resources for systems that will have
more severe reactions to the date change.
Y2K Test and Evaluation
It is important to specify in some detail the goals and role of the Y2K test and evaluation effort. In many cases, it may be
next to impossible to prove that the Y2K problem has been fixed. One reason is that many systems interface with components
that cannot be rolled forward to test. Satellite networks and telephone systems are two examples. These interfaces can be
simulated and analyzed, but it may not be possible to test them to the same level of confidence as other systems. The need to
work with users should not be overlooked. They need help to understand the levels and types of risk the system has so they
will remain confident in the system's performance.
Systems that undergo Y2K maintenance should be evaluated to determine their degree of Y2K compliance and
whether this compliance is sufficient for organizational goals. Any testing activity should be aimed at gathering information to
determine the degree of Y2K compliance.
Stage the testing and evaluation of purchased components early so that infrastructure errors do not mask the failure of
the original application. Address the validity of licenses and passwords for the duration of the full testing period. Likewise,
ensure that the testing environment and testing tools operate through the entire testing period. They, too, are susceptible to
the Y2K problem.
Y2K testing requires a layered approach. Test applications in isolation, then test systems, then test a system of systems
to the extent possible. These increasingly complex entities will have the same compliance requirements, but the approach
to gathering data will be different for each.
Details for an overall Y2K assessment approach being used within much of the DoD can be found in the "Exit
Criteria Checklist"
(found at
http://www.mitre.org/research/cots/COMPLIANCE_CHECKLIST.html) System time windows and the existence of various date-related rollovers of date counters complicate proper date handling. Each system functions in
its own time window, which surrounds the present date. Planning and scheduling systems work with dates that are
weeks, months, and sometimes years in the future. Trend analysis systems and billing systems regularly reference dates in the
past. You will need to verify the ability of your system and its window of time to successfully process dates before and after
the transition to 2000.
A Silver Bullet?
To successfully manage your Y2K effort, you may apply a wide variety of tool technologies. Many Y2K discussions
focus solely on tools that can find and possibly fix the problems. But a larger set of tools—including testing, configuration
management, project planning, and cost estimating tools—are just as important and possibly indispensable.
One caveat to the pursuit of tool technologies for Y2K is to do it appropriately rather than overwhelm and distract
your staff from their jobs. It is extremely important that the introduction of new tools be compatible with your organization
and that it not cause a paradigm shift that will lower productivity and reduce the quality of the work.
Tools to Locate and Fix Code
First, you need to find the code. Keep in mind that your inventory often includes systems that are
homegrown, no longer maintained, or undocumented software, undocumented firmware, and COTS systems. You will need tools and techniques
to find these components. Once found, scanning, tagging, and conversion tools can be used to place both the source code
and documents on line.
Second, you can use analysis tools to search for possibly erroneous code, such as operating system search tools and
commercial Y2K-aware search tools for application code. One of the most significant problems with using analysis tools to
find the date problems in firmware and software is the false negatives and the false positives. False negatives are date
problems that the analysis tools miss. False positives result when the tools spew out a plethora of potential problem areas that the
analyst must then wade through to find the real problems. Both types of problems can be addressed with tools that more
fully understand the context and usage of the dates, such as some of the reverse-engineering technologies that the Air
Force's Rome Laboratory has helped develop and introduce into the commercial marketplace. These intelligent tools reduce
the search to actual problems—find date data by mining data dictionaries, message sets, file exchanges, variables, and so
forth. These rule-based artificial intelligence tools can follow assignments and look for behaviors within the code, but they
need specialized parsers, a great deal of computing power and memory, and some must first be programmed with your
business rules to understand what to look for.
Although these intelligent tools are getting better, they are not silver
bullets, and they will not solve the problem in
its entirety. To make automation viable, you need to partner it with knowledgeable and skilled analysts. Given good parser
technology, tools can detect most date-related lines, but there are still ambiguities that require humans to decipher:
Tools for Testing
Estimates suggest that testing will account for about 45 percent of the Y2K effort. One way to minimize the test effort is
to use testing tools to develop automated and repeatable test methods. Test scripts and scenarios provide a reasonable,
repeatable way to conduct effective stress tests of various problem dates.
Y2K testing is unique in that it requires testing at numerous points in time, and each test requires supporting test data
and test scenarios. Table 1 shows sample dates to consider testing—the specific dates you need to test will depend on the
composition of your systems.
|
Date Event
1998-01-01 Flag Year 98 1999-01-01 Flag Year 99 1999-09-09 Magic Number 9/9/99 2000-01-01 Overflow 2-Digit Years 2000-1-10 First 9-Character Date 2000-10-10 First 10-Character Date 2000-02-29 Leap Year 2000-12-31 Day 366 of the Year 2001-01-01 21st Century 2100-01-01 Not a Leap Year 3000-01-01 Not a Leap Year |
| Table 1. Some possible date-related failure dates. |
It is vital that systems developers be responsible for the correction and fielding of a fixed system. Organizations that set up central testing and clearing facilities encounter tremendous logistical and coordination problems in dealing with multiple environments and languages. The systems developers, who already possess development and test capabilities, are in the most cost-effective position to validate and verify the correct behavior of their own systems. What the central organization should do is provide adequate and specific criteria to assure that everyone is consistently finding and fixing the potential problems (see "Exit Criteria Checklist" in the "For More Information" section).
Tools for Project Management
Configuration management tools are indispensable to handle the rapidly changing system components and the
performance of multiple regression tests. Given the varied steps and numerous parties involved, along with the stress of an
immovable deadline, a good project planning and project monitoring tool set will be extremely valuable. Likewise, as the project
moves forward from its initial rough cost estimate, cost estimating tools and models will be tremendously important in
answering trade-off questions and keeping a handle on the actual impact of the Y2K remediation effort.
Triage Scorecard
Because of risks, schedule constraints, and budget limitations, senior management must be pro-active in the oversight of
Y2K efforts. Senior managers must have current information that allows them to make timely decisions about resources and
priorities. To this end, MITRE has developed a
"triage scorecard" designed to help managers
Figure 2. Y2K triage scorecard. R = red; Y = yellow; G = green; B = blue.
The Y2K triage scorecard, in conjunction with lower-level,
detailed status information, is a management tool that provides periodic reports
on the Y2K risks that may affect an organization's ability to do its job. A
full discussion of the scorecard and a spreadsheet version of it can be found
on the MITRE Y2K Web site (http://www.mitre.org/tech/y2k/docs/index.html).
Each row represents the status of a system, a subsystem, or a collection of interrelated or interoperating systems.
Red (R) represents the highest risk and hence the highest priority in making changes—it requires immediate attention.
Yellow (Y) represents moderate risk—it should be monitored. Green (G) indicates that renovation is proceeding smoothly
with low risk—no management action is anticipated. Blue (B) indicates satisfactory solution of problems or completion of
an activity. A blank field in the implementation status area means no activity has begun.
The inventory step is distinct but usually considered the initial part of the assessing and planning phase. The
percentages along the right represent ranges for the activities according to industry surveys.
Where to Start - A Y2K Process
A typical Y2K effort has five major phases, as developed and used by the
DoD [7]. The process can be tracked with a scorecard or some similar mechanism (Figure 2). Upper management should be apprised of the process at each phase.
Figure 3 illustrates the five phases:
Figure 3. The relative amount of effort will differ for each phase of a
Y2K project.
Awareness
Each organization must educate its employees about what the Y2K problem is and how to deal with it. Many have a hard
time believing that something as trivial as a lack of two digits in a date can cause a serious problem.
Inventory, Assessment, and Planning
This phase involves eight steps:
Validation
Here, you test fixes with an exit criteria checklist. To test fixes to Y2K problems will require new and expanded
procedures compared to our traditional approaches. On top of all this, as
mentioned above, systems typically deal with a window
of time—a range of dates both before and after the present date—that requires testing beyond Jan. 1, 2000.
Field
In this phase you proceed to field (or in most cases, re-field) the fixed systems. This includes the training necessary for
the system's users. Although most organizations will be able to use their traditional methods to field new systems and upgrades
for the changes needed for Y2K, there will probably be several additional issues that impact their traditional approach. The need
to ensure that all changes are implemented on time against a firm, no-slip deadline will be new for many organizations. The
simultaneous change of commercial components, developed
components, and procedures also will be new for many. Finally,
for those forced into a change in their interfaces, the coordination and simultaneous activation of your new release with
your interfacing partners will be especially challenging when more than one interface is changing.
Conclusion
The Y2K problem will cause some bizarre and possibly unexplainable happenings. Peter de Jager tells of a Scottish bank
that was so confident of its systems that it overruled its Y2K service provider's desire to continue testing. The bank advanced
the year and began to run reports. One looked rather peculiar. After long study, one of the bank's elder statesmen recognized it as
a printout in the old fractional pounds, shillings, and pence. Apparently, when Scotland adopted a decimal system in 1971,
the bank had used a date switch that caused every report generated after 1970 to use the new decimal format instead of the old
fractional units. But when the time was advanced to 2000, the part of the system that used the date switch thought it was back
in 1900, so it reverted to running the old reports.
I hope this article helps you to avoid a similar mishap. Y2K is solvable, but it will take a reasoned and thorough effort.
Acknowledgments
The summary work contained in this article was funded by
the MITRE Corporation and is based on the composite effort of
all the individuals at MITRE that work on the Y2K effort. Special thanks to Thomas Backman, Michael Brenner, Judith Clapp,
Paul Garvey, Calvin Groenewould, Lawrence Shafer, John R. Roberts, John Vitkevich, and Barbara Wolfinger for their
thoughts, ideas, and efforts in dealing with the Y2K efforts on which this article rests.
About the Author
Robert A. Martin is a manager
within MITRE Bedford's software engineering products and practices section, where MITRE
promotes the use and development of various product and process assessment technologies and methods.
MITRE became involved in researching, addressing, and facilitating their customers' Y2K efforts in 1995. One part of their effort is a Y2K Web site that
addresses Y2K issues from a DoD perspective. Martin and his group work with the majority of MITRE's DoD customers (as well as MITRE)
to address the Y2K problem. Martin received a bachelor's degree and a master's degree in electrical engineering from Rensselaer
Polytechnic Institute and a master's of business degree from Babson College. He is a member of the IEEE and the IEEE Computer Society.
ReferencesMITRE Corporation
202 Burlington Road
Bedford, MA 01730-1430
Fax: 781-271-8500
E-mail: ramartin@mitre.org
For More Information
MITRE has established a clearinghouse for Y2K information on a Web site that includes papers and presentations, templates and
work sheets, discussion forums, cost estimation help, and links to other Y2K sites.
The Web site also provides a catalog of Y2K tools, services, and consultants, although we do not endorse the companies and
products listed in the catalog. The newest part of
MITRE's clearinghouse provides information about the status of COTS hardware
and software with respect to their ability to handle the transition to 2000, leap year, and other time-related sources of problems.
We welcome contributions of information and solutions from all quarters and have provided simple submission forms for
this purpose.
MITRE also has ongoing research investigations into enhancing commercial reverse engineering-based Y2K analysis tools.
We also are exploring the potential payoff in reworking compilers to overload date-related operators so that they correctly
handle transcentury two-digit dates. We are producing a proof-of-concept GNU-based compiler and exploring the viability of this
approach with compiler vendors with an emphasis on compilers for DoD legacy systems. We also are exploring ways to use pattern
matching and visualization to attack the problem of false positives discussed in the article.
This article is based on an article that first appeared as a cover feature in the March 1997 IEEE computer magazine, COMPUTER.
© 1997 IEEE. Reprinted with permission, from COMPUTER; Vol. 30, No. 3, pp. 44-51, March 1997.
For further information directly related to Year 2000 issues, please contact Year2000@mitre.org
Information is provided by the MITRE Y2K Team Last modified: Thursday, 14-Feb-2008 09:21:03 EST
|