I have several questions.  If you don't have time or interest for the first...
please skip to the next paragraph(s).
 
When a list's log disk fills up LISTSERV puts that list on hold and transfers
the offending file to the primary postmaster.  Once some space has been made
available on the disk, how does the primary postmaster (or better some lesser
mortal) resubmit that file back to the list?  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.  The
following message accompanied the returned file after I did a class D transfer:
 
> Received a transferred  file from myself, possibly  destined to (0743)@FILE.
> The destination node ("FILE" - assuming it  is valid) is probably not in the
> routing tables, which you might want to check. The file has been transferred
> to [log in to unmask]
 
How was this supposed to work?  (It looks like LISTSERV uses a class G
TRANSFER command to put the offending file in the postmaster's reader because
the file's origin here is LISTSERV rather than the list's userid.  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.)
 
Why doesn't LISTSERV simply leave the file with the other "held" files for
the list so that the list owner(s) could be able to handle the problem?
 
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?
 
I've read an old (1.5o) mailing (is there other documentation?) about dynamic
disks and filemodes, but 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?
 
Eric, If this is not currently possible, would you consider adding it to the
wish list?  My objective would be to permit a list log definition like:
    * Notebook= Yes,L1/userid.vaddr,...  (e.g, userid.vaddr could be OWEN.200)
so the log disk is completely defined in the LIST definition file and no LINK
command needs to be added to the LISTSERV PROFILE EXEC.  This would enable the
creation of a new list with its own log disk to be done without stopping and
restarting the server and also makes it possible to shift the burden of
creating and managing the log disk onto a (local) list owner.  Then, all the
postmaster has to do is create the list and let the list owner modify it to
point to the appropriate disk for logging.  It would be nice for a list owner
to be able to cause LISTSERV to RELEASE, DETACH and otherwise(?)manipulate the
appropriate log disk, but that's not required to achieve my objective.
 
Is it possible to define primary and secondary postmasters such that the
error and informational mailings only go to the primary postmaster??
 
Thanks for your help and consideration.
Jim Owen (wishing I had someonelse to be... postmaster)