BioBit No 17 ( Bitnet for the complete idiot )

Robert A. L. Harper harper at cc.helsinki.fi
Thu Oct 18 16:28:26 EST 1990


         1717171717                      1717171717
         1717171717                      1717171717
         171    171                      171    171
         171717171    171   1717171717   171717171    171  171717171
         171717171          1717171717   171717171            171
         171    171   171   171    171   171    171   171     171
         1717171717   171   1717171717   1717171717   171     171
         1717171717   171   1717171717   1717171717   171     171

                                  No 17

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
                      INDEPENDENT "bionaut" NEWSLETTER 
                        << EDITED BY ROBERT HARPER >>
    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

   Summer is over. Good things are happening on the net once again. There
   has been a new release of "BITNET for the complete idiot". Things are
   therefore not too bad. I know I did not write this network clasic. I
   know it is long... but it is so good and covers so many things, it would
   be a waste not to give it some airplay. And since the documentation says
   that if you inform the author you can include it in a newsletter then that
   is enough justification to put it out on BIONET.... RIGHT!!!
   
   No more talk. Ladies and gentlemen may I present for your education,
   edification and entertainment the one... the only... BITNET USERHELP.

   Rob "standing on the shoulders of a giant you see much further" Harper
 
     _
    __-
   __---    The
  __-----   BITNET
 __-------  Services
___________ Library                                             BITNET USERHELP
 
*******************************************************************************
 
                                                                   August, 1989
 
 
           "Oh no! Another Version of the Completely Revised Edition"
 
 
This  document  has been  written  for new  users  of BITNET services.  A quick
perusal of the text here should familiarize  you with the basic concepts behind
BITNET and how to communicate with people through it.   A longer look will show
you the many types of information services available in the network and explain
how to access them.
 
If the information  presented  here is  confusing or  incomplete, please send a
note to the author, Christopher Condon, at address BITLIB at YALEVM.  Likewise, if
you  find  this document  useful and would like to reprint it in part or whole,
(in a newsletter or local  documentation, for example) we  have no objection as
long as you inform the author.
 
A companion file to this is BITNET SERVERS, which lists the currently available
servers and services. Instructions for receiving the latest versions of SERVERS
and USERHELP appear at the bottom of this document. In addition to these files,
you should  consult your local  computer center staff  and online documentation
for additional information.
 
Here is a rundown of the topics covered:
 
 
     1.   Tools for Communication
 
          BITNET for the Compleat Idiot
          Messages
          Files
          Mail
 
     2.   Servers and Services
 
          What the Heck is a Server, Anyway?
          File Servers
          User Directory Servers
          Forums, Digests, and Electronic Magazines
          List Servers
          Relays
 
     3.   Beyond BITNET
 
          Other Networks
          More on Gateways
 
     4.   In Conclusion
 
          Suggested Reading
 
 
 *********
*         *  Tools for Communication
*         *
*         *  Part 1
*         *
*         *  BITNET for the Compleat Idiot
 *********
 
 
If you intend to make any sense out of this document,  you should first  have a
basic understanding of some computer concepts:   mainframes,  userids,  and the
like.   Since  you are  reading this  there is  a pretty  good chance  that you
understand these things already.   If not, go back,  read some documentation on
your system, get comfortable with "logging on", "editing",  and all those other
fun activities  and *then*  you can begin  communicating through  BITNET.   The
concepts we present  here aren't terribly Earth-shattering,   but you shouldn't
dive into this totally unprepared either.
 
You should also  be a little  familiar with the type  of hardware and operating
system  you are  using.  Most IBM systems  in BITNET run VM/CMS.   The  Digital
Equipment VAX  systems usually run  an operating  system called VMS  along with
a software package called JNET which allows them to communicate via BITNET.  We
will be referring to VM/CMS and VMS/JNET throughout this document.
 
If you  already understand  computer networking,   you will  find this  section
entirely dull  and pedantic.   We  would advise you to  skip to the  next part,
"Messages".  For the rest of you, we'll try to make this quick and painless.
 
The word "computer" still scares many people.   When BITNET is described simply
as  a "computer  network",   that  one word  can  send  chills up  your  spine.
Sometimes  a phrase  like "communications  medium"  can make  the technology  a
little more accessible.   That  is how we like to think of  it.   It's not some
awful computer-techie sort  of thing.   Rather,  it's a  tool for communicating
with people and exchanging information, just like your telephone, only a little
more complex.
 
This doesn't  mean that there  isn't a lot  of gee-whiz technical  stuff behind
BITNET.   If that is the sort of thing that tickles your fancy,  you'll find it
in this network.  The rest of you, however, don't need to know the gory details
in order to use BITNET effectively.
 
That mainframe  you log onto is  connected to mainframes at  other universities
and institutions.    The connection  is usually  a high-speed  leased line,   a
special sort of telephone connection.   You  might say that these computers are
always on the phone with each other.    Our particular network is what is known
as a  "store and forward"  network.    This means that  if I send  something to
someone in Los  Angeles,  the computers in the network  between Connecticut and
California will store and forward it from computer to computer until it reaches
it's destination.
 
