Recently we asked our readers whether their organizations foresee major IS impact from the Year 2000 date problem and what they are doing about it. Here's a representative sample of what they said.
This is a tremendous opportunity! While forcing
ourselves to crack open just about every legacy app we have, we can objectize
it (keep it, wrap it or rewrite it), clean house, redocument and in general
regain control of the legacy apps, which have been coasting for years. This
process can be one of the most efficient and effective ways to move onto
client/server, Web and Internet platforms.
Glenn Kapetansky
Chicago, IL
The Year 2000 date problem is of great concern.
We plan to resolve it by implementing SAP client/server solutions.
Mark Sakamoto
San Jose, CA
The pace at which most hardware and software go
through their life cycles these days will mean that it is unlikely that
most of us will still be using the same systems by the year 2000. As we
get closer to that date, manufacturers will take it into account. By what
I see from credit card expiration dates, mortgage planning, etc., the vast
majority of financial institutions have already covered this ground in their
information systems. I expect most others have as well by now.
David Ingalz
Fremont, CA
Many organizations believe they still have three
or more years to work on this, which is a dangerous illusion. Many systems
have expiry dates as columns in tables, and these require next-century dates
for items such as contracts, mortgages and investment certificates almost
immediately. On the other hand, the cost to review, correct and test many
programs is being overestimated by some consultants as a scare tactic.
Yogi Schulz
Calgary, Alberta, Canada
Our company sells Year 2000 solutions. So far we
have found an almost "head-in-the-sand" attitude on the part of
many organizations, particularly the federal government. Some systems are
already crashing due to the inability of applications to address things
like a four-year contractual obligation that started this year. Starting
next year, the Year 2000 problem will impact any "long-term" planning
of more than two years.
John Keane
Springfield, MA
Currently, our distribution package is not Year
2000-compatible; we are looking at other application systems to replace
it. One item in our RFP is compatibility with the Year 2000.
Tony Kus
Milton, Ontario, Canada
Year 2000 is of great concern to our organization.
We are a state-owned utility. Our billing system will be seriously affected,
and our action-item tracking system will need modification. A major project
is now under way to totally rewrite the billing system and bring it from
an IDMS legacy system into a client/server Oracle environment.
Ben Ettlinger
White Plains, NY
Our organization is fairly new (about three years),
so we have already addressed this issue in the software that we sell (such
as dispatching technicians to fix problems for utilities) by storing all
of our dates in Julian format (for example, 19961024).
William Alber
Tampa, FL
The Year 2000 problem has been taken very seriously
by our company. Because our business runs on multiple operating systems--some
of which can be seriously affected by the problem--we established a formal
project with cross-functional staffing. The purpose of the team is to identify
all potential impact related to the Year 2000; make code corrections and
necessary hardware acquisitions; establish a test base and test team; and
thoroughly test all impacted code.
Bill Holt
Bellevue, WA
Our systems won't be affected, because they are
all based on relational database applications that use the "date"
and "datetime" data type. The real concern for us is how others'
systems will affect us (banks, financial institutions, etc.). We are ensuring
that all new applications have at least a four-digit year.
Tom Pratt
Seattle, WA
Most of our critical legacy systems will be affected
by the Year 2000. The problem begins next year, as we begin to accept students
with possible graduation dates beyond the year 1999. A solution has been
proposed, but no resources have been allocated toward it. We have determined
that the next version of our system adequately deals with the problem, and
are ready to convert to the newer version when resources are available.
Carl M. Vigil
San Jose, CA
Much work has been done to address the century issue
on the mainframe, but little attention has been given to the client/server
systems. I hope there are initiatives (I am not aware of any) in the upper
echelons to address these systems, because from a perspective of sheer numbers
and total utilization, they outweigh the mainframe environment.
William Potter
Birmingham, AL
We completed our conversion to four-digit years
just over a year ago. It was part of a larger project started in late 1993
to convert our information systems from one platform to an open systems
platform. We will be doing belts-and-braces testing next year by running
a trial 1999 end-of-year on our disaster recovery system.
Richard Shorter
Auckland, New Zealand
At Stanford University, a Year 2000 committee was formed in 1993. A huge number of items needed to be addressed, and these are slowly being taken care of either by modifying programs, data, screens or procedures, or by rewriting or replacing various applications. Dealing correctly with Year 2000 issues is a requirement of all replaced systems.
Undoubtedly there will be unexpected consequences, but hopefully we won't
be damaged as badly because of good advance planning.
Bill Bauriedel
Stanford, CA
We have resolved almost all the Year 2000 issues
with our internal software and through programming policy covering any software
currently under development. What concerns us are various third-party programs
and utilities to which we do not have access to the source code. We just
know that some program (probably on our CEO's laptop) crucial to the business
function will not be ready for the millennium.
Alan Spindel
Memphis, TN
All of our software was rewritten years ago to prepare
for Year 2000. We now keep a printable ASCII pair that represents the full
year (2010) in the 2-byte field that used to have the "96" part
of the year. We did have to find and fix a lot of date issues, but now everything
uses one callable module that has all sorts of date functions.
Charlie Lawrence
Anaheim, CA
The client that I am currently consulting with is a medical malpractice insurer who will begin to face Year 2000 problems after December 1997 (insurance companies have business and insurance maturation projections into the future). The client decided that investing money in their current system to make it Year 2000-compliant was not a wise choice due to the age, complexity and inflexibility of the mainframe-centric system. They saw their Year 2000 problem as the opportunity and justification to migrate to a new client/server-based system and solve the date problem at the same time.
They decided on a package and are now in the process of customizing it
to meet their specific needs. They plan to be done with software development
by July 1, which will leave them with five months to roll out the new system
before Year 2000 problems surface.
John Matise
San Francisco, CA
In my organization, we have a truly database-driven
environment. The applications do not contain old hard-coded program code.
Lillianne Dykstra
Palo Alto, CA
We are upgrading office software to suites whose vendors claim to have addressed the problem. Any pervasive problem such as Year 2000 is a big concern. Future problems with delayed--but hidden--impact are also a problem. Some software uses an algorithm to relocate the problem somewhere else within a century. This example relocates the two-digit problem to the year 2030:
GETDATE(TWODIGITS)
TESTDATE = TWODIGITS + 1900
IF (TESTDATE < 1930)
THEN TESTDATE = TESTDATE + 100
RETURN(TESTDATE)
We are trying to inventory all software to determine the useful life
of the underlying code and cataloging critical issues that affect the useful
life. This includes a variety of operating systems, control systems and
databases.
Steven J. Hathaway
Salem, OR
Our organization has converted approximately 80 percent of our date fields to use a four-digit year, and the remaining 20 percent will be converted by 1998. The bulk of our application is written in Cobol, making it necessary to rewrite the static record definitions and then convert the files.
Unfortunately, another legacy accounting application will become defunct
as of Jan. 1, 2000. We do not currently have the source code, so we cannot
alter the file definitions. Being that the application is no longer supported
by the vendor, we do not expect to be able to use the application after
Dec. 31, 1999.
Michael S. Cross
San Mateo, CA
I'm so busy treading water and trying to get everything
accomplished now that if I have the Year 2000 problem to deal with,
it will be a welcome indication of longevity!
Kevin Montgomery
Burlingame, CA