Nick: I think the "Subject:" field is accepted on IBM notes provided it appears AFTER all the mandatory tags. You can also use "Subj:". Jeff: you're right, but this implies an additional call to LSVKEYWD and 5 more lines of code whenever I need to look at the Notebook tag, which is why I used a hardcoded default from the beginning. I'm not too keen on changing this one -- just make the notebook public in the mail header. I'd do it if everybody really thinks that it's really important. Notebooks: well, several things are sure... 1) It is IMPOSSIBLE to keep a list of all subscribers to a given list. I had contemplated doing it in the past to solve the problem with people attempting to mail to a 'foreign' peer when theirs was down and Send= Private, or people wanting to REV (LOC a list at some peer where Review= Private, etc. I was completely discouraged by the number of people who modify their LIST files using XEDIT from the LISTSERV machine, thwarting any attempts at synchronizing the recipients lists. 2) Item (1) implies that someone who's registered at a server which doesn't keep notebooks will not be able to get them by asking another server directly. We're speaking of the Notebook= Yes,Private case only, of course. 3) A server which doesn't keep notebook could be caused to automatically forward the request to other peers (in much the same way as a REVIEW command gets forwarded). This would unavoidably cause multiple notebooks to be sent to the originator... unless there is a keyword telling the server which peers are presently keeping notebooks. The following syntax might work: - Extend the first operand of the Notebook= field: Yes | No | Peers. All the other operands still apply. - Add a new keyword: Archivers= node1,node2,<user3@>node3... Same format as the Peers= keyword but it lists those peers who're keeping notebooks - Notebook= Peers,... means that if 'my node' appears in Archivers, I keep a notebook, else I don't (this allows the list header to be the same for all nodes; a variation might be Peers --> I don't keep one). If I don't keep a notebook, I'll forward to the nearest (LSVBITFD-wise) server. 4) Problem: you need to know the fileid of the notebook file you want. That means you must be able to GET listname FILELIST. If it's GET = ALL, no problem; however, there are cases where you'd want it to be GET = PRV, for example if you have Notebook= Yes,Private,..,Separate and you feel that some of the Subject: tags (they appear in the filelist in that case) are confidential. In that case the guy won't be able to get the filelist. Besides, the fileid may not be the same for all the servers in case logging is set to Separate, and you may not know in advance which server you'll get your notebooks from. So we need the same kind of auto-forwarding facility on 'listname FILELIST' (I intend to drop the NOTEBOOK FILELIST soon, it costs too much CPU time to build and is really too large; to com- pensate, LISTSERV will automatically build a default 'listname FILELIST' if none exists on the A-disk -- GET code will be PRV). Does that sound ok to all of you? Two other problems: 1) Due to some old areas of code in LSVDIST EXEC (dating back from the time that ALL servers were automatically part of the DISTRIBUTE backbone), version 1.5h of LISTSERV crashes with a REXX error whenever a global PUT command (such as my PUT PEERS NAMES) is distributed to a server which has disabled the DISTRIBUTE function. I'll fix that, but I wanted to warn you about the problem. Affected servers are those who're next to a server which has disabled DISTRIBUTE. 2) Due to the limit that CMS places on the number of arguments you may pass to a program, all servers will crash with REXX errors as soon as the 60th LISTSERV is added to PEERS NAMES... :-( The various options, eg (STACK, will be moved to the left and programs like LSVBITFD will successfully complete with data being typed on the terminal, not stacked. When LISTSERV issues a PULL command it will be in big troubles. I'll make sure to find a solution BEFORE letting more than 59 servers in PEERS NAMES :-) 3) Due to internal coding conventions, servers with DISTRIBUTE disabled are unable to process multiple-hosts PUT commands such as PUT PEERS NAMES. The problem is easy to understand: DISTRIBUTE is used to propagate the file to be stored through the network. Whenever the destination for a file is a list server, it is a convention that what the sender wanted the server to do is to process the file as if it had been sent directly to the server's reader. For obvious security validation reasons, the DISTRIBUTE job is then forwarded (instead of being distributed) to the target LISTSERV, ie it does not get the file from another server but a DISTRIBUTE job with only one recipient: itself. Servers with DISTRIBUTE disabled will zap the job before even looking into it. This is a tough problem, but I'll try to find a way out. Just don't be surprised if it happens. Eric