Year 2000 Problem--Part II

Search for solutions with CCIT task force

Last time we learned about the scope and significance of the Year 2000 (Y2K) computer chip problem.

This time we'll search for solutions with the CCIT Year 2000 Task Force. Remember, not every Y2K problem has a solution yet. A deskstop by desktop search for the Y2K villain isn't feasible, so there are some things you'll need to do for yourself.

To recap, the Y2K problem will occur on Saturday, Jan. 1, 2000, when some computer programs will fail to operate, and others will return unexpected or incorrect results. It's a holiday weekend, of course, so unless you want to get jangled out of bed by a frantic weekend worker who can't get your computer system started, better start making some preparations now.

In early 1997, the Center for Computing and Information Technology (CCIT) established a task force to look for solutions relating to the Y2K problem. Among other things, this task force was to check CCIT-developed software for compliance and plan appropriate fixes, inventory all major systems for compliance issues, request vendor certification letters (they've already received several replies), identify hardware and programs that would have to be upgraded, assess potential costs and how to budget for them, and identify scheduling and testing issues.

It's especially this last item that could cause you problems. If you consider the Y2K dilemma to be a computer problem and decide to wait for the "computer people" to fix it, you could find yourself at the end of a very long line.

"We're doing everything we can. We've made this a priority and we've alerted all of our people. But let's face it, some people are not going to embrace the potential seriousness of the situation and will wait until the last minute," said Melissa Forinash, acting CIO of CCIT. "Your best bet is to get out in front of this for yourself. If you act soon, before the panic sets in, you're more likely to be prepared and to have solutions available."

Forinash suggests:

• Take a hard look at all your systems, not just your computer systems (barcoders, security systems, entrance passes, etc.). If these systems are date sensitive, they might be at risk for the Y2K problem.
• Test them; put 2000 or 1999 in a date field and see how the program reacts, see how it calculates. Also see how any other program that depends on this information reacts to these test dates.
• Note that old IBM-style computers in the 286, 386 and in some cases the 486 classes are Y2K problematic and will not work and must be replaced.
• Above all, if you aren't sure about your hardware or software, send an e-mail message to y2k-help@musc.edu. This way your request for help will reach the people most responsible for working on solutions. Christine Williamson, Client Support Manager for CCIT, said that a response would be made within a week.

Y2K Task Force members include: Steve Akins (chair), Duane DeWeese, Mitchelle Morrison, Gary Mingee, Mark Daniels, Alton Sheppard, Stan Porterfield, Nickie Kopacka, Linda Jarriel, and Melissa Forinash.

Some preliminary recommendations from the task force:

• Don't assume that because you have a vendor letter of certification that everything's fine. Still conduct your own tests.
• Incorporate Y2K changes and fixes with other projects÷If you know an upgrade is planned or a bug fix is coming, request that the vendor also include Y2K fixes. The kind of response you'll get will tell you a lot about how the vendor plans to handle the problem. For example, Oacis interface changes and planned expansion for the Electronic Medical Record will include Y2K updates.
• Budget. Y2K is going to cost you time and money. That's a fact. A few budgeting cycles is better than one. If you can't afford to replace all hardware at once, how about some this budget year and some next?