what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

csl96-03.txt

csl96-03.txt
Posted Aug 17, 1999

Millennium Rollover: The Year 2000 Problem

tags | paper
SHA-256 | fa13c29dfb045dc1505551c7619662d490f4bddbc8144e8e8fada69b5b49bf6a

csl96-03.txt

Change Mirror Download
MILLENNIUM ROLLOVER:  THE YEAR 2000 PROBLEM
At one second after January 1, 2000, millions of people will
celebrate the beginning of a new year. Many people will also rue
the day because of computer hardware and software problems that
will create havoc for those who are not prepared. Simply put,
many hardware and software systems will cease to work or will
produce wrong answers when the year 2000 arrives. This bulletin
provides information that CSL has collected from a variety of
sources on the extent of the year 2000 problem, what
organizations are doing about the problem, and where help can be
found to deal with the problem.

The Year 2000 Problem
For 30 or 40 years, programmers have stored date information in
"mm/dd/yy" format to conserve space in disk storage and computer
memory. They adjusted computations to take the two-digit year
into consideration when computing time periods, ending dates, and
the like. Programmers represented years in the twentieth century
as two digits without considering what might happen once the year
2000 rolled around. At that time, most programmers and project
leaders figured that their programs would not last into the
twenty-first century. In hindsight, it seems these people should
have known better, but they were trying to perform a service to
their management by conserving expensive disk and computer
memory. Adding two century digits to a date field for a 100-
million record file would have added at least 100 megabytes of
storage requirement to a disk that cost upwards of $20,000 for
15-20 megabytes. It made economic sense to lop off the two
century digits.

Now, the industry faces the problem of adding those two century
digits back into the date field in order to keep software running
and producing correct output. The problem, however, is not
isolated to software. Hardware will also cause difficulties for
system administrators and chief information officers. System
clocks on virtually every personal computer will wind up with
corrupted dates on January 1, 2000.

In some cases, the date will appear to roll over to the correct
date, but when the machine is turned off and then back on for the
next session, an odd date will have taken its place. It may
appear as January 1, 1980; January 4, 1980; January 1, %000; or
some other combination of characters, all of which will produce
erroneous results. The dilemma is not limited to personal
computers. Some workstations, minicomputers, mainframes,
elevators, and automobile central computers will fall victim to
the insidious problem. In most cases, software patches can
alleviate the problem to a more-or-less livable extent, but in
some cases, the date issue can be resolved only by replacing the
hardware.

In software, the problem will be most visible in sorting routines
that sort on two-digit year fields. Storing 1999 as 99 and 2000
as 00 will cause the 00 date fields to sort out before the 99
date fields. The consequences of this action can be determined
only after the context of its use is understood. Additional
difficulties will crop up, and already have.

In one case, a bank's irreplaceable backup tapes were almost used
as scratch tapes when a mainframe operator discovered the
discrepancy and pulled them from the scratch tape bin. The
problem came from the tape management software's use of the date
"00/00/00" as the scratch tape indicator in the tape label
retention date field. In 1995, tape backups were made with a
retention date of December 31, 2000, which was stored in the tape
header as "12/31/00." The tape management software looked at
only the year portion of the retention date and decided that they
had been around long enough. Thank goodness for the observant
operator!

Year 2000 horror stories abound, all with the same lesson to be
learned. Hopefully, senior executives and chief information
officers will realize the severity of the problem and take
preventive action. Unfortunately, the solution is expensive and
labor-intensive, but there is hope and experience from those who
have already taken corrective measures.

What Organizations Can Do About the Problem
William M. Ulrich, in Application Development Trends' February
1996 issue, describes the essential elements of a strategy for
assisting organizations in solving the year 2000 problem. These
elements include:

 performing an enterprise-wide assessment of the extent of
the problem;

 assessing the infrastructure in place and additional
requirements to support any new functions associated with
the solution;

 deploying strategies for solutions;

 defining validation strategies for testing modifications and
assessing the compliance of new software to standards; and

 detailing budgeting strategies.


Foremost in deciding what to do is estimating the extent of the
problem. For software, the Gartner Group estimates that it will
cost between $0.50 and $1 or more per line of executable code to
analyze, modify, and test the software. Organizations in general
have found that 1-2 percent of code will be affected and will
have to be modified, but all of the code must be analyzed to make
this determination. Estimates translate into one staff-year per
100,000 lines of code! Some organizations, such as banks, may
have as many as 10 million lines of code with a higher affected
rate than organizations that use information technology to keep
accounts, mailing lists, personnel records, etc. This translates
into 100 staff-years of effort.

Time is of the Essence
Once the extent of the problem has been defined, organizations
need to formulate a time frame for corrective action and start
the process as soon as possible. All of the work should be done
before the start of the year 1999 in order to have a sufficient
shakedown period for testing changes. With only 220 effective
workdays per year (after two weeks of vacation, holidays, and
sick leave are factored out), approximately 600 workdays remain
until the end of the year 1998. One hundred staff-years over 600
days requires at least 35 persons working on the problem full-
time. A large organization may spend between $5 million and $10
million on corrective action. The Gartner Group estimates that
Fortune 500 companies will spend between $10 million and $40
million each. Worldwide, the figure is $300-600 billion.

