Please use REPLY TEXT or suchlike to answer this survey. Be sure to reply to SURVEY@FRECP11, not ERIC. If you cannot answer a question, just ignore it. 1. If you are not a LISTSERV postmaster, please indicate your role in LISTSERV operations (user, list owner, file owner). Otherwise ignore question. 2. Please give the model of your CPU. 3. How much CPU does your LISTSERV eat a month, on the average? 4. How much lists are there on your LISTSERV? Count lists > 100 ppl as 2 lists. 5. On the average, do you think LISTSERV eats: Little CPU, a Normal amount of CPU, Too much CPU? 6. Specifically, which are the commands/functions (eg 'mail processing', 'the XXX command') which you find unacceptably (or particularly) slow? 7. Would you be willing to increase LISTSERV's disk space if it may save you CPU cycles? You may give detailed explanations if you want. 8. Would you be willing to increase its virtual storage (by around 1-2M) to save CPU cycles (and possibly increase paging)? 9. Are you particularly concerned about the amound of DASD I/O operations done by LISTSERV (eg EXECIO * DISKR (FIND xxxx)? If so, would you rather have it use more GLOBALV storage and do less DASD I/O (and consequently require more storage too)? 10. To which extent would you be willing to spend CPU cycles to help alleviating network congestion? Reply 'never!!', 'anything you want if it may help', 'not more than nnn secs a day', etc. 11. Ditto on permanent DASD space (I'm thinking of automatic archiving and suchlike, or providing large files normally hosted by other servers). 12. Do you think DISTRIBUTE is: Underused, Overused, or used Normally? 13. Would you be willing to have your server used to DISTRIBUTE large ARPA lists for the good of the network community, even if it causes it to eat more cycles? I mean, not creating lists on your server but just using it as part of the DISTRIBUTE backbone to solve the problem of those awfully large ARPA distributions. 14. Are there particular features you would like to see added to LISTSERV? Please be realistic and don't ask for something impossible :-) 15. If LISTSERV provided, in the future, a network-wide conferencing system that would require a significant (5 megs? 10 megs?) increase in permanent DASD space (to cache issues of (possibly other people's) conferences for a short period of time as well as to permanently keep issues of chosen conferences), and possibly a (reasonable) increase in virtual storage and CPU, would you be willing to host that feature or would you want to disable it on your server? Note that your answer will have no impact on whether the feature will actually be provided or not as this is part of a completely independent project for NETSERV and LISTSERV (funded by IBM Germany). However, I need your views on that so as to have the specs of the project 'tuned' as needed. 16. Still about the same conferencing system project. Would you mind if the DISTRIBUTE function was used to send out copies of conference issues, even if your server doesn't participate in the conference? 17. We are presently trying to 'blend' the LISTSERV and NETSERV command sets so as to make it easier for users *and* application programs to act independently of the type of server. For example, NETSERV will change the syntax of its commands to use a "PW=" keyword instead of the positional parameter. However, this may require a few adaptations from LISTSERV as well. The question is: would you accept changes to LISTSERV that caused (minor) incompatibility problems, or temporary problems (I'm thinking of 'this will cause problems until all the servers hosting the list have installed release nnn' and suchlike) or would you rather keep a few annoying differences to avoid such problems? We'll be trying to develop a 'common command set', ie a SUB-set of commands and parameters that works identically with NETSERV and LISTSERV so that servers/programs using those commands don't even have to know which type of server they're speaking to. Each server will retain options/parameters/whatever that are specific to it but part of each command's syntax will be compatible with the other server -- ideally... Thanks for your time, Eric