>When a  list's log  disk fills up  LISTSERV puts that  list on  hold and
>transfers the offending file to the primary postmaster.
 
This is an error, it should leave  the file in its reader in HOLD status.
I will fix it.
 
>I tried both CP class G and  D TRANSFERs back to LISTSERV; both resulted
>in the file being retransferred back to the postmaster, possibly because
>of a local CP mod to the  class G TRANSFER command that reORIGINates the
>file with the transferrer's userid.
 
c/possibly//
 
>Would the class  D transfer from postmaster have worked  properly if the
>ORIGIN of the file had been the  list's userid? If so, we can accomplish
>that by  ensuring that  LISTSERV uses the  unambiguous class  D TRANSFER
>command syntax: TRANSFER LISTSERV RDR... rather than TRANSFER * RDR.)
 
Yes, but there is no way I will change the code just because a particular
site happens to have a mod to class G TRANSFER that does not affect class
D TRANSFER.
 
>We have  been logging all  of our  lists on a  common log disk,  but the
>YALEVM postmasters are tiring of managing that common disk space for the
>list owners.  Has anyonelse  come up  with a good  scheme that  puts the
>burden of list and log management solely on the list owners?
 
So how do you allow a list owner to create and extend minidisks, etc?
 
>I don't see how they will help create the scenario that we would like to
>set up:  where the  log disk  belongs to some  other user  (probably the
>list's userid) and LISTSERV simply links that disk MR at it's native (or
>the next  available) virtual address  and remembers that address  to use
>with dynamic  filemodes. Has anyonelse  got this or  something similarly
>easy to work?
 
Q1: in what  way is this different  from LISTSERV being the  owner of the
disk and the list userid having a MR link?
 
Q2: why do you want the list userid to have R/W access to the disk? It is
VERY dangerous. LISTSERV sometimes creates files associated with the list
archives which should not be "ramdomly"  modified. The list owner can use
the PUT command to alter or delete list archive files.
 
>    * Notebook=  Yes,L1/userid.vaddr,...  (e.g,  userid.vaddr  could  be
>    OWEN.200)
 
Personally, I would call that a security exposure.
 
>Is it possible to define primary and secondary postmasters such that the
>error and informational mailings only go to the primary postmaster??
 
Use  the "quiet:"  keyword to  suppress  any mailing  to the  postmasters
following the keyword (they only have privs, but no junk mail).
 
  Eric