>>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
|