In BITNET,  there is only one way from "Point A" to "Point B".    A small piece
of the network might look like this:
 
 
              ---    ---    ---
             | A |--| B |--| C |
              ---    ---    ---
                      |
                     ---    ---    ---    ---    ---
                    | D |--| E |--| F |--| G |--| H |
                     ---    ---    ---    ---    ---
                      |                    |
              ---    ---                  ---    ---
             | I |--| J |                | K |--| L |
              ---    ---                  ---    ---
                                           |
                                   ---    ---
                                  | M |--| N |
                                   ---    ---
 
 
Those boxes represent computers in the network, and the dashes between them are
the leased  lines.  If I  am at computer "A" and  I send a file  to someone  at
computer "N" it would travel the following path:
 
                              A-B-D-E-F-G-K-N
 
Each of the computers  in BITNET is called a "node" and has  a unique name that
identifies it to the other nodes.   For example, one of the mainframe computers
at Yale has the  nodename YALEVM.   You might liken this to  a state or country
abbreviation:
 
     In the postal service:     CT     =  Connecticut
     In BITNET:                 YALEVM =  Yale University IBM 3083
 
Your  userid in  combination  with  the name  of  your  node is  your  "network
address".   It  is usually written in  the format userid at node (read  "userid at
node").   For example, the name of my node is YALEVM,  and my userid is CONDON.
Therefore,  my network address is CONDON at YALEVM.   If I know the userid at node of
someone in  the network,   I can communicate  with that  person, and he/she can
communicate with me.   The same goes for you.    All you need to know are a few
commands.
 
 
 *********
*         *  Tools for Communication
*         *
*         *  Part 2
*         *
*         *  Messages
 *********
 
 
There are three basic methods of communicating via BITNET:   MESSAGE, FILE, and
MAIL.   The reason  you  would  choose one  over  the  other for  a  particular
application will become clear after a little explanation.
 
The MESSAGE (sometimes  called "interactive message")  is the  fastest and most
convenient  method  of communication  available  through  BITNET.   It  is  the
network's equivalent of  a telephone conversation.  The difference  is that the
words  are typed  instead  of spoken.    The message  you  type is  transmitted
immediately (well, quickly) to its destination.   In BITNET this destination is
the network address (userid at node)  of the person  you want to contact.   If the
person you are contacting is logged on,  the message will be displayed on their
screen.   If not, their computer will tell you so.   In this case, your message
is  lost forever.    In other  words,  no  one is  there to  answer the  phone.
However, many people run a program which will act like an answering machine and
hold your message until they log on.
 
The  syntax to  send messages  depends on  your computer  and system  software.
People on VM/CMS systems would type something like this:
 
     TELL userid AT node message
 
For example:
 
     TELL KRISTEN AT MARIST Hey Kristen, What's up?
          +------    +----- +----------------------
          |          |      |
          |          |      +----------- the message you are sending
          |          |
          |          +------------------ the node of the recipient
          |
          +----------------------------- the userid of the recipient
 
 
People on  VAX/VMS systems using  the JNET  networking software would  use this
syntax:
 
     SEND userid at node "message"
 
For example:
 
     SEND KRISTEN at MARIST "Hey Kristen, What's up?"
          +------ +----- +------------------------
          |       |      |
          |       |      +-------------- the message you are sending
          |       |
          |       +--------------------- the node of the recipient
          |
          +----------------------------- the userid of the recipient
 
 
The quotes  around the message are  optional.  However, the JNET networking for
VAX/VMS will  translate your  entire message into upper-case  characters if you
DO NOT  use them.  Many  people  find receiving  messages like   that extremely
annoying.
 
You should consult your local system documentation for more information on TELL
or SEND and their  capabilities.    When a message arrives on  your screen,  it
will look something like this:
 
     FROM MARIST(KRISTEN):  Hello!  It's been a while, no?
 
Now for the disadvantages:   Text sent by  message must be short.   In general,
your message length can be one line, about the width of your screen.   In other
words, you won't be sending someone a copy of your thesis via the TELL command.
Also,  you can only  communicate with someone in this way  when they are logged
on.   Considering  time zone  differences,  this  is often  quite inconvenient.
Lastly, there is the problem of links.   If the connection to the node you want
to contact is broken (by, for example, a disconnected phone line),  you receive
an error message and whatever you sent is gone.
 
However, this does not make messages totally useless. As you will see later on,
TELL and SEND are extremely helpful in accessing the many services in BITNET.
 
 
 *********
*         *  Tools for Communication
*         *
*         *  Part 3
*         *
*         *  Files
 *********
 
 
FILES are another way to communicate over BITNET.   The text files and programs
that you  store on your  computer can be transmitted  to users at  other nodes.
People on VM/CMS systems would use a syntax like this:
 
     SENDFILE filename filetype filemode userid AT node
 
