Well, well, there is truth to both sides, but please note that: - DISTRIBUTE will be used AUTOMATICALLY by LISTSERV when distributing files to a list. Only files, not mail. Mail items are typically small and would not gain much from being DISTRIBUTEd, ie this is perhaps not worth the added CPU time and problem when the neighbour's server is on vacations ( ;-) ). However you should note that the current implementation of the file distribution feature is very unsatisfactory: 1) You don't know who sent the file. With DISTRIBUTE you know. 2) The routine that avoids loop is VERY poor. It works without problem when everything is ok, but the one implemented for MAIL is much more solid and will detect loops that the file distribution one will not. The last routine I implemented in DISTRIBUTE has a "VIA" dataset which gathers the userid@nodes of all the lists which participated in the file distri- bution and stop the process as soon as a duplicate is found. This is an excellent protection against loops. Note that it can still loop if there is an "old" server in the path which trashes the "VIA" dataset... :-( 3) Because of (1) the ACK/NOACK/MSGACK option is not respected. You don't know when your file has been received. No problem to respect it with DISTRIBUTE. 4) It doesn't work for ARPA recipients. DISTRIBUTE does, and will even use the best path to route the file to its appropriate gateway... I therefore think that DISTRIBUTE has GOOD reasons to be a part of LISTSERV. However, this does not mean that it cannot be isolated from LISTSERV and ran as a specialized server. The current code would cause some problems since the server would be registrated as a normal LISTSERV but there would be no pro- blem maintaining a separate list for DISTRIBUTE-only servers. If people are interested in running a server just for DISTRIBUTE I could provide a separate package and separate servers list... - If you split LISTSERV into MAILSERV, DISTSERV and FILESERV, you have a very significant duplication of code and datafiles. Just try it... :-) I bet more than 50% of the code/datafiles is shared between the three functions. - You can distribute a file to a LISTSERV list by making it the only recipient of the DISTRIBUTE job (that will be done automatically in the future when you send to a list). A DISTSERV could not, of course. - Similarly, you can restrict access to a file to a given list of people. That means if you want something which is not just GET = ALL/LCL/some list of nodes/some list of userid@node which will not change very often, you have to write code to maintain the list more efficiently than just logging on to the server, stop it, XEDIT the filelist, etc. Nothing prevents you from creating a LISTSERV list WITHOUT the associated dummy userid, ie a list you won't be able to mail to, just for defining who can retrieve a file or set of file. This could be the list of CS students working on AI projects for example. - Maintenance of one single server is easier than that of three servers. Espe- cially if you need to provide the three of them with a copy of BITEARN NODES which you must update every month, and re-issue a NODESGEN to the three of them But of course you may not need the file-server functions at all and be concer- ned about the disk space they require. But it's not that much actually. As for the "selling" aspect of the thing, I'd say that people would be more interested in a server that can do mailing, has powerful file-server functions, and has the DISTRIBUTE thing but requires only 3 cyls of 3350, than in three different servers. If they need only one or two of the three above functions they might still find a use for the last one in the future. This is especially true for the file-server functions which everybody can find a use for as soon as there is a program developped by someone at the local node which is to be made avai- lable to the network without having to worry about sending updates automatical- ly, etc. Granted, Netserv is here for that but Netserv is not designed to dis- tribute packages which have nothing to do with the network such as mods to the PASCALVS compiler :-) And there is often a need for a local file server for local-node-only use in each big installation -- even here at FRECP11 we had this need... Eric