From: Danny van Loon. Subject: [IGSMAIL-31] Software KOSG GPS receiver Date: 27 JUN 1992 12:53:49 *********************************************************************** IGS Electronic Mail 29-JUN-1992 16:37:26 Message Number 31 *********************************************************************** ============================================================================== THIS FILE CONTAINS 2 MESSAGES ============================================================================== From: Danny van Loon. Subject: Software KOSG GPS receiver -------------------------- Since Wednesday 24 June 1992 the KOSG ROGUE SNR-8 GPS receiver is running the Meenix 7.00.1 and the CONAN 4.2 software. Regards, Danny van Loon. ============================================================================== From: Dr Peter Morgan Subject: DATE PROBLEMS FOR THE UNWARY ---------------------------- I saw this on the news as prob some of you too. It could be nasty but is not yet a problem in our work. > > Path: csc.canberra.edu.au!manuel!munnari.oz.au!spool.mu.edu!think.com!sdd.hp.com!swrinde!gatech!utkcs2!shuford From: shuford@cs.utk.edu (Richard Shuford) Newsgroups: vmsnet.networks.tcp-ip.cmu-tek,vmsnet.networks.misc,comp.mail.misc Subject: network disaster plan Summary: plan ahead Keywords: network, disaster, recovery Message-ID: Date: 21 Jun 92 04:58:15 GMT Article-I.D.: utkcs2.l48337INNkmu Expires: 7 Jul 1992 23:24:25 GMT Sender: shuford@cs.utk.edu Followup-To: vmsnet.networks.misc Organization: University of Tennessee, Knoxville--Dept. of Computer Science Lines: 50 NNTP-Posting-Host: duncan.cs.utk.edu > A few days ago, VAX/VMS computer systems running recent versions of > the CMU-Tek TCP/IP networking software experienced a systematic > failure triggered by the inexorable march of time: a date field > overflowed, and all TCP sessions would disconnect immediately after > establishment. > > The problem was first noticed in Japan, not too far from the > International Date Line, and the systematic failure marched west from > timezone to timezone. Some system administrators in the Western > Hemisphere did receive electronic-mail notification of the impending > problem, but only when the messages took a route that allowed delivery > to the doomed systems before the network connectivity was lost. > > There are at least two things that this event teaches: > > (1) Anybody who writes software that manipulates dates and times > must check all limit values and special cases, at the peril > of inadvertently creating a timebomb. > > (2) If interorganization network links are important to your site, > you are well advised to have a network disaster plan. > > - Think about how you can contact your network neighbors if > the network is unusable. You may know everybody's e-mail > address by heart, but do you know the telephone number to > call your neighbor at his office? At his home? > > - Do any provisions need to be made for local substitutes > of services that are normally obtained over the network? > This could be name services, weather reports, or lots of > things. > > - Think about how to cope with an extended period of network > downtime. Do you need a formulate a policy how long your > alternate mail-exchanger site should retain e-mail that has > been piling up for weeks? > > If you have one leased line through which all your traffic > with the outside world flows, it would be prudent to invent > some alternate emergency channel of communication. Maybe > you can get your unreachable neighbor to dump queued-up > mail and news to a magtape and hire a taxicab to carry it > to you. Or maybe you can dust off that old modem and set > up an emergency dial-up link. Once a year, amateur-radio > operators have a Field Day, when they test their equipment > under emergency conditions. Maybe you could arrange for > -- > ....Richard S. Shuford | "Food gained by fraud tastes sweet to a man, > ....shuford@cs.utk.edu | but he ends up with a mouth full of gravel." > ....BIX: richard | Proverbs 15:17 NIV > from Peter Morgan