For example:
 
     SENDFILE BITNET USERHELP A KRISTEN AT MARIST
              +---------------- +----------------
              |                 |
              |                 +------- the address of the recipient
              |
              +------------------------- the file you are sending
 
 
The syntax for VMS/JNET systems is quite similar:
 
     SEND/FILE filename.extension userid at node
 
For example:
 
     SEND/FILE BITNET.USERHELP KRISTEN at MARIST
              +--------------- +-------------
              |                |
              |                +-------- the address of the recipient
              |
              +------------------------- the file you are sending
 
 
The file sent  is stored in  the "electronic mailbox"  of the  recipient  until
he/she  logs on.   People  on VM/CMS systems  would use the  RECEIVE or RDRLIST
commands to process files sent to them in this way.  People on VAX/VMS  systems
would use the RECEIVE command.  You should check your local  documentation  for
information on these commands.
 
SEND/FILE and SENDFILE are useful for sending programs or large volumes of data
over the network.  However, they shouldn't be used for  everyday communication.
The MAIL utilities (covered below) are much more accessible.
 
 
 *********
*         *  Tools for Communication
*         *
*         *  Part 4
*         *
*         *  Mail
 *********
 
 
Luckily the other form of BITNET communication  has been given a very apt name:
MAIL (often called "electronic mail" or "e-mail").    The simile is a good one.
Just like regular postal service mail  ("snail mail"),  you provide an address,
return address, and text.  Software for sending mail software differs from site
to site,  so you will have to look in your local documentation for information.
However, we may be able to shed some light on what most mail looks like and how
it works.
 
Mail files are  really just specially formatted text files.    The feature that
makes them different is the "mail header".  This tells a BITNET system and your
mail software  that it is  not a regular text  file.   It looks  something like
this:
 
                                           The address of the recipient
                                                                      |
                                                         The subject  |
                                                                   |  |
                                                     Your address  |  |
                                                                |  |  |
                                                   Todays date  |  |  |
                                                             |  |  |  |
     Date:         Fri, 10 Sep 88 23:52:00 EDT            <--+  |  |  |
     From:         Ted Kord <BEETLE at JLIVM>                <-----+  |  |
     Subject:      COBOL declared illegal                 <--------+  |
     To:           Kristen Maryrose Shaw <KRISTEN at MARIST> <-----------+
 
 
An entire mail message would look like this:
 
 
  +---------------- Mail header
  |
  |  Date:         Fri, 10 Sep 88 23:52:00 EDT
  |  From:         Ted Kord <BEETLE at JLIVM>
  |  Subject:      COBOL declared illegal
  |  To:           Kristen Maryrose Shaw <KRISTEN at MARIST>
  +  ========================================================================
 
  +  Have you seen the newspapers?  Is this good news, or what?  I think that
  |  the ramifications are startling.  This is one more step on the road to a
  |  higher civilization.  We may make it out of the Computer Age yet.  Or is
  |  it the Space Age?  I keep forgetting...
  |
  +---------------- Mail text
 
 
Mail has a number  of advantages.   The size of a mail file  is limited only by
your long-windedness  (however,  we don't recommend that  you transmit anything
longer than 3000 lines). If the person at the destination address is not logged
on,  the  message will be stored  until they read  it.    If the links  to that
particular node  are disconnected,   your mail will  be held  until it  can get
through.   Also,   mail is  the only  way you  can communicate  with people  in
networks outside of BITNET.
 
The disadvantage of mail  is that it is,  indeed,  slower  than messages.   The
longer your mail file,  the longer it will take to get from Point A to Point B.
If your mail is less than 100 lines you won't have to worry about that.
 
 
 *********
*         *  Servers and Services
*         *
*         *  Part 1
*         *
*         *  What the Heck is a Server, Anyway?
 *********
 
 
One of  the first things  experienced BITNET users will  tell you about  is the
variety of file servers, list servers, relays, and so on.   They might describe
them to you as "virtual machines" or "server machines". This kind of talk makes
plenty  of  sense if  you are a  typical computer nut,  but for the novice this
terminology might  as well be  Gaelic.   Luckily,   the concept is  really very
simple, despite everyone's efforts to make it confusing.
 
A "server" is a userid much like yours.    It may exist on your computer (node)
or on  some other  BITNET node.    The people who  set up  this userid  have it
running a program that will respond to your commands.  This is a "server".  The
commands you send and  the way in which the server responds  to them depends on
the particular program being run.   For example, the servers NETSERV at MARIST and
LISTSERV at BITNIC offer  different types of  services,  and so  require different
commands.  The various kinds of servers are described later in this document.
 
You can send your commands to servers in one of two formats:   MAIL or MESSAGE.
Not all  servers accept  commands via  both formats,   but this  information is
included in the document BITNET SERVERS.
 
People on VM/CMS systems would send commands something like this:
 
     TELL userid AT node command
 
For example:
 
     TELL NETSERV AT MARIST HELP
 
People on  VAX/VMS systems using  the JNET  networking software would  use this
syntax:
 
     SEND userid at node "command"
 
