Archives
What's New
Site Map
Subscriptions

Home
NetFlash
This Week
Forums
Reviews/buyer's guides
Net Resources
Industry/Stocks
Careers
Seminars and Events
Product Demos/Evals
Audio Primers

IntraNet



Error 404--Not Found

Error 404--Not Found

From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.


















For more info:

Sounding the net alarm on year 2000 problems Year 2000 specialist Karl Feidler warns that client/server apps are at risk. Network World, 7/28/97.

Y2K Information Center
Large collection of Y2K links and resources.

Back to the Buzz issue

The Buzz
Year 2000: It's a network problem, too

By Charles Bruno
Network World, 9/29/97

Mike Kilbane doesn't yet know where he'll spend New Year's Eve 1999, but he's plugging away at a complex problem that may well force him to sweat the final seconds of the millennium at work.

Kilbane is year 2000 project manager at Ingram Entertainment, Inc., a national distributor of video entertainment products. His mission over the next two years is to "make sure the year 2000 bug is a hiccup and not a terrible crash,'' he says.

Unlike many IT executives who are focusing mainly on the effect of the year 2000 problem on mainframe applications, Kilbane also is investigating its impact on client/server and LAN-based applications. Kilbane, who chairs the Tennessee Y2K User Group, knows something many of his IT colleagues have yet to learn: The year 2000 bug (also know as the millennium bug) will sink its tentacles deep into enterprise networks.

Whether by distraction or fear, many IT organizations have yet to probe into just how the year 2000 bug will affect their voice and data networks. Out of 31 year 2000 user groups contacted by Network World, only three have begun examining the effects of the year 2000 bug on networks. Gartner Group, Inc., a Stamford, Conn.-based consultancy, estimates half of all companies affected by the year 2000 issue will not be ready by Dec. 31, 1999.

"People are making a big mistake thinking this is only a mainframe problem,'' says Tim Chou, chief operating officer of Reasoning Corp., a Palo Alto, Calif., purveyor of year 2000 software.

Indeed, as the clock ticks, date- and time-stamp operations chug away inside scores of voice and data network products.

Interoperability

When it comes to networks, perhaps the single greatest year 2000-related issue is one few vendors will speak publicly about: interoperability among different brands of products. That's the issue that tops Kilbane's list of concerns.

"It's one thing to come out and say you've made a single piece of equipment year 2000 - compliant,'' he says. "But the real crux is to ensure that product will work with other gear.''

If you have a hub or router from vendor X and a network management system from vendor Y, each may be independently compliant, but "vendors aren't doing any interoperability testing between them," Kilbane says.

A key concern is the interchange of data, according to Dan Miech, year 2000 product manager at Terasys, Inc., a Naperville, Ill., consulting firm. Because there is a high degree of data sharing between a midrange or high-end host and downstream clients, you need to ensure the date-windowing techniques employed on the mainframe side of the house mesh with the date fixes implemented on the client side. "If the server and the host interpret '00' as two different dates, you'll wind up with data matched to wrong dates,'' Miech says.

That plays into client/server applications. If a company supports a link between an AS/400 host and downstream Lotus Development Corp. Notes clients, Miech says, any Notes macros tied to the AS/400 will fail if they are not made year 2000-compliant.

PBXs and voice gear

The buzz on the street is that PBX systems and related voice gear may be hit hardest by the year 2000 bug. Even so, Bob Gabriel, senior network engineering specialist at Cornell University, isn't too worried.

Gabriel knows the Lucent Technologies, Inc. Definity switches that support more than 17,000 lines on campus are year 2000-compliant. "We don't expect to lose functionality at all,'' Gabriel says.

Yet industry observers caution that PBXs are prone to year 2000 complications. While most admit that switches aren't likely to lose dial tone and will continue to provide call processing as the new century kicks off, they caution that important adjunct function-ality may be lost.

Services such as time of day or day of week routing and station management detail reports - the lifeblood of bill-back systems - may be rendered inoperative by the year 2000 bug.

Voice response systems and automated call distributors are heavily dependent on date and time stamps. They likely will become confused as the date rolls over to 2000, according to Art Schoeller, research director for voice call processing at Gartner Group.

Because software scripts rule voice response systems, you need to examine the coding for date-related operations, especially for messages directed at the public, Schoeller says. "I'd hate to see calls destined for a live staff go to a recorded announcement that advises callers to try back tomorrow,'' he says.

Similarly, intelligent voice response systems depend on interaction with host applications. While a host programmer may have done the due diligence to correct year 2000 issues, if they forget to update the interactive voice response code, Schoeller says the system may feed incorrect data to callers.

On the voice mail side, systems that rely on message indexing often rely on date stamps to sort messages. If that isn't addressed, messages may be incorrectly sorted or deemed old and automatically deleted.

Messaging systems

E-mail products are likewise driven in large measure by date and time stamps. Come the turn of the century, you could log on to find messages deleted or purged because the software thinks their shelf life has expired, says Daniel Blum, a principal at Rapport Communication, a consulting firm in Silver Spring, Md.

Systems administration will be hit hardest. You may encounter a host of problems: Your oldest messages may post first, and you'll have to scroll to ferret out the new ones. The system may reject new messages with a date it thinks has long since expired. On Jan. 1, 2000, you could lose messages from a day earlier because the system thinks they're 100 years old.

