>(SFS) seemed like a possible way to eliminate some of the work LISTSERV >does to simulate a hierarchical file system, and take that burden off >your back. I understand that you want to drop the subject, but I want to make sure I have convinced you that the SFS cannot take any burden off my back, at least not now. Common sense dictates that you cannot simplify your (programming) task by relying on a facility, however powerful it might be, which you cannot use unconditionally. That is, as long as you have to code "IF <I can use facility> THEN <inst1> ELSE <inst2>", you are making your life more difficult because you have to code inst2 anyway and now you are adding the burden of inst1. Doing this might (or might not) increase performance or provide better functionality when the facility is available, but it is certainly NEVER going to make your life easier. This is by the way the only reason why LISTSERV V2 will not support CMS release 3 any more: I'm sick and tired of coding "If sp4 Then" everywhere I want to do an EXECLOAD or EXECIO STEM, when almost everybody has CMS 4 or above. I don't *need* to do an EXECLOAD or EXECIO STEM, but I usually want the performance boost when I can use it, and I'm tired of the IF's. >Ideally, these services should be specified independently of your >implementation, so that any user on any system on the network can write >a compatible server. Nobody will write such a compatible server. I know it sounds like a gratuitous and dictatorial statement, but it's based on experience. I have sent LISTSERV sources, over the last 3 years, to a dozen experienced VMS programmers (some of which also had a good knowledge of VM) who wanted to port it to VMS. None of them has produced anything that would handle even just the distribution list business, which is a relatively small fraction of LISTSERV. Maybe it due to the sheer amount of work to be done (30000 lines of REXX code, 6000 lines of assembler, 12000 lines of documentation and, as you know, a lot remains to be done in this area). Maybe to the difficulty of interfacing with the networking software under VMS. Maybe to the fact that LISTSERV kept changing very fast, when I was working on it full time. Maybe to the lack of documentation about the internals, but on the other hand REXX is easier to understand than most programming languages. If you want to port LISTSERV to another operating system, you have to face 3 difficulties: 1. Get someone to write a specification of LISTSERV and documentation about the internals. 2. Find people to write the code. 3. Convince the user community that this implementation can be "trusted" to join the backbone (for example). For (1) and (2), you will have to bear in mind that LISTSERV is constantly changing and that, as they port the software, the poor programmers will be faced with constantly changing specifications (the changes would be compatible of course, but the amount of work they have to do would constantly increase, so that they might get the impression that they will never catch up). >As it stands now, around 60-70% of all BITNET nodes are excluded from >running LISTSERV because they do not run VM. They can use the LISTSERVs running on VM nodes from their non-VM machines. That's about as far as I can go. Eric