You think the Year 2000 issue is somebody else's problem, right?

You don't need to know about it because you're not the "computer person" in your department.

And you don't anticipate a problem because you've purchased new software and hardware, right?

Sorry! UB faculty and staff who haven't done a thing about the Year 2000 can no longer bury their heads in cybersand.

That was the message that was delivered last week to the Faculty Senate Executive Committee by Voldemar Innus, senior vice president for university services and chair of the Year 2000 steering committee.

"The Year 2000 date is not going to change. This is an issue everybody needs to look at now so that you can take time to address the issues," he noted.

Carolann Lazarus, UB information systems auditor, added: "People think this is a problem that's over a year away, but to do any of this, you need resources and time. If everyone in a department finds out they need to buy new, compliant software or hardware all at the same time, it will kill their budget."

Plus, she added, there have been rumors that some software vendors will be jacking up prices as the Year 2000 draws closer and stock may be limited.

Earlier this month, a Y2K steering committee and affiliated working groups were organized to find out just how much (or how little) university departments are doing to confront the Y2K issue.

The steering committee will manage and monitor the Year 2000 plan efforts, be responsible for ensuring that assessments and remediation are completed and make recommendations to UB's senior leadership.

A working group composed of hands-on coordinators representing all university departments will provide guidance and support to implement the Year 2000 plan and bring to the steering committee's attention issues that come up.

Subgroups dealing with awareness, a conference day, student support, inventory and assessment tools, and risk assessment are being named.

A "SWAT" team that will be available to handle unforeseen emergencies also is being created.

"We're still at the point where we don't know how badly we could be hit," said Lazarus.

Units across the university were notified in June of a timeline for Y2K compliance.

For a copy of the timeline and other important information on the Year 2000 problem, check out the UB Y2K Web site at http://www.wings.buffalo.edu/year2000. The site is updated often and includes new fix-it guidelines, as well as important links to information about compliance for specific products.

According to Innus, the problem can be divided into four major categories:

1- Institutionwide applications that are considered critical to UB's mission, such as budgeting, personnel, records and registration.

2- Applications developed and maintained in the individual academic/administrative areas on campus.

3- Vendor-provided software and hardware (off-the-shelf packages such as word processors and spreadsheets).

4- Embedded chips that reside in a variety of equipment that may or may not be IT-related, such as a chip in an elevator that tracks maintenance based on the date, medical or laboratory equipment, even VCRs.

"The first area we have addressed, by and large" said Innus, noting that the campus's transition seven years ago to an IBM system made these systems compliant.

The other three areas are those that remain of concern, he said.

"Things literally may not work on Jan. 1, 2000," said Innus.

And while it is perhaps difficult to imagine, systems as basic and pervasive as telephones could be among those that are affected, he said. In some cases, it may just be that the display on the telephone will simply read the wrong date. On the other hand, where the date is tied to the electronics of the phone, the whole system could fail, he said.

"When we do have failures in January 2000, our customers are not really going to care whether or not it's because it's part of a central or decentralized system," he said. "They will simply see it as an institutional failure."

Some units have completed their inventories and assessments of the types of systems that could be impacted, including how compliance can be achieved and how much time and money it will take to do so.

For the most part, units with systems that are supported by Computing and Information Technology are believed to be compliant or at least well into the process of assessment.

But there are many other types of systems in the university.

Innus noted that it is individual researchers in the university who are of highest concern.

"They're doing research with very specialized equipment and software and nobody except those individuals is in a position to do an assessment," he said.

In addition, servers and local area networks in individual departments are extremely difficult to assess in terms of compliance.

The Y2K working group will be working to identify an integrated method of conversion. There may be, for example, an advantage to sharing compliance software among departments that use the same programs.

Systems managers warn that even though some vendors may claim that their products are compliant, that may not always be true.

At recent meetings of the Y2K regional group, of which she is a member, Lazarus said participants discussed the fact that while Microsoft Excel and Access are described as compliant, certain specific functions of each package are not.

These are the kinds of idiosyncrasies that will surface, she noted, only when people begin to undertake the corrective actions on their systems, a step that the working group strongly recommends units should be actively involved in already.

Lazarus summed up why the Year 2000 problem is so mystifying.

"We won't really know exactly how we are going to be affected, until Jan. 1, 2000," she said.