>Well, it wasn't possible because some routines reaccess the 192 as someother >mode and then reaccess as D. I wish there was a "SET PGMSEARCH diskmode ON|OFF", which would allow me to tell CMS never to take any EXEC or MODULE from the D-disk. Not difficult to implement, and very useful, but unfortunately it's not there :-( That's what the D-to-Z-back-to-D swapping business is about. >(DMSDDL requires a work disk as A). That's not true, but DISK DUMP does. The 192 disk is NEVER accessed as A unless a DISK DUMP file is being received. I wish you could DISK LOAD * * D, but re-unfortunately, you can't. >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. It is HIGHLY UNDESIRABLE to have the LISTS database on the A-disk. I think I had already stated it, but I may have forgotten - please accept my apologies if it's the case. >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. Not unless you're receiving a large number of DISK DUMP files. However, LISTSERV will re-ACCESS the 191 from time to time, to sort the FST, just because it is (sigh) faster than making a sort in REXX (I'm speaking about a simple sort like the o(n**1.5) Shell-Sort, not something that takes 100 lines of code :-) ). That happens when you do a LIST command, for example. > 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. No, I edit files from the LISTSERV userid every day, and it's as good a method as GET + PUT *when you know what you're doing*. In particular, you have to make sure that new entries don't inherit bogus flags in cols 81-100 from another entry you "-ed, that they get inserted in the proper order, etc. But that doesn't spoil the checksum. I think the error you made (if you did indeed make one) was when moving the LISTS database stuff - this could well generate an invalid X-LUPD job, which would get invalidated after you fixed the database, thus creating a checksum error. >I'll keep an eye on it, and report anything interesting. Please do keep me informed. There is some code preventing a server from requesting a REFRESHME until it got the output from the previous REFRESHME, but I get the feeling that it doesn't always work. I'd be interested in any info you could provide on this. Thanks, Eric