informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/internet/bitnet.inf

1017 lines
44 KiB
INI
Raw Permalink Blame History

From: B_FOLEY@UVMVAX.BITNET
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
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@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@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
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@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@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
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@node
For example:
SEND/FILE BITNET.USERHELP KRISTEN@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@JLIVM> <-----+ | |
Subject: COBOL declared illegal <--------+ |
To: Kristen Maryrose Shaw <KRISTEN@MARIST> <-----------+
An entire mail message would look like this:
+---------------- Mail header
|
| Date: Fri, 10 Sep 88 23:52:00 EDT
| From: Ted Kord <BEETLE@JLIVM>
| Subject: COBOL declared illegal
| To: Kristen Maryrose Shaw <KRISTEN@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@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
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@node "command"
For example:
SEND NETSERV@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@BITNIC requesting a list of files:
Date: Fri, 10 Sep 88 23:52:00 EDT
From: Rebecca Estelle Shaw <BECCA@YALEVM>
To: Listserv <LISTSERV@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@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@BITNIC you would type on of the following:
VM/CMS: TELL LISTSERV AT BITNIC SENDME BITNET USERHELP
VMS/JNET: SEND LISTSERV@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@DREW (remember the HELP command?) and send a query:
VM/CMS: TELL NAMESERV AT DREW SEARCH/NAME Scott Free
VMS/JNET: SEND NAMESERV@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@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
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@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"
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@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@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@METRO>
Sender: COBOL Discussion List <COBOL-L@METRO>
From: Ted Kord <BEETLE@JLIVM>
Subject: No More Perform-Through-Varyings!
To: Daniel Lawrence Shaw <DANIEL@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@BITNIC. You could then correspond with people on that mailing list by
sending mail to LIAISON@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@BITNIC the command to
subscribe to LIAISON:
VM/CMS: TELL LISTSERV AT BITNIC SUB LIAISON Kristen Shaw
VMS/JNET: SEND LISTSERV@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@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@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@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@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@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): <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@UTCVM "/WHO 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:
VM/CMS: TELL RELAY AT UTCVM /SIGNOFF
VMS/JNET: SEND RELAY@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@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@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@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@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@JLIVM
+---- +------ +--- +----
| | | |
| | | +--------------- 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 "@".
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@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@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@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@BITNIC, LISTSERV@MARIST, or LISTSERV@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@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."
Reference in New Issue View Git Blame Copy Permalink