A report on electric utilities and the Year 2000 problem

by Steve Heller


Note: this is an old report. For the latest on TU's Y2K status, see the Texas Utilities Y2K information page.

Susan and I went to a meeting of the Dallas-Fort Worth Data Administration Management Association Year 2000 users group today (9/19/97). The main speaker was Bob Schuster, the system test manager for the Year 2000 Information Technology project at Texas Utilities (TU). He was accompanied by John Carrier, the Y2K program manager for TU, which is the holding company for a number of electric utilities.

His presentation was interesting on a number of counts:

  1. They are taking this situation very seriously and have a comprehensive plan for remediating and testing all of their business systems. The plan is well underway and they expect to be done by the end of next year, which allows all of 1999 for integration testing.

  2. They originally planned to divide all programs into two groups: "assumed compliant" and "assumed non-compliant". The programs in the former group were those written from scratch after all the databases and other tools they used were compliant. Unfortunately, they discovered that there weren't any programs that could be assumed to be compliant, because even those programs that used only compliant tools had been written in such a way that they weren't compliant. An example of the latter was that the underlying database uses 4-digit years, but the programmer copied the year value to a 2-digit field and then did date arithmetic with it. Therefore, they have to treat all programs as being non-compliant.

  3. They are going to be using windowing techniques (treating every two-digit year value xx from a certain year onward as meaning 19xx, and every two-digit date before that number as meaning 20xx). Although they recognize that it would be better to expand all the dates to use 4-digit years, they are taking this windowing approach because they have 66,000 files that contain two-digit year dates. If they were to expand the dates, they wouldn't be able to put the programs back in service as they were fixed, but would have to maintain two sets of programs and two sets of files until everything was done. They don't have enough resources to do that.

  4. This group will not be able to fix anything that isn't Y2K related. Any other errors found in the code will be thrown back to the development groups for fixing, because they don't have enough time to do that.

  5. They are not going to do any capacity testing to make sure that the programs will still be able to handle the load after making fixes to the year calculations, because they don't have enough time to do that.
But possibly the most interesting thing was what he did not mention: how they were doing with their embedded controller problems, which of course are the kinds of problems that would stop power from being produced or distributed. Here is a nearly verbatim rendition of the exchange that followed when I asked about this issue about half-way into the meeting:

Q: What are you doing about your embedded systems exposure?

A: We have just begun the assessment phase for our embedded systems exposure. Every piece of equipment that has a microprocessor in it will have to be tested and possibly fixed. We don't know how big a task this will be yet, because we haven't finished the assessment phase.

Q: But why didn't you start the embedded systems work first? What good will it do you if you get every business system fixed but you can't generate or distribute power?

A: We can't figure that out either.

To return to my main page, click here