Document for beginners using BITNET

Found at: 0x1bi.net:70/textfiles/file?internet/bitnet.inf

Subject: Document for beginners using BITNET
From:   IN%"BIO-NAUT@IRLEARN.UCD.IE" 15-OCT-1990 02:49:18.61
Subj:   BioBit No 17 (Bitnet for the complete idiot)
         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 BIONAUT.... 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
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
note to the author, Christopher Condon, at address BITLIB@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
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
     2.   Servers and Services
          What the Heck is a Server, Anyway?
          File Servers
          User Directory Servers
          Forums, Digests, and Electronic Magazines
          List Servers
     3.   Beyond BITNET
          Other Networks
          More on Gateways
     4.   In Conclusion
          Suggested Reading
*         *  Tools for Communication
*         *
*         *  Part 1
*         *
*         *  BITNET for the Compleat Idiot
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
You should also  be a little  familiar with the type  of hardware and operating
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
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
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
n this network.  The rest of you, however, don't need to know the gory details
n 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
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
California will store and forward it from computer to computer until it reaches
t's destination.
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:
Each of the computers  in BITNET is called a "node" and has  a unique name that
dentifies 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
     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@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@YALEVM.   If I know the userid@node of
communicate with me.   The same goes for you.    All you need to know are a few
*         *  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
mmediately (well, quickly) to its destination.   In BITNET this destination is
the network address (userid@node)  of the person  you want to contact.   If the
s  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
The  syntax to  send messages  depends on  your computer  and system  software.
     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
     SEND userid@node "message"
For example:
     SEND KRISTEN@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
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
     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
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.
     SENDFILE filename filetype filemode userid AT node
For example:
              +---------------- +----------------
              |                 |
              |                 +------- the address of the recipient
              +------------------------- the file you are sending
The syntax for VMS/JNET systems is quite similar:
     SEND/FILE filename.extension userid@node
For example:
              +--------------- +-------------
              |                |
              |                +-------- the address of the recipient
              +------------------------- the file you are sending
The file sent  is stored in  the "electronic mailbox"  of the  recipient  until
commands to process files sent to them in this way.  People on VAX/VMS  systems
nformation 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,
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
t 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
                                           The address of the recipient
                                                         The subject  |
                                                                   |  |
                                                     Your address  |  |
                                                                |  |  |
                                                   Todays date  |  |  |
                                                             |  |  |  |
     Date:         Fri, 10 Sep 88 23:52:00 EDT            <--+  |  |  |
     From:         Ted Kord                 <-----+  |  |
     Subject:      COBOL declared illegal                 <--------+  |
     To:           Kristen Maryrose Shaw  <-----------+
An entire mail message would look like this:
  +---------------- Mail header
  |  Date:         Fri, 10 Sep 88 23:52:00 EDT
  |  From:         Ted Kord 
  |  Subject:      COBOL declared illegal
  |  To:           Kristen Maryrose Shaw 
  +  ========================================================================
  +  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
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.
*         *  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
terminology might  as well be  Gaelic.   Luckily,   the concept is  really very
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
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@MARIST and
LISTSERV@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
ncluded in the document BITNET SERVERS.
     TELL userid AT node command
For example:
     SEND userid@node "command"
For example:
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
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@BITNIC requesting a list of files:
     Date:         Fri, 10 Sep 88 23:52:00 EDT
     From:         Rebecca Estelle Shaw 
     To:           Listserv 
Throughout  this document  we  will use  examples where  commands  are sent  to
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
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
s 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
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
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
mportant 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
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:
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@BITNIC you would type on of the following:
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
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
user directory server.   There is (as yet)  no central user directory server or
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
     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
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
UMNEWS@MAINE  (the  Bitnauts  List),   a NETSERV  user  directory  server,   or
NAMESERV@DREW.    More information  on  these servers  is  available in  BITNET
SERVERS and via their HELP commands.   I'll  use NAMESERV@DREW as an example of
that these commands are specific to this server.  The syntax to register myself
     VM/CMS:      TELL NAMESERV AT DREW REGISTER first last keywords
     VMS/JNET:    SEND NAMESERV@DREW "REGISTER first last keywords"
