Y2K Problems, Issues, and Solutions

Short List of affected hardware: switching routers, routers, switches,
hubs, workstations, PDAs, NICs, servers, csu/dsu, modems, transceivers,
print servers, VCRs, video equipment, facility equipment....

Short list of affected vendors: Cabletron, Cisco, Dell,  SUN, Apple,
Datatel, Novell, 3Com, Dec, Octel, SCT, Packard Bell, Compaq, Gateway,
HP, Intel, Lantronix, NEC, Lucent, Allied, Lexmark, IBM, Oracle, Ardent,
Meridian, Nortel, US West, GTE...

The group brainstormed on possible approaches to preparing for the Y2K
change:

* Implement and keep current vendor patches
* Periodically visit vendor and Y2K national Web Pages
* Develop "Contingency -- spare hardware" possibly through regional or
state groups
* Prepare test methodologies for your campus
* Implement random date change tests
* Implement rollover dates change tests
* Implement leap year change tests
* varied C systems
* Implement or communicate support policies -- should we support only
current version minus 1 of all software?  Are there implications for
hardware replacement in order to stay current?
* Identify purchase order compliancy requirements statements
* Can NW-HEAT develop a Web page with links addressing some Y2K issues?
* Develop plans to educate customers


There was opinion that vendors, such as SUN, Dell, Apple, Datatel,
Intel, Novell, Gateway, are providing adequate information on Y2K
compliance.  Some disagreed, feeling that, for example, Novell is not
addressing the issue well and are moving to NT perhaps for a variety of
reasons.

There was discussion on the list of affected hardware and some feeling
that we cannot address issues on all systems.  Hence, determining what
systems are critical or of most importance may need to be made by each
campus.  Additionally,  vendor solutions to the Y2K issues may not be
absolute and complete.  Are we confident that vendors will address the
issues?  What are reasonable expectations for vendors to provide and
when should they provide it?  For some systems solutions are critical
along with substantial lead-time and testing to ensure that systems work
as expected when the date rolls over. What expectations do our campuses
have for backups prior to rollover? Have we prioritized risks?  When do
we plan to test and re-test vendor solutions? How do we prioritize which
systems are critical? (Pcs, Pcs-vs-servers, applications vs major
software, network components vs critical central network routers?)

Action Items
* Shall NW-Heat prepare a collection of links to vendor pages?  Are
there checklists, which can be shared with the group over the Web?
* We should share, through the nw-heat  email list, our experiences,
problems, and changes
* Shall we list our varied testing results to date?

Suggestions for Individual Campuses
* Leverage FEAR and UNCERTAINTY
* Prioritize risks
* Share test information on hardware and software  (RETEST)
* Prepare clear policies on what is/is not reasonable
* Document -- what we have -- link resources
* Share actual rollover plans for test/verify Dec 31/Jan
* Ensure adequate backup prior to rollover