home *** CD-ROM | disk | FTP | other *** search
/ Meeting Pearls 3 / Meeting_Pearls_III.iso / Pearls / comm / Mail+News / UMS11 / Doc / english / options.txt < prev    next >
Text File  |  1995-07-09  |  5KB  |  146 lines
  1.  
  2.   Global Options:
  3.   ~~~~~~~~~~~~~~~
  4.  
  5. CHAINQUICK:
  6.  
  7.   when  importing, build reply-chains quicker by only using 32-bit
  8. CRCs  to  compare  MsgIDs.  This  involves  a  very  small risk of
  9. creating false reply-chains.
  10.  
  11.  
  12. SAVECOMMENTS:
  13.  
  14.   preserve comments when updating the "ums.config" file.
  15.  
  16.  
  17. BETTERIMPORT:
  18.  
  19.   use  larger  buffers  for  writing. This is useful when UMS more
  20. used  as  a  node  for routing messages between exporters than for
  21. interactive use, e.g. by newsreading.
  22.  
  23.  
  24. BETTEREXPORT:
  25.  
  26.   use  larger  buffers  for  reading.  Not that much useful. Speed
  27. sequential exporting but harms interactive usage (newsreading) and
  28. concurrent accesses.
  29.  
  30.  
  31. SPARING:
  32.  
  33.   use  as  little RAM as possible without becoming too slow. Makes
  34. BETTERIMPORT and BETTEREXPORT useless.
  35.  
  36.  
  37. GREEDY:
  38.  
  39.   use more RAM overall.
  40.  
  41.  
  42. NOADDBUFFERS:
  43.  
  44.   don't  use  AddBuffers().  Otherwise UMS tries to figure out how
  45. many  file-extension-blocks  it will need on the FileSystem and to
  46. AddBuffer()  missing  blocks.  NOADDBUFFERS  should  be enabled if
  47. other filesystems than FFS are used for the MB.
  48.  
  49.  
  50. NOCHECKHD:
  51.  
  52.   don't  try  to check space on FS. Neccessary when using RAM: for
  53. the MB.
  54.  
  55.  
  56. CHECKLINKS:
  57.  
  58.   perfect  data  structures integrity is essential for UMS' proper
  59. operation.  This  option tells umsserver to check all its ".chain"
  60. and  ".link" files on startup and somewhat repair deficiencies. 
  61.   If  you  upset  your  MB by improperly terminating UMS before it
  62. could  flush  its  buffers,  it will show several "too long" error
  63. next   time.   In  this  checking  of  links  is  already  invoked
  64. automatically,  so you don't usually need to use "CHECKLINKS". Use
  65. this if you're afraid you corrupted your MB otherwise.
  66.  
  67.  
  68. IMMEDIATEACTION:
  69.  
  70.   after  SOFTFLUSH  seconds  of  idle  time, ACTIONCOMMANDs can be
  71. started  automatically. By default, UMS will start only one action
  72. and  wait  another SOFTFLUSH seconds before starting the next one.
  73. This  ensures  that  actions are only run when UMS isn't currently
  74. needed  for  other  applications.  With  IMMEDIATEACTION, multiple
  75. actions  are  started immedeatly after each other. In other words:
  76. not  only  after  SOFTFLUSH  seconds  of idle time, but also after
  77. termination  of another action one new action can be started. This
  78. still  somewhat  avoids  to  spawn  a countless number of parallel
  79. processes.  If  you _want_ multiple actions to run in parallel and
  80. not be serialized, use the "run" command in an ACTIONCOMMAND.
  81.  
  82.  
  83. CLOSEFILES:
  84.  
  85.   some  filesystems  (e.g. old 1.3-FFS) don't entirely flush their
  86. buffers  when  asked to with dos.library/Flush(). In this case the
  87. UMS  MB  will  always  be truncated if umsserver is not terminated
  88. before  a  reboot or shutdown. This can be circumvented by closing
  89. and  re-opening  each files instead of just flushing it. Umsserver
  90. does so, if option CLOSEFILES is used.
  91.   Modern  file-systems (like >=2.0 FFS) don't need this. So, since
  92. it  might decrease performance, you're recommended not to use this
  93. option.
  94.  
  95.  
  96. REQ, NOREQ:
  97.  
  98.   enable  or  disable  UMS'  requesters. The default depend on the
  99. value  of  pr_WindowPtr  of  the  server's  process. UMS only uses
  100. requesters  in severe cases, e.g. when it cannot allocate required
  101. memory  or  when  it's  aked  to  quit while there are still users
  102. logged in.
  103.   If  requesters  are disabled in such a case, always the negative
  104. choice  is assumed. I.e. the server will quit, without retrying to
  105. allocate  memory, or giving users a chance to log out properly. In
  106. the worst case, when a bad error occurs during a cleanup, this can
  107. mean that a corrupted message-base it left behind!
  108.   Disabling  requesters  might  be useful if nobody is around that
  109. could  answer  the requesters and help the umsserver. But it's not
  110. required,  since  UMS'  requesters  have  a  timeout  (unless some
  111. "autopoint"-like utilities are used).
  112.   Since  UMS uses requesters only in really severe cases, it's NOT
  113. recommended to disable them!
  114.  
  115.  
  116.   User Options:
  117.   ~~~~~~~~~~~~~
  118.  
  119. NOHARDLINKS:
  120.  
  121.   indicate  that  the  user  (typically an exporter) cannot handle
  122. hardlinks.  If  this  option  is set for a user, UMS prevents this
  123. user  of  receiving hardlinks. In case an (other) user WriteMsg()s
  124. hardlinks  which  could be read by the NOHARDLINK user, WriteMsg()
  125. will  fail with error code "noHardlinks (116). Can be used e.g. to
  126. prevent  the user from writing a crossposting that would be cut by
  127. exporters not supporting hardlinks.
  128.  
  129.  
  130. MAILACTION, NEWSACTION:
  131.  
  132.   umsserver  can  automatically  execute  shell-comma nds for user
  133. when they receive new messages. If umsserver is idle for SOFTFLUSH
  134. seconds   and   news   messages  have  arrived  for  a  user,  its
  135. ACTIONCOMMAND  can be executed. Option MAILACTION enables this for
  136. new private message and NEWSACTION for public messages. Specifying
  137. both  MAILACTION  and NEWSACTION means that ACTIONCOMMAND is to be
  138. executed if any kind of new message has been received.
  139.  
  140.  
  141. BOUNCEACTION:
  142.  
  143.   for  sysops  only:  execute  ACTIONCOMMAND  if new to-be-bounced
  144. messages occur.
  145.  
  146.