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