Messaging utilities effectively may be rendered useless, says Joyce Graff, research director of electronic messaging at Gartner Group. Message tracing, tracking and measurement tools are at risk, Graff says.

Mail passing from LANs to IBM host systems may run into problems because most gateways autoregister Internet IDs and assign them Professional Office System IDs every 90 days or so, Blum says. "You won't be able to get through the gateway since the autoregistration info will time-out,'' he says.

PC servers and workstations

Potentially, the single greatest area of impact for the year 2000 bug is the hundreds and thousands of servers and downstream clients that sit on LANs companywide.

Why? One word: BIOS. The Basic Input Output System initializes PC workstations and servers, setting up the system date and time by reading values according to a real-time clock chip that keeps constant time for the PC. If BIOS does not successfully roll over to 2000, all date and time references will be invalid, according to Karl Fielder, CEO of the year 2000 consultancy Greenwich Mean Time, Ltd.

Greenwich Mean Time found that 93% of 1996 and pre-1996 BIOSes do not roll over successfully to 2000 or take into account that 2000 is a leap year. BIOSes created after 1996 fare a bit better - only 47% do not roll over to 2000.

In fact, many PC-based systems roll back to 1980 - the PC's birth date from which many BIOSes sprang forth. Some older systems do not allow entry of dates greater than 12/31/99.

Compounding matters, the PC or server system date can be injected into a network operating system (NOS) or nested within client/server applications that happen to tap the PC for date information, says Jay Reischl, a vice president at Double E Computer Systems, an Omaha, Neb., network integrator. So the potential is enormous for infecting your network applications with false date information.

But even before you commit to fixing system BIOSes, Reischl says you have to consider the impact false BIOS dates have on other LAN components. LAN-based applications also may be affected by the year 2000 bug. And if they, too, need an upgrade, you may be facing the need for a quantum leap in memory or even a push to the next fastest hardware platform - just to satisfy the application upgrade requirements.

Network operating systems

NOSes are intertwined with the PC BIOS issue in their ability to roll over system dates success-fully to the year 2000. Because some NOS clients connect back to the server on boot-up for their time and date synchronization, they are highly reliant on the server hardware platform's ability to provide correct date information.

Ross Wilson, logistics planner for the year 2000 project at the Church of Jesus Christ of Latter-day Saints in Salt Lake City, says his organization's Novell, Inc. NetWare client workstations synchronize their internal clocks with NetWare servers as they log on. "If our servers get out of whack, so does everything else,'' he says.

Microsoft Corp. and Novell have committed to releasing year 2000-compliant versions of NT Server and NetWare. In Novell's case, the com-pany said a future point release of NetWare will be year 2000-compliant. That means an upgrade for users still plugging away with NetWare 3.X and early NetWare 4 versions.

NT Server and NetWare operate via their own file systems, so a fair amount of file and directory caching is based on dates that at present are not year 2000-compliant. Internal functions such as security (specifically assigning user rights) rely heavily on NOS dates, and they need to be evaluated for year 2000 date rollover, says Steve Smith, director of enterprise technology at Terasys, Inc., a systems integrator specializing in NT Server and NetWare.

Moreover, because NOSes such as NetWare roll dates out to downstream clients upon boot-up, LAN administrators need contingency plans for network resident applications that pull their dates from the PC BIOS instead of the server, Double E's Reischl says. And don't forget to check how executables such as NetWare Loadable Modules and specialized backup programs for NetWare pull date information.

Terasys' Smith says companies also have to examine a whole battery of homegrown LAN applications developed with products such as Microsoft Access or Lotus Notes. Every homegrown application pulls dates from NOS or client workstations. If these applications aren't checked, companies may "lose important applications that have become the lifeblood of operations,'' Smith says.

Routers, switches and hubs

There's good news - and bad - for shops that rely on multiprotocol routers or ATM switches to anchor their enterprise networks. These devices mostly will be spared the mayhem created by the year 2000 bug. But they're not totally exempt.

Routers and switches do not use date stamps to process data, so they are expected to remain operational at the turn of the century. But routers that synchronize their operations with like devices via a network time server may run into a snag, according to Wilson.

Routers and switches do time-stamp net management alerts, and any misplaced dates may result in error messages being purged because the device considers them out of date. Or element management systems and error logs could fill up with error messages from routers or switches that generate alerts with bad dates.

Words of wisdom

The recurring theme of solving year 2000 problems is testing, but there are other tricks.

Mike Tercy, director of the Federal Defense Business Unit at GMSI, Inc., a network integrator that is the guardian of the Penta-gon's year 2000 testing efforts, says you should press vendors for year 2000-compliant products by the end of 1998. That gives you ample time to integrate patches, test them in your environment and work out any kinks with suppliers.

Carl Schultz, a senior network engineer with GMSI, says you should leverage your maintenance contract renewals with vendors to ensure free upgrades to year 2000-compliant offerings.

Other experts suggest networking with year 2000 user groups so you can bounce ideas and problems off peers at other companies.

Whatever you do, start early, says Ingram Entertainment's Kilbane. "We've got two years to fix this,'' Kilbane says. "Let's dive in and get it done.''


Feedback | Network World, Inc. | Sponsor index
How to Advertise | Copyright

Home | NetFlash | This Week | Industry/Stocks
Buyer's Guides/Tests | Net Resources | Opinions | Careers
Seminars & Events | Product Demos/Info
Audio Primers | IntraNet

ÿ