For example:
 
     SEND NETSERV at MARIST "HELP"
 
Many servers can also accept commands via mail.   Indeed, some will only accept
your commands in that format.   The syntax for the commands you send remain the
same.  You send mail to the server as if you were sending the mail to a person.
The text  of your message  would be the command.    Some servers will  take the
command  as the  first  line of  a  text  message,  others  require  it in  the
"Subject:" line.    Some servers will  accept more than  one command in  a mail
message, others will take only one.   Here is an example of a mail message sent
to LISTSERV at BITNIC requesting a list of files:
 
 
     Date:         Fri, 10 Sep 88 23:52:00 EDT
     From:         Rebecca Estelle Shaw <BECCA at YALEVM>
     To:           Listserv <LISTSERV at BITNIC>
     ========================================================================
     INDEX
 
 
Throughout  this document  we  will use  examples where  commands  are sent  to
servers via message.   However,  for many of the cases we will present you have
option of using mail.  The choice is up to you.
 
There are two particularly confusing aspects of  servers of which you should be
aware.   First, servers in the same category (say, file servers)  do not always
accept the same commands.   Many of  them are extremely different.   Others are
just different enough to be annoying.   There are many approaches to setting up
a server, and everyone is trying to build a better mousetrap.
 
The second  problem is  that there  are many  servers that fill  two, sometimes
three categories of server.  For example, LISTSERV works as a list server and a
file server. Many LISTSERVs have been modified to act as user directory servers
as well.  If you don't  understand this  terminology, bear with  us.   The best
is yet to come...
 
 
 *********
*         *  Servers and Services
*         *
*         *  Part 2
*         *
*         *  File Servers
 *********
 
 
Remember that a server runs on a userid much like yours.   Like your userid, it
has many capabilities, including the ability to store files.   The program that
a file server runs enables it to send you files from its directory,  as well as
a list of files available.  These may be programs or text files.   Those of you
with PCs and modems would liken these servers to dial-up bulletin boards.
 
You will generally send  three types of commands to a  file server.   The first
type is  a request for  a list of  files the server  offers.   The second  is a
request that  a specific file  be sent to your  userid.   The third,   and most
important is a HELP command.
 
The HELP command is  very important because it is one of  the few commands that
almost all  servers accept,  no  matter what  the type.   Because  the commands
available differ from server to server, you will often find this indispensable.
Sending HELP to a server will usually result  in a message or file sent to your
userid listing the  various commands and their syntax.    You  should keep some
documentation handy until you are comfortable with a particular server.
 
To request a list  of files from a server,  you will usually  send it a command
like INDEX or  DIR.   The list of  files will be sent  to you via mail  or in a
file.  For example:
 
     VM/CMS:      TELL LISTSERV AT BITNIC INDEX
     VMS/JNET:    SEND LISTSERV at BITNIC "INDEX"
 
To request a specific file from the list  you receive,  you would use a command
like GET  or SENDME.    For example to  request the  file BITNET  USERHELP from
LISTSERV at BITNIC you would type on of the following:
 
     VM/CMS:      TELL LISTSERV AT BITNIC SENDME BITNET USERHELP
     VMS/JNET:    SEND LISTSERV at BITNIC "SENDME BITNET USERHELP"
 
In many cases the files are  organized into subdirectories or filelists.   This
can make requesting a  file more complicated.   As always,  this  makes it even
more essential  that you  keep documentation about  a particular  server handy.
Some file servers offer  programs that you can run which  will send commands to
the server for you.
 
 
 *********
*         *  Servers and Services
*         *
*         *  Part 3
*         *
*         *  User Directory Servers
 *********
 
 
User directory servers are offered for two  reasons:  One is to help you locate
the network of address of a specific  individual.   Another is to help you find
people in BITNET with various interests.  You might call them the "phone books"
of the network.
 
There are a number of user directory servers in BITNET.   Unfortunately, few of
them accept the same commands or respond in the same way.   Worse,  there is no
guarantee that an individual you are looking  for is registered on a particular
user directory server.   There is (as yet)  no central user directory server or
requirement for people to be registered in one.
 
Given these  problems,  you might  wonder what good  these servers are  at all.
They are disparate, disorganized, and often difficult to access.   However,  if
you have a  good idea of who  or what you are  looking for they can  be useful.
For example, let's say I am looking for the network address of Scott Free.   He
may  or  may not  be  registered  with  one  of many  user  directory  servers.
Searching  all of  them would  be  time-consuming,  considering  the number  of
servers.  However, this time I'm lucky, because I have some information:
 
     1.  Scott Free goes to Drew University.
     2.  The nodename for Drew is DREW.
     3.  There just *happens* to be a user directory server at Drew.
 
The lucky  point here  is that  Drew University  has a  user directory  server.
There  is a good chance that Scott may be  registered there.    I retrieve  the
documentation for NAMESERV at DREW (remember the HELP command?) and send a query:
 
     VM/CMS:      TELL NAMESERV AT DREW SEARCH/NAME Scott Free
     VMS/JNET:    SEND NAMESERV at DREW "SEARCH/NAME Scott Free"
 