For example:
     VM/CMS:      TELL NAMESERV AT DREW REGISTER Chris Condon cars money
     VMS/JNET:    SEND NAMESERV@DREW "REGISTER Chris Condon cars money"
as  many  as five.    These  are  useful  when  people make  searches  not  for
ndividuals but for groups of people with the same interests.   For example, if
*         *  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
n 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
n BITNET.  Let's say that you have subscribed to a forum for people interested
n 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 
     Sender:       COBOL Discussion List 
     From:         Ted Kord 
     Subject:      No More Perform-Through-Varyings!
     To:           Daniel Lawrence Shaw 
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
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
makes it very easy to whip out  a quick,  emotional,  response,  to which there
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
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.
ELECTRONIC MAGAZINES  take the digest concept  a step further.    These mailing
lists actually mimic the organization and  format of "real" magazines.   BITNET
s used as a convenient and inexpensive distribution method for the information
they contain.    The frequency of  distribution for these  electronic magazines
the most formal,  structured form  of BITNET  communication.  Where a digest is
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
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@BITNIC.  You could then correspond with people on that mailing list by
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
     SUBscribe listname your_full_name
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
nteractive 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
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
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@UTCVM "Hello there!"
When you first start  using Relay,  you must register yourself  as a Relay user
using the /SIGNUP or /REGISTER commands:
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@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@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):  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.
The response from the Relay would look like this:
     FROM UTCVM(RELAY): Ch   UserID @ Node      Nickname
     FROM UTCVM(RELAY): 10  BONJJ524@CCNYVME  (   Karl   )
     FROM UTCVM(RELAY): 10  UARE6641@NDSUVM1  (  Buzzard )
     FROM UTCVM(RELAY): 10  QNDIPC41@HENTHT5  ( Wandjina )
     FROM UTCVM(RELAY): 10    BITLIB@YALEVM   ( Fuzzyman )
     FROM UTCVM(RELAY): 10  EETDEE60@JLIVM    (  Dr_Fate )
     FROM UTCVM(RELAY): 10  PSYUY948@WATDCS   ( John_Cage)
     FROM UTCVM(RELAY): 10     BECCA@YALEVM   (  Rebecca )
     FROM UTCVM(RELAY): 10    EDTCAI@CORNELLA ( Nightwing)
When you are done with your conversation, you can sign off the Relay:
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
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
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")
s 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@node address
s 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
dentifies the  destination  network.  In this example, the destination network
s ARPANET, the code for which is 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
network address is CONDON@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.
This address  tells your  networking  software  that your  letter should  go to
JLIVM.  It might extend the address to look something like this:
                 +---- +------ +--- +----
                 |     |       |    |
                 |     |       |    +--------------- the node of the gateway
                 |     |       |
                 |     |       +-------------------- the network
                 |     |
                 |     +---------------------------- the node
                 +---------------------------------- the userid
The gateway is a server machine (userid@node) that transfers files  between the
two  networks.  In  this case,  it is  ARPA@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 "@".
your  networking  software is  not smart  enough to know  that the gateway  for
address with all of the interesting special characters.
network  is in, say, ARPAnet.  Our  networking software is smart enough to know
                 +----- +---- +------ +------ +---
                 |      |     |       |       |
                 |      |     |       |       +----- 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
*         *  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
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
at the end of this document.  Per usual, all of these files are free.
a simple list of commands.  It's better than nothing.
Below  are listed some files from the NETINFO FILELIST on LISTSERV@BITNIC which
You can get them by sending the following  command to  LISTSERV@BITNIC via mail
or interactive message:  SENDME filename filetype.  For example:
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!).
LISTSERV GROUPS  -  A list of all the  different  mailing lists  available  via
ARPANET SIGS* - (ARPANET SIGS01, etc.)  This is a list of all the mailing lists
n  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
Likewise, you  can get the  latest version  of BITNET SERVERS by sending one of
those servers the command GET BITNET SERVERS.
course, free.  To subscribe, send the following command to LISTSERV@MARIST:
     SUBSCRIBE NETMONTH your_full_name
For example:
      This document (c) 1988 Christopher Condon and Yale Computer Center
A publication of the BITNET Services Library              "Because We're Here."