Just have a look at the latest NetMonth issue, there is an article about GRAND by Judith Molka: > It (GRAND) will soon be used to shadow several discussion groups on > [log in to unmask] Wonder why they're not willing to install a FRECP11-LISTSERV? ;-) I guess we have to do something about this use of GRAND as a substitute for LISTSERV. As you may know my first experience with GRAND was a *BIG* deception. They may have improved it, but three things are sure: 1) The size of the user package CANNOT have decreased (about 3 cyls) 2) The speed of the user package CANNOT have increased (5 secs for just pres- sing ENTER on my system) 3) The size of the files it ships you across the network, as well as the number of these files, cannot have bettered. You want to know what a discussion is about because you don't understand what the topic exactly is? Just press the ORDER key and wait until the whole 1,500 lines contents of the discussion reach you :-) I've heard rumours that the main problem of GRAND is that the servers ship updates to each other faster than the network can transmit them, resulting in a GRANDiose bottleneck *hee hee* Anyway, GRAND may perhaps be a good conferencing tool; but it certainly should not be used to emulate LISTSERV functions, in much the same way that a war 40 tons tank should not be used as a personal leisure car ;-) Some (happy) news: - I'm completing a "links weight" feature for the infernal module. It seems to be working, except that we have problems with aliases. If you change the weight of a link, you must change the weights of all the aliases too. Otherwi se the link gets short-cut by its alias, and... :-( Also it sometimes causes the program to die because it creates a loop in the network (that would have to be examined more thoroughly). - I'm not going to use the "links speed" from BITEARN NODES to create the links weight file. I heard that NODESGEN takes 1 minute 20 secs on Phil's computer, but on mine it takes 15 minutes. I just can't afford doubling that, especial- ly since I would have to test the stuff. I can't spend 6 hours on this just because every test takes 30 minutes. Anyway I don't think this is very impor- tant since important links all have the same link speed. - I'm putting on some stuff to fix the loop problems on ARPA &co. I decided that parsing the messages was impossible, considering the amount of "ERGTW-PRTMOUT%NSLINK%MAIL- Poor mailer was not able to access nasty UNIX node for three days, your nice mail has had to be canned, waaaahahahahh". I just had an "EUREKA" idea: *anything* sent by LISTSERV has a "Sender: nia niania <listid@mynode>" line in the header. Now if I find a "Sender: some- thing <listid@mynode>" line in the mail BODY, it is probably a rejection notice. - Loop problems caused by loops in peer links: I'll fix that by adding an inter peer field indicating the source node. If I get mail originated from *me*, I just can it. :-) Which does not mean that I'm not going to bitch whomever initiated the link.... Ah, another issue (excuse the length of this mail :-) ). The BITNIC seemed to be very concerned with the issue of "LISTSERV coordination". I saw in a note from BITNIC that they sort of tended to assume that it would be reasonable that the NIC be designated as the coordination point for all LISTSERVs in the world. Needless to say, it seems absurd that BITNIC coordinates a network of FRECP11- LISTSERVs when THEY do not even have one and have no idea of how it works. Even assuming that they eventually install one, they would have to really indulge in a minute perusal of all the tomes and librams furnished with the device, not to mention the arcane formulae found in the magic REXX books inside the apparatus. :-) Actually I think that the LISTSERVs should be coordinated not by a single person or center, which would not be available 24h, not to mention the time zones problem, but by a (limited) number of people who have a good knowledge of the thing and above all a good understanding of how peer linking works and what should be done to avoid a loop or stop it. Good knowledge of the network topolo gy (in the person's area) would also be required. FRECP11-LISTSERV is a distri- buted server, so it's gonna have a distributed coordination :-) I think that about 5 people would be needed all over the world, 2 in Europe and 2-3 in the States (and perhaps 1 in Canada too). Who will volunteer? We might then suggest to the various LISTSERV owners to give one or more of these persons the authority to stop their LISTSERV in case a mailing loop occurs. This would also cause them to receive all severe error messages from the server and would help troubleshooting a lot. This would of course be optio- nal, although those people who do not allow anybody except their own account to stop their LISTSERV might be considered morally responsible of long duration mailing loops by other people on the network. As I mentioned in the LISTMAST MEMO, I feel like anybody who has authority to drain the network link to the LISTSERV should also have authority to stop the server so that he does not have to resort to draining the link to stop a mailing loop. Also please note that you can give STOP privileges *without* giving CP or CMS privileges -- this is a separate class of postmastership and requires a separate password. I understand that nobody would want people outside the node to have CP privs on a class D account. :-) Eric