Unfortunately,  there is no entry for "Scott Free"  and I am stuck.   I call up
Scott and ask him for his network address.   However, just because Scott didn't
register  himself with  the  server doesn't  mean  you  shouldn't.   Some  user
directory servers allow people at other  nodes to register themselves.   Others
do  not.    At this  point  we  recommended  that  you register  yourself  with
UMNEWS at MAINE  (the  Bitnauts  List),   a NETSERV  user  directory  server,   or
NAMESERV at DREW.    More information  on  these servers  is  available in  BITNET
SERVERS and via their HELP commands.   I'll  use NAMESERV at DREW as an example of
how user directory servers take your  registration.   However,  you should note
that these commands are specific to this server.  The syntax to register myself
would be:
 
     VM/CMS:      TELL NAMESERV AT DREW REGISTER first last keywords
     VMS/JNET:    SEND NAMESERV at DREW "REGISTER first last keywords"
 
For example:
 
     VM/CMS:      TELL NAMESERV AT DREW REGISTER Chris Condon cars money
     VMS/JNET:    SEND NAMESERV at DREW "REGISTER Chris Condon cars money"
 
I entered only two keywords there ("cars" and "money") but I could have entered
as  many  as five.    These  are  useful  when  people make  searches  not  for
individuals but for groups of people with the same interests.   For example, if
I were looking on NAMESERV at DREW for people with an interest in "money", I would
have used a command like this:
 
     VM/CMS:      TELL NAMESERV AT DREW SEARCH/FIELD MONEY
     VMS/JNET:    SEND NAMESERV at DREW "SEARCH/FIELD MONEY"
 
 
 *********
*         *  Servers and Services
*         *
*         *  Part 4
*         *
*         *  Forums, Digests, and Electronic Magazines
 *********
 
 
The idea of mailing  lists has been given new life with  the advent of computer
networks.   Most of us are on mailing lists, be they for magazines,  bills,  or
those silly  pamphlets you get  from your  Senator.   Computers have  brought a
whole new degree of speed and functionality to mailing lists,  as you will see.
In BITNET,  mailing lists are used mainly to keep people with similar interests
in contact.   There are  several formats in which this contact  can take place.
These are "forums", "digests", and "electronic magazines".
 
FORUMS are a good example of how the utility of mailing lists has been expanded
in BITNET.  Let's say that you have subscribed to a forum for people interested
in COBOL (gack!).    How you could subscribe  to such a list  will be described
later.   Someone (anyone!) on the mailing list sends mail to a server where the
list is kept.  This server forwards the mail to all of the people in the forum.
When mail from a forum arrives in  your computer mailbox,  the header will look
much like this:
 
 
     Date:         Fri, 10 Sep 88 23:52:00 EDT
     Reply-To:     COBOL Discussion List <COBOL-L at METRO>
     Sender:       COBOL Discussion List <COBOL-L at METRO>
     From:         Ted Kord <BEETLE at JLIVM>
     Subject:      No More Perform-Through-Varyings!
     To:           Daniel Lawrence Shaw <DANIEL at YALEVM>
     ========================================================================
 
 
This looks a  little confusing,  but there  really isn't much to  it.   In this
example, Ted Kord ("From:") sent mail to the COBOL-L list address.  This server
then forwarded  the mail to everybody  on the list,  including  Daniel Lawrence
Shaw ("To:").    Note the line named  "Reply-To:".   This line tells  your mail
software that  when you  reply to  the note  that the  reply should  go to  the
list...  meaning *everybody* on  the list.   People will in turn  reply to your
mail, and you have a forum.
 
This is usually very  interesting,  but it can lead to  problems.   First among
these is  the volume of  mail you can  receive.   If you  are in a  very active
forum,  you can get 50 or more pieces  of electronic mail in a single day.   If
you are  discussing a  controversial or emotional  topic,  expect  more.   Many
people have a tendency to "flame".   The speed and immediacy of electronic mail
makes it very easy to whip out  a quick,  emotional,  response,  to which there
will be similar replies.    We advise you to take some time  and think out your
responses to forum postings before inadvertently starting a "flame war".
 
DIGESTS provide a partial solution to the these problems.   In this case,  mail
that is sent to a mailing list is stored rather than sent out immediately.   At
some point a  the "Moderator" for the  list organizes and condenses  all of the
correspondence for the day  or week.   He then sends this out  to the people on
the mailing list in one mailing.
 
The drawback with this  setup is that it requires a  lot of human intervention.
If the  moderator gets  sick,  goes  on vacation,   or quits,   activity for  a
particular digest can come to a screeching halt.
 
ELECTRONIC MAGAZINES  take the digest concept  a step further.    These mailing
lists actually mimic the organization and  format of "real" magazines.   BITNET
is used as a convenient and inexpensive distribution method for the information
they contain.    The frequency of  distribution for these  electronic magazines
ranges from weekly to quarterly to whenever-the-editor-feels-like-it.   This is
the most formal,  structured form  of BITNET  communication.  Where a digest is
simply a group of letters  organized by  topic, an electronic magazine includes
articles,  columns, and features.  Perhaps the  only feature of paper magazines
that they do *not* include is advertisements.
 
 
 *********
