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)