We've experienced some performance spikes we believe are due to Listserv,
so I've been watching it closely at periods, and adding timings to
certain pieces of code to try to track down problems.  Eric's always
been receptive to my suggestions for the future.  One idea I had
was to replace the D work disk with a RamDisk.  (RAMDISK is a tool
from Arty Ecock that allows a CMS minidisk to be taked from DMSFREE
space.)  I was going to increase the virtual memory, and let CP paging
take more work as opposed to Listserv doing I/O to a real D disk.  Well,
it wasn't possible because some routines reaccess the 192 as someother
mode and then reaccess as D.  I abandoned that idea as a nice idea,
but not worth the effort to re-write code.  (DMSDDL requires a work
disk as A).  It never occured to me then, but if you have FILEDISK = 'A5'
in the LOCAL SYSVARS, and you support the global LISTS database, you will
have over 1000 file just for that on you A-disk.  I haven't measured it,
but I imagine that the number of ACC 192 A, ACC 191 A commands done over
a day add up significantly.  I have ended up moving my LISTS database
to another disk.  (I obviously did it wrong, since it ended up asking every
server for a refresh.)
  The other day, I was on the Listserv console, and I remembered that
I needed to change a List header.  I foolishly edited it, which I believe
has thrown the checksums all off, and has caused every server to request
a REFRESHME from my server.  I noticed this because files began to
backup on the system.  There were many files from other servers requesting
LSVDEFLT REFRESHME.  On my server, this takes almost 3 minutes elapsed time.
I'm stuck with it now, but maybe I can save someone else from the trouble.
Because of it, I've modified LSVCMD to record number of times a command
is executed, and the amount of time each took.  I'll keep an eye on it,
and report anything interesting.
 
  Harry