*         *  Servers and Services
*         *
*         *  Part 5
*         *
*         *  List Servers
 *********
 
 
In the previous section  we mentioned servers that are used  to control mailing
lists.   As you might guess,  a server  that performs this function is called a
"list server".    Most of these have  the terribly original userid of LISTSERV.
One of these servers can control subscriptions to many mailing lists.
 
The most  difficult concept  behind list  servers is  the difference  between a
LISTSERV and  its list-ids.  When you subscribe to a mailing list, you send the
appropriate command to a LISTSERV.   When you want to communicate to the people
on the mailing list,  you send mail to  the list-id.   For example,  there is a
list named LIAISON.   To  subscribe to this list,  you would  send a command to
LISTSERV at BITNIC.  You could then correspond with people on that mailing list by
sending mail to LIAISON at BITNIC.
 
LIAISON is a list-id,  a "satellite" of the LISTSERV.   We mention this because
many people make  the mistake of sending  commands by mail to  list-ids.   This
annoys people to no end and creates a lot of unnecessary network traffic.
 
To subscribe to a lists,  you would send a LISTSERV a SUBSCRIBE command,  which
has the following syntax:
 
     SUBscribe listname your_full_name
 
In  this example,   Kristen  Shaw is  sending  LISTSERV at BITNIC  the command  to
subscribe to LIAISON:
 
     VM/CMS:      TELL LISTSERV AT BITNIC SUB LIAISON Kristen Shaw
     VMS/JNET:    SEND LISTSERV at BITNIC "SUB LIAISON Kristen Shaw"
 
If you misspell your name when entering a SUBscribe command,  simply re-send it
with the correct spelling.   To delete her name from the mailing list,  Kristen
would enter an UNSUBscribe command:
 
     VM/CMS:      TELL LISTSERV AT BITNIC UNSUB LIAISON
     VMS/JNET:    SEND LISTSERV at BITNIC "UNSUB LIAISON"
 
Those are  the basic  commands you  need to  know in  order to  access LISTSERV
controlled mailing lists.  However, LISTSERV has a multitude of features, so we
(of course) encourage you to read the LISTSERV documentation.
 
*NOTE*  If you are on a VAXcluster, you  should send  SUBSCRIBE and UNSUBSCRIBE
commands to LISTSERV via MAIL.
 
 
 *********
*         *  Servers and Services
*         *
*         *  Part 6
*         *
*         *  Relays
 *********
 
 
Relay might be one of the tougher types of servers to understand.   If you have
used the CB Simulator  on CompuServe you will catch on  to the concept quickly.
The idea behind Relay is to allow more than two people to have conversations by
interactive message.   Without Relay-type servers,  this would not be possible.
Let's set up a scenario:
 
Kristen, Daniel, and Rebecca are at different nodes.   Any two of them can have
a conversation through BITNET.    If the three of them want  to talk,  however,
they have a problem.   Daniel can send Rebecca messages,  but Kristen can't see
them.   Likewise, Kristen can send Daniel messages,  but then Rebecca is in the
dark.  What they need is a form of teleconferencing.  Hence, Relays.
 
Each of these  users "signs on" to a  nearby Relay.   They can  pick a channel,
much like  a CB.    Instead of sending  his   messages  to Kristen  or Rebecca,
Daniel sends  his messages  to the  Relay.   The  Relay system  then sends  his
messages to *both* Kristen and Rebecca.  The other users can do the same.  When
they are done talking, they "sign off".
 
Relays can distinguish commands from the text of your messages because commands
are  prefixed with  a slash "/".  For example, a HELP  command would  look like
this:
 
     VM/CMS:      TELL RELAY AT UTCVM /HELP
     VMS/JNET:    SEND RELAY at UTCVM "/HELP"
 
A message that is part of a conversation would be sent like so:
 
     VM/CMS:      TELL RELAY AT UTCVM Hello there!
     VMS/JNET:    SEND RELAY at UTCVM "Hello there!"
 
When you first start  using Relay,  you must register yourself  as a Relay user
using the /SIGNUP or /REGISTER commands:
 
     VM/CMS:      TELL RELAY AT UTCVM /REGISTER Daniel Shaw
     VMS/JNET:    SEND RELAY at UTCVM "/REGISTER Daniel Shaw"
 
You can  then sign  on.   You  can use  a nickname,   much like  CB users  have
"handles".   In the following example, someone is signing on to channel 10 with
a nickname of "Fuzzyman":
 
     VM/CMS:      TELL RELAY AT UTCVM /SIGNON Fuzzyman 10
     VMS/JNET:    SEND RELAY at UTCVM "/SIGNON Fuzzyman 10"
 
