Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!rice!uw-beaver!ubc-cs!unixg.ubc.ca!gauguin.ucs.ubc.ca!hilchey
From: hilchey@ucs.ubc.ca (Paul Hilchey)
Newsgroups: comp.sys.sgi
Subject: Re: ELM on Iris
Keywords: elm, flock, nfs
Message-ID: <1991Feb28.231411.28094@unixg.ubc.ca>
Date: 28 Feb 91 23:14:11 GMT
References: <9102272300.AA05961@fred>
Sender: news@unixg.ubc.ca (Usenet News Maintenance)
Reply-To: hilchey@ucs.ubc.ca (Paul Hilchey)
Organization: University of British Columbia
Lines: 32

In article <9102272300.AA05961@fred>, shc@fred.UUCP (Steve Couturie) writes:

|> 
|> OK:  To make ELM 2.3 Patch 11 work on Iris 4D:
|> 
|> Do the Configure.
|> 
|> Edit config.sh:
|> 
|> 	d_vfork='undef'		vfork causes ELM to fail to make locks
|> 	d_flock='define'	Sets locking style:  This works for me.
|> 	d_flockonly='undef'		ditto

I ran in to some weird problems with elm that I traced back to flock,
so I would recommend you use
	d_flock='undef'

The problem showed up in a cluster of machines with shared mail spool and
home directories.  I never did track down exactly what was happening, but after
running elm you could wind up not being able to read (using cat, for example)
all of your mailbox.  From some machines you could only read the portion of the
file that existed prior to running elm.  From the machine where you ran
elm, though, you could read all of the file, and ls reported the correct
file size from all machines.  Elm does a stat on the mailbox and is 
unhappy if it can't read as many bytes as are supposed to be there.

This was with Irix 3.3.1.

______
Paul Hilchey
University Computing Services
The University of British Columbia