>>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.
Sorry.  I didn't mean to make it sound like it was a gratuitous ACCESS.
>
>>(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.
Actually, I believe it can be other things also, since I've experienced this
problem on something else I was working.
>
>>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.
You may have stated it, but it went right past me.
>
>>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.
I guess my point was that with a large number of files on the A-disk, this
can add up.  LISTS database is one example.  Large Packages on the A-disk
also can be a problem.  If you don't need it on the A-disk, don't put it there.
This may not be intuitive to others, or a normal habit.  I, for example,
don't run with the Listserv EXECs on the a-disk. (Never have)  I was just
too lazy when I agreed to support the LISTS database to change a single
letter.
>
>>  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 was just changing the headers, not users.  I usually only delete users that
way.
>
>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.
Hmmm.  I know I mismoved the LISTS database, and I ended up requesting a
refresh from everyone else.  I never thought about it forcing everyone else
to get a refresh from me.  Meaning I might have just hit the monthly checksum
causing an error, and everyone choking on it, and requesting a refresh.
>
>>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