Member Views

Opinions of UniForum Members

Year 2000: Disaster or Mere Annoyance?

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:

IF (TESTDATE < 1930)

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