The University Record, October 21, 1998
Millennium Bug: Much still to be done, Griffiths says
By Jane R. Elgass
The good news is that a great deal has been accomplished. The bad news is that a great deal remains to be done before the University is ready to face 12:01 a.m. on Jan. 1, 2000, and potential problems with the Millennium Bug, also referred to as the Year 2000 (Y2K) problem, Jose-Marie Griffiths told the Regents at their meeting last week.
As the university chief information officer and executive director of the Information Technology Division, Griffiths is spearheading campuswide efforts to make certain that the University’s systems, from e-mail to water for steam at the power plant to elevators at University Hospital, will be able to function properly at that magical moment.
Some software assumes that the first two digits of a year are “19” and uses a two-digit number instead of a four-digit number. For example, “89” represents “1989.” This becomes a problem when the century changes and the software recognizes the year “00” as “1900” instead of “2000.”
Projects to assess the current state of the University’s systems and identify those that need correction have been under way for some time in four major areas: software applications, operating systems, data archives and programs embedded in hardware, such as elevators.
Griffiths said that the U-M’s central systems are pretty well on the way to being compliant, with some undergoing testing now and others scheduled for testing in 1999. The focus now is moving to the rest of campus.
During the summer, 103 assessments were received from 36 units. Assessment work is continuing in several other areas, including:
• Research. About one-third of this area has been covered as many researchers were not on campus during the summer.
• Third-party software, particularly that which must interface with the PeopleSoft software on which the M-Pathways project is based.
• Data Systems Center. Assessments in this area uncovered 600 programs developed with unit funding but held centrally, Griffiths said. Units are being notified about programs that belong to them and asked if they are still relevant and need analysis for possible reworking. While the number of programs is high, Griffiths is pleased that the system being used to identify potential problems worked. “It’s likely these could have fallen through the cracks,” she said.
• The Health System has pretty much identified problems in its central systems, but not in distributed systems, what sits on people’s desktops. There also is a concern about building systems, especially at remote sites.
• Other areas that require additional work include equipment at the Medical School, power distribution, student organization offices in the Michigan Union, an old laboratory at the School of Dentistry and fire alarm systems.
Griffiths said that one of the most time-consuming projects now under way is analyzing the tests that people have run to determine if the fixes really work. “1999 will be devoted almost exclusively to testing.”
Griffiths also noted that many units and individuals on campus are uncertain about what will be handled centrally and what must be done by them or their units. She has asked central units to identify what they will handle as a means of “trying to minimize panic.”
These central units include Plant Operations, Purchasing, the Information Technology Division and Medical Center Information Technology, as well as campuswide and local area networks.
For the most part, many of the areas that need work have been identified, Griffiths said. She noted that the University is most vulnerable in “dependencies on external suppliers.” These are most evident at the Health System, which depends on the American Red Cross, pharmaceutical companies and the federal government (for such things as Medicare payments).
In addition, the student systems at the Medical School and the business office and ticket office at the Athletic Department require solutions.
Work done to this point, Griffiths observed, has focused on specific computers and systems. That is now shifting to broader issues, such as the critical worst case scenario, which would be something that could threaten life.
“We are preparing contingency plans to address that,” she said. “We will have a backup and recovery plan for the entire University that will include phasing in and out alternate sources if necessary. Critical to that is identification of the human resources we will need to have at hand on Jan. 1, 2000. We intend to have the plan in place by June 30, 1999.”
Areas that need further assessment and analysis include things the University might make available as a result of research projects (are they required to be Y2K-compliant), whether our insurance policies cover liabilities if any system should fail, and the University’s cash position on Jan. 1, 2000.
Next steps in the overall process include:
• Continuing identification and elimination of problems.
• Providing information to the University community, such as advising students who will be here in 2000 to not bring non-compliant equipment.
• Extensive testing, both remediation—testing of a new code written to take care of the problem—and integration testing—testing systems end-to-end, testing products in the context in which they are used.
The main point of this massive effort, Griffiths concluded, “is to not have a critical problem.”
You can always drop us a line: [email protected].
