This weekend has been very productive I think (although FRORS31 was down all
the time, as usual). The "infernal program" seems to be working perfectly, and
proves to be very useful. I have added the following features:
- "NODESGEN" command that automates the generation of ALL BITEARN NODES-based
tables. It takes 15 minutes to execute on my system (with 6 batch machines
prior = 30 (we were blackmailed into doing this, *I* would never give prior
30 to *six* batch machines)) because of the !"|$!"$ :alias. which the pre-
vious version did not handle, and which are NOT in sort order of course. I
spent 10 minutes thinking of a way to sort them back in less than 60 minutes
of REXX execution -- a bubble sort of 1,500 entries takes forever in REXX :-(
GENROUTS is no longer needed, which does not mean that you should not learn
to use it for your RSCS tables (if you don't use it already) :-)
- "SUBSCRIBE" now automatically forwards requests to the host nearest to your
node. Only one forward operation is done, in case the tables are not synched
and the target server would forward back.... Do forever; Bounce; End....
- "<QUIET> MOVE listname userid@node <TO> newnode"
DD=ddname
This moves the indicated guy or list of guys to the indicated server, in such
a way that his SET options are transferred without loss and no mailing is
lost. It works that way:
You Source server Target server #1 Target server #2
MOVE --------->.
X-ADD------------------->adds
X-ADD--------------------------------------------->adds
.<------------ack
(network delay)
dels<-------------------X-DEL
dels<---------------------------------------------X-DEL
.<------------"command complete"
(plus notification mail)
The list names and list passwords must be the same at the two nodes. Otherwi-
se it's just too much of a pain to define a protocol to convey the two pass-
words to the servers, plus the "target" servers could intercept the password
to send back to the "source" server to accept the X-DEL, so it's all useless.
- "EXPLODE listname": this causes LISTSERV to examine the specified list and
see whether some MOVEing ought to be done or not. If so, it sends you back a
job file which you'll have to receive and send back after review (and after
filling in the password field) if you actually want to effect the MOVEs. It
is a very short routine and very convenient when adding a new server to a
list. It does take some CPU time to run, but not to much. About 5 secs TCPU
for the CHAT-L list, ie less than 0.3 secs per user, which I think is very
reasonable considering the time it saves you :-)
- The "commands job" stuff is 90% implemented. I needed it for the MOVE stuff
and I also implemented what I will need for the "big project" (file retrans-
mission with the LISTSERVs routing copies of the files thru each other accor-
ding to the recipients list -- similar to the "forking" aspect of some
networking programs). Actually this "big project" has now become very easy
with the commands-job crap and the "lightspeed pathfinder" ( :-) ) so I
think I'll be able to write it next weekend. Beats GRAND :-) The worst will
be to write the LISTSERV-using version of SENDFILE :-(
Also, I'll upgrade DEL and ADD when I have time to support the "DD=ddname"
option (better speed when adding/deleting a lot of people at once).
Ah, LSVPUT: Harold took my NSVPUT program from Netserv and converted it into a
LSVPUT since it seemed like I would never have done it unless I was really
pushed to :-) I reviewed it and re-shaped part of the code (hope Harold won't
kill me), gave it some testing and it seemed to work ok, so I'm shipping it to
this list. Note that it won't accept passwords longer than 8 chars because of
!"$"%$ DVHUTL RDI (I could write a LSVRDI ASSEMBLE, it's very easy, but is it
really worth it?). Harold, some of the changes I made may seem trivial and
silly, such as wasting time for nothing, but I had to make them in NSVPUT becau
se of people bitching me. For example, I would myself *never* have added that
test on the STATE return code saying "disk not accessed" instead of "file not
found" and similar crap because h*ll, if the disk is not accessed, it's not
false nor stupid to say that the file was not found!... But, well, I guess that
a perfect program should say "disk not accessed" and I was asked to put it in
and I did it to save myself the time of explaining why I felt it was not neces-
sary :-) Similarly, rc=999 is not documented in the IBM doc and should there-
fore never be used, etc. Oh well....
Anyway: I'll need someone to test my new 1.4b stuff before I can ship it out
(assuming I get to find time for upgrading the docs). That would be on monday
or tuesday evening, my time. Also, the reason why the US didn't get V1.4a is
that UGA was down this weekend and the files were large enough to have taken
the night to get there. In case you didn't install 1.4 yet, you should discard
the individual LSVPROF and LSVRECV you have received from LSTSRV-D, they are
contained in UPD14A SHIPMENT. And in case you get funny JCL-looking files from
my server transferred to you, just discard them and forgive me... :-)
Eric
|
