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