PF>
  > In this context -- the client code (which does no file i/o) would send a
  > message to the server, like "read next message",  or "write
  > message". The server,  being a separate process (perhaps on
  > a different PC) would process these messages from all
  > clients.  Since the server is the only process that has any
  > message files open,  it need not use any locking at all.
PF>

Although a well-designed server would have multiple service threads in
order to service multiple clients, and so would need some internal locking
and arbitration between threads.  Of course, since all contending threads
would be in the same process, much faster locking mechanisms than
DosSetFileLocks could be used.

I did try to design a messagebase server once.  The problem is that to do
it _right_ you still end up addressing many of the same coherency problems
for the multiple service threads that you would address if you had
multiple processes all accessing the messagebase directly with a DLL API.
On top of which you also have to design and implement the client-server
protocol.

PF>
  > This is _very_ efficient across a network, when file
  > locking is the other alternative.
PF>

And _that_ is the true advantage of a messagebase server.  All messagebase
file I/O is performed by the server process alone, so you don't encounter
the problems of distributed file access and locking over a LAN (OS/2 LAN
Server and Netware are pretty good at this, admittedly, but NFS is plain
awful); and you don't have the security and administrative headache of
making the messagebase directories visible to all client workstations, and
thereby risking an errant process (or user) deleting the entire database.

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.01