Global Options:
  ~~~~~~~~~~~~~~~

CHAINQUICK:

  when  importing, build reply-chains quicker by only using 32-bit
CRCs  to  compare  MsgIDs.  This  involves  a  very  small risk of
creating false reply-chains.


SAVECOMMENTS:

  preserve comments when updating the "ums.config" file.


BETTERIMPORT:

  use  larger  buffers  for  writing. This is useful when UMS more
used  as  a  node  for routing messages between exporters than for
interactive use, e.g. by newsreading.


BETTEREXPORT:

  use  larger  buffers  for  reading.  Not that much useful. Speed
sequential exporting but harms interactive usage (newsreading) and
concurrent accesses.


SPARING:

  use  as  little RAM as possible without becoming too slow. Makes
BETTERIMPORT and BETTEREXPORT useless.


GREEDY:

  use more RAM overall.


NOADDBUFFERS:

  don't  use  AddBuffers().  Otherwise UMS tries to figure out how
many  file-extension-blocks  it will need on the FileSystem and to
AddBuffer()  missing  blocks.  NOADDBUFFERS  should  be enabled if
other filesystems than FFS are used for the MB.


NOCHECKHD:

  don't  try  to check space on FS. Neccessary when using RAM: for
the MB.


CHECKLINKS:

  perfect  data  structures integrity is essential for UMS' proper
operation.  This  option tells umsserver to check all its ".chain"
and  ".link" files on startup and somewhat repair deficiencies. 
  If  you  upset  your  MB by improperly terminating UMS before it
could  flush  its  buffers,  it will show several "too long" error
next   time.   In  this  checking  of  links  is  already  invoked
automatically,  so you don't usually need to use "CHECKLINKS". Use
this if you're afraid you corrupted your MB otherwise.


IMMEDIATEACTION:

  after  SOFTFLUSH  seconds  of  idle  time, ACTIONCOMMANDs can be
started  automatically. By default, UMS will start only one action
and  wait  another SOFTFLUSH seconds before starting the next one.
This  ensures  that  actions are only run when UMS isn't currently
needed  for  other  applications.  With  IMMEDIATEACTION, multiple
actions  are  started immedeatly after each other. In other words:
not  only  after  SOFTFLUSH  seconds  of idle time, but also after
termination  of another action one new action can be started. This
still  somewhat  avoids  to  spawn  a countless number of parallel
processes.  If  you _want_ multiple actions to run in parallel and
not be serialized, use the "run" command in an ACTIONCOMMAND.


CLOSEFILES:

  some  filesystems  (e.g. old 1.3-FFS) don't entirely flush their
buffers  when  asked to with dos.library/Flush(). In this case the
UMS  MB  will  always  be truncated if umsserver is not terminated
before  a  reboot or shutdown. This can be circumvented by closing
and  re-opening  each files instead of just flushing it. Umsserver
does so, if option CLOSEFILES is used.
  Modern  file-systems (like >=2.0 FFS) don't need this. So, since
it  might decrease performance, you're recommended not to use this
option.


REQ, NOREQ:

  enable  or  disable  UMS'  requesters. The default depend on the
value  of  pr_WindowPtr  of  the  server's  process. UMS only uses
requesters  in severe cases, e.g. when it cannot allocate required
memory  or  when  it's  aked  to  quit while there are still users
logged in.
  If  requesters  are disabled in such a case, always the negative
choice  is assumed. I.e. the server will quit, without retrying to
allocate  memory, or giving users a chance to log out properly. In
the worst case, when a bad error occurs during a cleanup, this can
mean that a corrupted message-base it left behind!
  Disabling  requesters  might  be useful if nobody is around that
could  answer  the requesters and help the umsserver. But it's not
required,  since  UMS'  requesters  have  a  timeout  (unless some
"autopoint"-like utilities are used).
  Since  UMS uses requesters only in really severe cases, it's NOT
recommended to disable them!


  User Options:
  ~~~~~~~~~~~~~

NOHARDLINKS:

  indicate  that  the  user  (typically an exporter) cannot handle
hardlinks.  If  this  option  is set for a user, UMS prevents this
user  of  receiving hardlinks. In case an (other) user WriteMsg()s
hardlinks  which  could be read by the NOHARDLINK user, WriteMsg()
will  fail with error code "noHardlinks (116). Can be used e.g. to
prevent  the user from writing a crossposting that would be cut by
exporters not supporting hardlinks.


MAILACTION, NEWSACTION:

  umsserver  can  automatically  execute  shell-comma nds for user
when they receive new messages. If umsserver is idle for SOFTFLUSH
seconds   and   news   messages  have  arrived  for  a  user,  its
ACTIONCOMMAND  can be executed. Option MAILACTION enables this for
new private message and NEWSACTION for public messages. Specifying
both  MAILACTION  and NEWSACTION means that ACTIONCOMMAND is to be
executed if any kind of new message has been received.


BOUNCEACTION:

  for  sysops  only:  execute  ACTIONCOMMAND  if new to-be-bounced
messages occur.