Well, another holiday season is over and as I recover I tried to remember my most memorable New Year’s Eve celebrations. Most I can’t remember. Maybe it’s old age kicking in, maybe it’s for a lack of doing anything exciting, or maybe it’s the alcohol effects. One very distinct memory is that of the year 1999 bringing in 2000.
Besides the arrival of a new century, there were many predictions of doom and gloom. The most feared was the impact of computer systems being able to handle the double zero year as they rolled over to year 2000 (Y2K). Working in the computer software industry I was particularly motivated and excited for this NYE party. However, the party at our company was spent at work waiting by the phones for any emergency calls. We had pizza and movies and video games to keep us entertained, and awake. Good thing too as we did not have any “emergency” calls. It’s still debatable as to why we didn’t have any calls.
Was the whole Y2K software scare was just a hoax? Or was the software industry just that well prepared? From experience, I know that the computer industry and IT departments had been preparing for years.
Learning the real testing challenge
I first learned of the software implications of Y2K in 1997. A customer of ours asked if we had anything specific for simulating the arrival of year 2000 with their computer applications. Being a software testing company we said sure, use our testing tools to change your test data to a year of 2000, run your tests and see. That’s when we got lambasted and “educated” by our customer. They simply couldn’t change all of the years to 2000 without impacting the application’s logic. For example, if every one of their customer’s birth year was changed to 2000, how old would everyone be? How does the application know what year it currently is? Doesn’t the computer clock itself have to be set to 2000 to pretend it is the New Year? How do we know where all of the dates are stored in our data files, and what format are they stored in?
Figure 1: One of the earliest slides I could find in my archives on the subject
A simple test suddenly became very complicated, and the clock was ticking. There were no easy answers or any automated software testing tools available. After many other customer interviews, architecture and prototype reviews and late night software development, we were ready to deliver our first release of software to find and change dates. The key was to change dates consistently by “aging” them consistently. For example making everyone’s birth dates two years, three months and 20 days older. This, combined with setting the computer systems date the same number of days older, allowed IT to simulate the application running after the Y2K roll over. Then the normal testing procedures of verifying the accuracy of the test results could be done.
Spreading the Word
We quickly found out that most companies had the same simplistic idea of testing for Y2K as we originally did. With less than three years until Y2K, we became educators and missionaries for the preparation effort.
I attended many software industry conventions to spread the word. At the 1997 IBM DB2 User’s Group (IDUG) conference in Miami, I was scheduled to present my “DB2 and Y2K” topic. The presentation was scheduled for Wednesday—the hour immediately following lunch. Not a good time for attendance expectations. After it rained the first three days of the conference, Wednesday morning was warm and sunny. A walk around the pool and beach at lunchtime dimmed my hopes of anyone attending as most of the conference attendees were enjoying the sun. Five minutes before the start of the presentation I stood in a conference room set to hold 200 people with one other person. Then it started raining; and not from the sky, it started raining people. The room soon filled to capacity. Most importantly, the DB2 product managers from IBM, the senior vice president of software development from IBM and one of the IBM DB2 software architects sat in the front row. Very scary!
I explained to the audience that many software applications, including DB2, store the year portion of dates as 2 digits in an effort to save on disk storage. So the year 1961 would be stored as 61. The application logic then assumes the century to be whatever the computer clock is set to. So in 1999, a person born in 1961 would be 39 years old. But in the year 2000, the person’s birth date would be 2061, or a negative 61 years old. Obviously, this could lead to the application not processing information correctly. The topic of my DB2 presentation was to inform where in DB2 this may be a problem. One example was how the date set in the DB2 system was used to know when to delete old data as part of a cleaning process. Because DB2 used a 2-digit year, data could be deleted mistakenly after Y2K. As I explained this, the IBM folks from the front row immediately informed me that there was a fix in the works and available soon. Great! We recorded this fix number for all of the attendees. By the end of the presentation there were a number of fix numbers provided. Not only did the attendees get valuable fix information from IBM, but they also got some insight into how to adjust application logic to avoid a major Y2K issue.
Solving the Issue
For most companies it was not possible to expand their stored dates to include the century in time for Y2K. So an alternative was to change the application logic to consider a pivot year. For example, a year that was before 60 was assumed to be a century of 19, and after is assumed to be 20. This would work for some dates and needed to be evaluated for each date and how the application uses it. The DB2 database fixes originally used this method for most of its dates. Many companies used different pivot years for different applications and stored dates depending on how the dates were processed. Both expanding the actual date values, and using pivot year logic were used, but both required a deep understanding of how applications used and processed stored dates. It also required knowing where all of the dates were stored.
The first task of many IT departments was a multi-step process: Build an inventory of their applications, determine how the applications used dates, determine how each application interacted with each other sharing data and understand physically how the dates were stored. In the late 1990’s most of these applications were legacy Mainframe applications. Most companies simply did not have a good understanding of, or documentation for, all of their applications. Even though not every application used dates, or would be impacted by Y2K, they needed to be evaluated. Even recognizing a stored date turned out to be difficult. Before inexpensive disk storage, and during the time of creative mainframe programmers bent on conserving space, dates were stored in very creative ways. By last count our data aging software accounted for 144 different ways a date could be stored.
So after spending $300-plus billion in preparation, what did the IT industry learn and benefit from this Y2K effort? One big side benefit from this effort is now most companies have a good understanding of how their many applications are interrelated and share data. With the explosion of new distributed computing architectures including mobile devices, this knowledge of legacy applications is required. These mainframe legacy applications still exist and will support new customer-facing applications and devices for a long time. With cheaper disk storage and databases now using more specific date and timestamp data types, we will probably not have to worry about expanding dates or another century rollover. However, there are a few other global IT projects to consider.
For example, this last holiday shopping season brought to light, again, another major global IT project: protecting sensitive customer data. This is probably an even larger effort with a greater economic impact to a company. I’m just glad I wasn’t at a year’s end pizza party fielding customer calls that night!
Jay Richards is a subject matter expert at Compuware. His primary job is assisting the Compuware products team in the sales and evolution of the Compuware APM tool set.