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
|
