Path: utzoo!attcan!uunet!know!samsung!sol.ctr.columbia.edu!cica!iuvax!rutgers!mcnc!beguine!durham!robinson
From: robinson@durham.med.unc.edu (Gerard A. Robinson)
Newsgroups: comp.databases
Subject: Re: Use of INGRES in a SUN environmnet
Message-ID: <1099@beguine.UUCP>
Date: 19 Sep 90 01:44:21 GMT
References: <1990Sep17.150529.4468@cs.umu.se> <2132@charon.cwi.nl>
Sender: usenet@beguine.UUCP
Reply-To: robinson@uncmed.med.unc.edu (Gerard A. Robinson)
Organization: UNC-CH School of Medicine, Office of Information Systems
Lines: 18

>We expect to solve the problem by linking the corresponding
>client-specific netu-files; this may cause problems in case of
>parallel update of netu-information, but prefer this very small
>chance over the other apparent approaches:

I should have mentioned yesterday that we do already do this (link the
various client IILOGIN files together).  The issues with this are the
same with any unlocked file that gets read into memory,  the version
that writes it last is the "correct" one.  I.E. you should take steps
to make sure that the netu utility is run only on one system, and
that the net servers are restarted periodically in order to read in 
the new entries.  If you add a name on one system, then you add it only
there and it possibly can be overwritten by some other entry from some
other system.  (At least that's the way it seems to work, I'd dearly 
love for someone at INGRES to clarify this.)  If you update on a server
then the client doesn't see it until its iigcn and iigcc are restarted.

Gerard Robinson ... UNC-CH School of Medicine, Office of Information Systems