You can then start sending the Relay the text of your messages:
 
     VM/CMS:      TELL RELAY AT UTCVM Good evening.
     VMS/JNET:    SEND RELAY at UTCVM "Good evening."
 
Relay messages will appear  on your screen like this.   Note  the nickname near
the beginning  of the message.   When  you send conversational messages  to the
Relay, it automatically prefixes them with your nickname when it forwards it to
the other users:
 
     FROM UTCVM(RELAY): <Argyle> Hello Fuzzyman.
 
You can find out who is on your channel with a /WHO command.   In the following
example, someone is listing the users on Channel 10.
 
     VM/CMS:      TELL RELAY AT UTCVM /WHO 10
     VMS/JNET:    SEND RELAY at UTCVM "/WHO 10"
 
The response from the Relay would look like this:
 
     FROM UTCVM(RELAY): Ch   UserID @ Node      Nickname
     FROM UTCVM(RELAY): 10  BONJJ524 at CCNYVME  (   Karl   )
     FROM UTCVM(RELAY): 10  UARE6641 at NDSUVM1  (  Buzzard )
     FROM UTCVM(RELAY): 10  QNDIPC41 at HENTHT5  ( Wandjina )
     FROM UTCVM(RELAY): 10    BITLIB at YALEVM   ( Fuzzyman )
     FROM UTCVM(RELAY): 10  EETDEE60 at JLIVM    (  Dr_Fate )
     FROM UTCVM(RELAY): 10  PSYUY948 at WATDCS   ( John_Cage)
     FROM UTCVM(RELAY): 10     BECCA at YALEVM   (  Rebecca )
     FROM UTCVM(RELAY): 10    EDTCAI at CORNELLA ( Nightwing)
 
When you are done with your conversation, you can sign off the Relay:
 
     VM/CMS:      TELL RELAY AT UTCVM /SIGNOFF
     VMS/JNET:    SEND RELAY at UTCVM "/SIGNOFF"
 
There  are  several  commands for listing  active  channels,   sending  private
messages, and so on.  When you first register as a Relay user, you will be sent
documentation.  You can also  get this information with the /INFO command.   To
determine  which  Relay  serves  your  area,  send any  of the Relays listed in
BITNET SERVERS the /SERVERS command.  Also, because of BITNET message  and file
traffic limits, many Relays are only available during the evening and weekends.
 
 
 *********
*         *  Beyond BITNET
*         *
*         *  Part 1
*         *
*         *  Other Networks
 *********
 
 
BITNET, as you probably  know, is not  the only computer  network in the world.
What you might  be startled to find out, however, is  that when you have access
to BITNET you also  have access to many other  networks as well. Unfortunately,
the methods  for communicating  with people in these  other networks are not as
diverse or simple as  the ones described earlier.  This aside,  BITNET links to
other networks  give you access  to people  and services you  couldn't  contact
otherwise (or at least without great expense).  That alone should make learning
a bit about them worthwhile.
 
Earlier on we  compared BITNET  nodenames to state  abbreviations.  We can take
that a  step further by  thinking of  BITNET  as a country.  The links  between
nodes (the "states") might be the highway system. Another network (a "country")
is connected to our highway system  at one point, which is  called a "gateway".
The guards (software) at  the border are not  particularly  smart and will only
let through mail.  Interactive messages and plain files can't get through.
 
The people in these other networks have addresses just like yours, but you need
to specify something extra in order to get mail to them.  A userid at node address
is not enough, because  that doesn't tell the BITNET mail software what network
that node is in.  Therefore, we can extend the network address with a code that
identifies the  destination  network.  In this example, the destination network
is ARPANET, the code for which is ARPA.
 
 
                 BECCA at SRI-NIC.ARPA
                 +---- +------ +---
                 |     |       |
                 |     |       +-------------------- the network
                 |     |
                 |     +---------------------------- the node
                 |
                 +---------------------------------- the userid
 
 
That is  about as  simple as an address  from another  network gets.  Generally
they  are  more complex.  Because  of the variety  of networks there can  be no
example which  will show  you what  a "typical" address might be.  However, you
shouldn't  have to let it  worry you too much.  If someone  tells  you that his
network address is CONDON at VENUS.YCC.YALE.EDU, just  use it like  that with your
mail software.  As long as  you understand  that  the mail is  going to another
network and that  the transit time  will be longer than  usual, you should have
few problems.
 
 
 *********
*         *  Beyond BITNET
*         *
*         *  Part 2
*         *
*         *  More on Gateways
 *********
 
 
We talked  a little about gateways in the previous section, but  didn't  get in
to too much detail.  This is  because the subject  can get a little  complex at
times.  Or  rather,  understanding  gateways isn't  difficult, but interpreting
network addresses that use them can be.
 
In our previous example, an address for  someone in another network looked like
this:
 
 
                 BECCA at SRI-NIC.ARPA
 
 
