Path: utzoo!utgpu!watserv1!watmath!att!rutgers!mailrus!uunet!mcsun!unido!mikros!mwtech!mecky!walter
From: walter@mecky.UUCP (Walter Mecky)
Newsgroups: comp.unix.i386
Subject: Re: Mail not delivered in MMDF Mail under SCO UNIX
Keywords: MMDF SCO-UNIX deliver
Message-ID: <705@mecky.UUCP>
Date: 21 Jul 90 01:46:58 GMT
References: <678@mecky.UUCP> <7590@gollum.twg.com>
Reply-To: walter@mecky.UUCP (Walter Mecky)
Organization: MIKROS Systemware, Buettelborn/W-Germany
Lines: 56

In article <7590@gollum.twg.com> david@twg.com (David S. Herron) writes:
< In article <678@mecky.UUCP> walter@mecky.UUCP (Walter Mecky) writes:
< >In the last few month, from time to time I missed some mail.
< >But I supposed it will be lost on the long way to my system.
< >By accident (I read an article here with "cleanque" dumping
< >core and tried it), I found some 50 mails from the last months
< >laying in the MMDF directory and not delivered to my users.
< ...
< All this is the way it is supposed to work..
< 
< This "lock problem" you mention is not a problem at all.  What would
< happen if you had two processes scribbling mail into your mailbox
< at once?  Why, confusion, that's what!  In order to avoid the confusion
< MMDF locks the mailbox while it's writing to it.  Similarly, the local
< channel gives up when it can't get the lock on the mailbox.  The way
< in which it gives up leaves the message in the queue directory.

It _would_ be no great problem, if the manual would mention it. But
in any case this is a bad dessign. Better would be an automatic waiting
of the local channel for the mailbox getting free. Best would be a 
queued access to the mailbox by a seperate process. Giving up by the
local channel should only be done when the next invokation looks for
undelivered messages.

< 
< The assumption is that you'll be running your system reasonably and
< have background deliver's doing the delivery.  
My assumption is that this should have been written in the manual.

< Good!  You read the manual and found the right way to run it!
No good! I missed mail over a period of some months and noticed it only
by accident. Then I read the manual and found a workaround. Better than
nothing, ok.

< >My workaround is to change the "mod=imm" to "mod=reg" in the mmdftailor
< >file for the local channel and run "deliver" as a background daemon. 
< You don't need to set mod=reg if you don't want to.  Doing so will only
< stop the immediate delivery attempt.  If you leave it as mod=imm then
< an immediate delivery attempt will happen and work frequently.  Leave
< the background deliver in the system and it'll catch everything that falls
< through the cracks.
Wrong in SCO UNIX! See the note to SLS 162, Page 4: "You cannot run a 
deliver -b on a channel that has mod=imm set for that channel ...This is
a known problem and will be fixed in a future release."

< <- David Herron, an MMDF weenie, <david@twg.com>
As a MMDF weenie you surely can tell us, if the following is no problem
too. If I send mail mail with

	mail user 

and log out immediatly when the shell prompt is displayed, the mail
is _not_ send. I suppose this error is caused by the hangup signal which
should be ignored in processes running asynchronesly.
-- 
Walter Mecky	[ walter@mecky.uucp	or  ...uunet!unido!mecky!walter ]