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