This address  tells your  networking  software  that your  letter should  go to
someone in another network.  What you might not realize is that your networking
software  "knows"  that  the address  for the gateway  to ARPA may be  at, say,
JLIVM.  It might extend the address to look something like this:
 
 
                 BECCA%SRI-NIC.ARPA at JLIVM
                 +---- +------ +--- +----
                 |     |       |    |
                 |     |       |    +--------------- the node of the gateway
                 |     |       |
                 |     |       +-------------------- the network
                 |     |
                 |     +---------------------------- the node
                 |
                 +---------------------------------- the userid
 
 
The gateway is a server machine (userid at node) that transfers files  between the
two  networks.  In  this case,  it is  ARPA at JLIVM.  Note that  the "%" replaces
the "@" from  our previous example.  This is because BITNET networking software
cannot handle addresses with more than one AT sign (@).  When your mail gets to
the gateway the  "@JLIVM" would  be stripped  off, and the "%" would  be turned
back into a "@".
 
If this is so automatic, why do you need to know this?   Because in  many cases
your  networking  software is  not smart  enough to know  that the gateway  for
IZZYNET is at BLEGGAVM.  If this is the case, you  have  to type  out the whole
address with all of the interesting special characters.
 
In many cases gateway to a network may be in another network.  In this example,
we are  sending mail to  MICKEY at  node PLUTO  in SHOENET.  The gateway to the
network  is in, say, ARPAnet.  Our  networking software is smart enough to know
where ARPA gateway is, so the address would look something like this:
 
 
                 MICKEY%PLUTO.SHOENET at SRI-NIC.ARPA
                 +----- +---- +------ +------ +---
                 |      |     |       |       |
                 |      |     |       |       +----- the network of the gateway
                 |      |     |       |
                 |      |     |       +------------- the node of the gateway
                 |      |     |
                 |      |     +--------------------- the network
                 |      |
                 |      +--------------------------- the node
                 |
                 +---------------------------------- the userid
 
 
As you can see, these addresses can get pretty long and difficult to type.  The
only consolation is perhaps that your address probably looks just as bad to the
people in the destination network!
 
 
 *********
*         *  In Conclusion
*         *
*         *  Part 1
*         *
*         *  Suggested Reading
 *********
 
 
Don't stop here. This document was written to get you started as a BITNET user,
but there is quite a bit more that you can read to use the network to  its full
potential.
 
First  of all,  I  recomend that  you look over BITNET SERVERS, the list of all
the  different servers  and services in BITNET.  Likewise,  I suggest  that you
subscribe to  NetMonth.  Instructions  on  how to get  these files  are located
at the end of this document.  Per usual, all of these files are free.
 
It  goes  without  saying  (but I'll  say it  anyway) that you  should read the
documentation for whatever servers you try to use, even  if you only  look over
a simple list of commands.  It's better than nothing.
 
Below  are listed some files from the NETINFO FILELIST on LISTSERV at BITNIC which
will  provide  further  information on  some of the topics I went over earlier.
You can get them by sending the following  command to  LISTSERV at BITNIC via mail
or interactive message:  SENDME filename filetype.  For example:
 
     SENDME MAIL MANNERS
 
CHAT ANALYSIS -  This  is the  original  document  by  Henry  Nussbacher  which
explained why  old-style Chat machines   were a  danger to  the network.   This
controversy prompted the develpment of Relay.
 
BITNET CHARTER - The original BITNET Charter.
 
BITNET OVERVIEW - A short document explaining the purpose of BITNET.
 
MAIL MANNERS - Must reading!!!!  This document explains  the dos and  don'ts of
using electronic mail in BITNET (or any other network for that matter!).
 
INFOREP LISTINGS - Each  BITNET  site  has a  person  who  is  responsible  for
distributing information about the network and helping out users (the Inforep).
If you don't know who your Inforep is, this document will tell you.
 
LISTSERV GROUPS  -  A list of all the  different  mailing lists  available  via
the BITNET LISTSERVs.
 
ARPANET SIGS* - (ARPANET SIGS01, etc.)  This is a list of all the mailing lists
in  the  Internet, including  many from  BITNET.  There  is a certain amount of
overlap between these files and LISTSERV LISTS.
 
 
*******************************************************************************
 
To receive the latest version of BITNET USERHELP, send the following command to
NETSERV at BITNIC, LISTSERV at MARIST, or LISTSERV at CMUCCVMA via mail or message:
 
     GET BITNET USERHELP
 
Likewise, you  can get the  latest version  of BITNET SERVERS by sending one of
those servers the command GET BITNET SERVERS.
 
If you want to get updates to BITNET USERHELP and BITNET SERVERS automatically,
subscribe  to NetMonth  magazine, "The Independent Guide to BITNET".  It is, of
course, free.  To subscribe, send the following command to LISTSERV at MARIST:
 
     SUBSCRIBE NETMONTH your_full_name
 
For example:
 
     SUBSCRIBE NETMONTH Danny Shaw
 
*******************************************************************************
 
      This document (c) 1988 Christopher Condon and Yale Computer Center
 
*******************************************************************************
 
A publication of the BITNET Services Library              "Because We're Here."
 



More information about the Bioforum mailing list