Table 1 presents statistics collected over the last six months
from various messages and notices on the World Wide Web (WWW).
While not rigorously measured, these figures give an indication
of what others have found in trying to deal with the enormity of
the problem. The average from this information is that 167,000
lines of code per staff-year can be analyzed, modified, and
tested. The scope of the problem for individual organizations
can be bounded using a ballpark estimating factor between 100,000
and 167,000 lines of code per staff-year.

Table 1. Size and Effort Estimates

Comments Lines of Code Estimated
Staff-hours

Manufacturing system 1,200,000 2,000
Commercial off-the-shelf
(source code was available) 2,000,000 2,500
2,000 programs 7,000,000 38,000
Retail system 7,500,000 75,000
401K system 1,300,000 9,000
7,000 COBOL programs (83% were
affected) 12,000,000 200,000
---------- -------
TOTAL 31,000,000 326,500
========== =======


A Plan of Action
The most reasonable solution is to attack the problem one step at
a time. A suggested means of planning for the work may include
the following steps:

 Select a product to assist in managing the inventory of
software and databases involved. Select one or more
products to assist in analyzing the software and estimating
the extent of the problem. Some of these products will also
modify the software and data automatically, but cannot do so
for every case. (Some computations are date-related, but
cannot be determined from the source code. In such cases,
an individual must analyze the source code line by line.)

 Inventory applications, libraries, databases, extraneous
files, documentation, and other items that have importance
within specific systems. Identify who is responsible for
each item.

 Analyze the applications and data. Estimate modifying the
source code alone to change those locations that perform
date computations and logic operations based on dates.
Perform a second estimation that includes modifying
databases and all source code that references data fields
and all source code affected in the first estimate. If
there is an insignificant difference between the two
estimates, the recommended course of action is to modify
both the databases and the source code. It may be less
expensive in the short run to modify only the source code,
but more expensive in the long run if maintenance problems
crop up over time due to the date processing fixes.

 Assemble a team of programmers, application experts,
database designers, and project management based on the
overall system requirements. Once estimates are known, the
number of personnel required can be determined, particularly
in view of the automated tools selected for use.

 Modify the system. Three major options are: a) modify the
source code to manipulate and perform computations on dates
with century digits included; b) use a sliding window time
frame to determine date context for computations; and c)
incorporate packed date fields and use specialized
subroutines for performing the computations. All three of
these are expensive and may lead to further maintenance
problems in the long run.

 Test the modifications. Allow 40-50 percent of the overall
project resources for testing, even more if the database is
modified. This includes testing documentation to ensure that
directions are correct and correspond to the changes made.

Sources of Help for Dealing with the Problem
The major obstacles in succeeding with a year 2000 problem are:

 getting executive management to acknowledge the problem and
take serious action;

 finding the right suite of tools to assist in the conversion
process; and

 enlisting the help of knowledgeable professionals.

Executive management must be made aware of the problem and its
severity before anything can be done about it. The problem is a
show-stopper. The solution will consume lots of resources. How
does one go about telling management that the organization must
invest large amounts of time and money into a project that will
allow the organization to continue business as usual? There will
be no added value or improved productivity; management will gain
only the knowledge that on January 1, 2000, the organization may
not have to go out of business.

Professionals in the field can describe in much finer detail the
consequences of ignoring the problem. Past naysayers have become
proselytes once confronted with their own ignorance of the
problem. Peter de Jager, a Toronto-based consultant and
motivational speaker, has numerous anecdotes and statistics that
he uses to help organizational management "see the light." He
has been speaking on the year 2000 problem for ten years and
publishes some of his work on the WWW at URL
"http://www.year2000.com/" where he has established the Year 2000
Information Center. Under his
"http://www.year2000.com/links.html" index are links to other
articles and publications on the year 2000 phenomenon.

Vendors, consultants, products, and services* are available
through de Jager's home page. Brochures on specific products and
their capabilities are available through WWW links at the Year
2000 Information Center. A great deal of technical expertise and
discussion can be found on the Year 2000 discussion group
administered by de Jager. Membership can be obtained simply by
sending electronic mail to listmanager@hookup.net with the
message "SUBSCRIBE YEAR2000" (without the enclosing quotation
marks) in the body of the message (not in the subject line).

For federal organizations, the Federal Information Resources
Management Policy Council (FIRMPOC) has a work group in place to
identify issues and recommend actions concerning the year 2000
problem. Kathy Adams (410-965-6294, kathy.adams@ssa.gov) of the
Social Security Administration in Baltimore, Maryland, chairs the
group. The group provides agencies with a definition of year
2000 compliance and issues a recommendation on contract wording
to that effect. The Office of Management and Budget (Ed
Springer, 202-395-3562, springer_e@a1.eop.gov) has also taken an
active interest in the year 2000 problem.

Conclusion
Organizations that recognize the impact of the year 2000 problem
and take action to remedy it will have a distinct advantage over
those that do little or nothing. It is a severe, immense
problem, and all anyone can do is plan for its solution. It will
not go away and it will most assuredly make itself known on
January 1, 2000.


*Mention of any product, service, company, or individual at this
source does not constitute a recommendation or endorsement,
explicit or implicit, intentional or implied, by the National
Institute of Standards and Technology.
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close