|
|
|
|
|
|
|
|
NetMonth, November 1987
* * * * *
** * ** ** *
* * * * * * * * * * *
* * * ***** ******* * * * ***** ****** ******* ******
* * * * * * * * * * * * * * *
* * * ******* * * * * * * * * * *
* ** * * * * * * * * * * *
* * ****** * * * ***** * * * * *
* *
* The guide to BITNET servers and services *
* *
* Volume 2 Number 5 November 1987 *
* *
*****************************************************************
* *
* Editor: Chris Condon CONDON@YALEVM *
* NetMonth Staff Supervisor: Gary Moss MOSS@YALEVM *
* *
*****************************************************************
* *
* It was the spring of 1981. In Manhattan and New Haven a pair *
* of modems were brought to life, and data began to flow over a *
* leased telephone circuit between the computing centers of the *
* City University of New York and Yale University. A bold *
* experiment had begun that over the next several years would *
* grow link by link into a worldwide network of academic *
* computers. BITNET started with only a single wire, but with *
* the inspired vision of a global community of scholars, *
* sharing research, ideas, and information. Few at t he time *
* believed that such a network, based on cooperation among *
* academic institutions, would ever succeed. At least two *
* individuals believed that it would. Ira H. Fuchs, then vice *
* chancellor for University systems at CUNY, had seen a network *
* within the IBM Corporation grow worldwide, interconnecting *
* not only programmers but researchers and managers. This *
* network, called VNET, spread among IBM sites using standard *
* IBM software and leased telephone lines, with each new link *
* responsible for its connection to the network. Together, *
* Fuchs and Greydon Freeman, then director of the Yale Computer *
* Center, saw in this model enormous potential for *
* communications among institutions of higher education: *
* administrators, faculty, and even students could use such a *
* network to share information. Fuchs and Freeman envsioned *
* more than CUNY and Yale sharing computer data. Nothing in *
* the network software restricted the communications to *
* computer programs. Increasingly, universities were beginning *
* to view the computer as a tool for for processing information *
* and text as well as number crunching... *
* *
*****************************************************************
* *
* From "BITNET: Past, Present, and Future" *
* by Daniel J. Oberst and Sheldon B. Smith *
* *
*****************************************************************
1
*************************************************************************
* Contents *
***************************************************************************
Bitnotes ................................................................ 1
Scuttlebut .............................................................. 2
FEATURES___________________________________________________________________
Internet-BITNET Gateways ................................................ 4
Relay, Bitnic, and Christmas ............................................ 8
Finding People in Other Networks ....................................... 12
SERVERS AND SERVICES_______________________________________________________
A New Name Server: LOOKUP@RITVM ........................................ 13
New Mailing Lists ...................................................... 14
DEPARTMENTS________________________________________________________________
Feedback ............................................................... 17
Policies ............................................................... 18
NetMonth is a network service publication distributed free of charge to
students and professionals in BITNET and other networks. This magazine and
it's companion file, BITNET SERVERS, are the work of the Yale Computer
Center BITNET Services Library (BITLIB) staff. The BITLIB is a local
online help facility designed to inform Yale network users about what
services are available to them through BITNET, and provide instructions
and utilities for their proper use. In publishing NetMonth the BITLIB
staff members hope to share the fruits of their labor with institutions
outside of Yale in order to promote a productive and enjoyable networking
environment for everyone. The BITLIB system is now distributed to more than
thirty educational institutions worldwide.
BITNET SERVERS is BITNETs most complete and up-to-date list of servers
and services. It is sent to NetMonth subscribers at the same time as the
magazine. BITNET SERVERS is dependent on your support to remain accurate.
If you know of servers and services not listed in BITNET SERVERS, or of
those listed in the file that are no longer available, please contact the
NetMonth staff at BITLIB@YALEVM.
For information on subscribing to NetMonth and BITNET SERVERS, see the
"Policies" section on the last pages of this issue. Within "Policies" there
are also instructions for submitting articles, sending Letters to the
Editor, and printing this file.
--------------------------< Distribution: 1765 >---------------------------
A publication of the Bitnet Services Library "Because We're Here."
1
Page 1
*************************************************************************
* Bitnotes Issue 16 *
***************************************************************************
* And now for something completely different...
...and more of the same. There is little need for me to repeat what I
have mentioned too many times before. BITNET is changing and growing day
by day, and yet it remains recognizable. More important, your needs have
changed and grown with the network. NetMonth should reflect those changes.
NetMonth began as a weekly list of servers and services known as Bitlist.
The need for more in-depth information on this subject became apparent, and
the current magazine came into being: "The monthly guide to BITNET servers
and services." That caption was a guideline for what should be included in
each issue. Now, I offer you a new caption for a new NetMonth:
"The independent guide to BITNET"
How will this new NetMonth differ from the old? This changed magazine will
include information on all issues of relevance to the network, be it news
about servers and services, tips for using the network more effectively, or
editorials by the network users.
Here are some of the new features I'd like to include:
1. A "Question and Answer" section. I may not know the answer, but I'll
find someone who does!
2. An "Editorial Page" featuring regular and irregular columnists from
different areas of the network, both physical and virtual.
3. A monthly spotlight on a network outside of BITNET with instructions for
how to send mail to people there.
In order to achieve all this there is a catch: We will need your
contributions more than ever. We will need questions for the Question and
Answer section. We will need writers for the Editorial Page. Yes, let's
make it official:
WANTED: Bright people with any range of BITNET experience needed
to write monthly columns about any network-related topic.
Applicants should posess at least passable writing skills.
Editorials do not have to be long ( 1 to 3 pages) and may be
serious, humorous, or anything in between. People who are unable
to contribute regularly are welcome to submit anything they can,
whenever they are able. There is no pay, but visibility is high.
1
Page 2
Now, I know that you are busy people. However, if I can find the spare
time to put together the magazine, couldn't you find a little to write
something? Many of you have a wealth of information and understanding
about the technical aspects of the network that I do not yet understand.
All of you have a different insight, and contrasting opinions. This is one
of the things that makes BITNET an interesting place environment in which
to work and play; I want to reflect that in NetMonth.
Also, a question: What would your reaction be to a NetMonth published on
paper and delivered by your postman? I am, of course, speaking of a
desktop-published newsletter with attractive fonts and graphics. Would a
format like that make you more or less likely to contribute?
Next month: A new format, a new design, a new NetMonth...
*************************************************************************
* Scuttlebut *
***************************************************************************
* Relay at TCSVM shut down: Wendel Bordelon and John Voigt of TCSVM issued
the following statement: "Well - it has finally happened. We have shut
RELAY down. Reason: Load on our system. Last night We were getting
better response from the RELAY at Aggieland than the one here. There were
over 140 users on 57 channels. Many of the private channels had only 1
user signed on.
"Recommendation: Limit number of public channels to 10. Limit number of
users per channel to 6. Eliminate /m command. If you want to send a
private message don't use RELAY to do it. It doesn't save any network
bandwidth and just causes extra overhead in RELAY. Limit number of private
channels. Allow the same number range (or use names(make Phil happy)) but
limit how many can be created. Kick off users on a private channel by
themselves at the next clock tick check.
"If RELAY at TCSVM is to come back we have to make RELAY something that is
worthwhile and useable. No one should have to live with the kind of
response time that RELAY provides when that many users are on. I find it
very hard to hold a conversation with 19 other users. That's how many were
on channel 1 last night. This has got to be corrected."
* BITNET-Internet Gateways announced (from Bitnews): The City University
of New York, Princeton University, Cornell University, and Massachusetts
Institute of Technology have each committed to provide gateway service for
electronic mail between the BITNET network and the Internet.
1
Page 3
Current gateway services provided by the University of Wisconsin (WISCVM)
will end on December 15, 1987. Prior to that date, at least two of the
above announced gateways will be in operation in parallel with WISCVM -
there will be no interruption in gateway services.
Prior to a regionalization plan and significant coordination with the
Internet, the most expeditious approach is to name the first few gateways
the same, namely, INTERBIT. That would mean that any gateway-destined mail
that landed at any INTERBIT node would be appropriately handled. This
change will be reflected in the December DOMAIN NAMES file which is used
for MAILER generation; users need not do anything - mail will go
automatically to the closest gateway. This is a transition measure
necessitated by the time frame, by the complexity of more desirable
solutions, and by the need to coordinate more with the Internet.
Plans are to regionalize gateway service between the networks in order to
balance traffic flow and increase reliability. Several other institutions
are seriously considering functioning as gateways. An analysis of
topologically best locations for such gateways will be conducted under the
auspices of the BITNET Board of Trustees' Technical Committee; and the
BITNET Network Information Center will coordinate regionalization plans and
associated software modifications.
See also in this issue: BITNET-Internet Gateways.
(Please note reference to Internet, rather than ARPANet, and Internet's
inclusion of ARPANet, NSFNet, NYSERNET and the other regional networks.)
* A warning from Malcolm Dickinson:
There is a self-propagating "virus" exec that has recently been released by
a grumpy scrooge onto BITNET. It is called "CHRISTMA EXEC".
This virus is a sneaky one. You may find it in your reader, sent to you by
a friend of yours in BITNET. If you load it from your reader and then type
CHRISTMAS, it will draw a little christmas tree on your screen, then SEND A
COPY OF ITSELF TO EVERY USERID IN YOUR * NAMES fille.
This may not seem to be so malicious, until one considers the amount of
file traffic such an exec can create. If you have 20 people in your NAMES
file, and 15 of them run the exec that gets sent to them, and each of them
has 20 people in their NAMES file, the resulting file traffic on the
network will be 320 file transfers. In the next generation it will be 6400
files, and in the next generation, 128,000 files. If the exec is spread
thoroughly without a concerted effort to stop it, a few million copies will
be flying around the net within a week, slowing file traffic immeasurably
and costing thousands of dollars in CPU time.
1
Page 4
*************************************************************************
* Internet-BITNET Gateways *
***************************************************************************
By Henry Nussbacher and Douglas Bigelow from Bitnews
Much progress has been made in BITNET toward establishing a robust
interconnection with the Internet. The following is a report on the
current gateway situation. Hopefully it will provide a stimulus and focus
for further short-term and long-term developments.
Douglas Bigelow
Chair, BITNET Board of Trustees Technical Committee
The removal of the University of Wisconsin BITNET-ARPAnet gateway
(WISCVM) on December 15th, 1987 has caused a reanalysis of the entire
gateway situation in BITNET. The Internet (ARPAnet, CSnet, NSFnet, etc.)
presents a unique problem of interconnection, due to its size. A single
gateway, albeit a simple and easy to implement solution, presents
problems of large backlogs and network congestion, both to the Internet
and to BITNET. This was proven very clearly with the Wisconsin gateway.
This paper will detail the "regional gateway" proposal, the pros and cons
of this interim solution and what steps need to be taken in the future.
I. THE BITNET SOLUTION:
The regional gateway solution states that every node is to use the
Internet gateway closest to them. The gateway id of SMTP@INTERBIT has
been decided upon as the universal gateway id that all BITNET nodes will
need to know about. The steps required to implementing "SMTP@INTERBIT"
have been:
a) register the node INTERBIT in EARN, BITNET, and NETNORTH as being
connected to node CUNYVM. This has been done. As of December 1st 1987,
most nodes have updated their tables and therefore know of the existence
of a node named INTERNET.
b) alter the DOMAIN NAMES file (the file that many sites use to
customize their mailer support to handle domain type names) to have all
Internet traffic sent to SMTP@INTERBIT (originally was SMTP@WISCVM). This
will be released to the public on the week of December 5th.
c) have more nodes create pseudo nodes called INTERBIT. The sites that
have agreed (so far) to act as regional gateways are: City University of
New York, MIT, Princeton University and Cornell University. (These were
the intiial four; other serious offers and inquires continue to come into
1
Page 5
the BITNIC.) This will be an ongoing process which will constantly
contribute to the equal distribution of Internet traffic among all
gateways. As more gateways connect, the load on CUNY and the other three
initial regional gateways should be reduced. It is expected that within
one year there will be in excess of 20 regional gateways.
d) alter the route table generation programs (in EARN and BITNET) so
that more nodes make use of end-of-path regional gateways. An example
would be MIT, which has many high volume neighbors, all of which will be
initially pointing to CUNY (which is much further away).
II. POTENTIAL PROBLEMS:
1) JES2: The JES2 Path Manager attempts to route files to any INTERBIT
node it may know of. If one is down or not available, then the JES2 Path
Manager has no qualms about routing the data to any other known INTERBIT
site. This can cause network loops. The solution to this is to define
only the CUNYVM-INTERBIT connection to all JES2 sites and not to
elaborate the alternate connections.
2) Loops: Each site receives a customized route table from BITNET's Chris
Thomas or EARN's NETSERV GENROUTS. Initially, they will all have INTERBIT
being a node connected to CUNYVM. But as more and more INTERBITs become
available, a need for customizing the route tables becomes more urgent.
Imagine the following topology:
X-A-B-C-D-E
When " X" represents an INTERBIT node, then all nodes (A-E) have their
route tables pointing to A as being the final link before INTERBIT. But
if the following were to occur:
X-A-B-C-D-E-X
then it would be foolish for nodes D and E to route their Internet files
to A; but rather they should route their data to E. In addition, node C
decides that it wishes to route its Internet traffic to E. That too is
also valid. But if for some reason node D changes its routing from E to
A, then there will be a loop between C and D. It is imperative then, that
all nodes be warned that they are not to tamper with the routing of
INTERBIT in their customized route tables. If a node has complaints about
an INTERBIT site (rejects valid BSMTP mail, garbles headers, is always
down for maintenance, etc.) and these complaints are justified, then the
INTERBIT gateway in question will be removed from the routing tables and
all neighboring sites will be assigned to another regional gateway. But
under no condition should a site decide on its own about where to route
INTERBIT traffic.
1
Page 6
Advanced nodes that need to alter their routing can change the DOMAIN
NAMES file to point away from SMTP@INTERBIT to some other regional
gateway "true userid" - like SMTP@CUNYVM, and in that way bypass the RSCS
looping problem. In general, the rule should be:
NEVER ALTER RSCS ROUTES BUT YOU CAN ALTER DOMAIN NAMES
III. PROPOSED ALTERNATE SOLUTIONS:
Customized DOMAIN NAMES: This solution would work if every node used a
mailer and the DOMAIN NAMES file. Unfortunately, there are many sites out
in BITNET, who have only the time to update their RSCS route tables and
do not wish to be bothered with another set of tables to be updated -
namely mailer tables. These sites will just latch on to the most common
gateway available to replace WISCVM, which in all probability will be
CUNYVM. This will put a large strain on CUNYVM - one that it is not
prepared to handle. Even if these sites could be convinced to route their
Internet traffic to some site other than CUNY, we run into the problem
two years from now, when there will be 50 or even 100 regional gateways
and these "small" sites will still be pointing to one of the 4 original
regional gateways. The method described in the Solution section, solves
this problem of the "lazy" node.
IV. THE INTERNET SOLUTION:
Now that we understand what needs to be accomplished from the BITNET
side, we need to also analyze what needs to be done from the Internet
side of the network. Mail originating in BITNET, that is sent into the
Internet, will have the RFC822 headers altered by the gateway to indicate
which gateway has processed the mail. Therefore, the user in the
Internet will have a valid header which will point back to the BITNET
regional gateway and from there to the destination user. Example:
user%TUCC.BITNET@VM.PRINCETON.EDU
The more major problem comes about when a user in the Internet wishes to
originate mail to a BITNET user. Here, once again, there are multiple
solutions:
1) On your own: Each site or each user will have to decide on his/her
own which regional gateway to use. They might just hardcode a known
regional gateway into their mail software and from then on, all traffic
from that Internet node will flow via that stated node. This is not an
optimal solution but it is one that works. TCP/IP does not have the
problem with network loops that RSCS has, so users user can decide on
their own which gateway is best for them.
1
Page 7
2) Create a BIT.NET domain: This is similar in concept to the INTERBIT
generic nodename. The user in the Internet would type in a user address
like:
user@GWUVM.BIT.NET or
user%VAX.OX.AC.UK@BIT.NET
and the Internet software would determine which gateway is closest via MX
records. This approach has had a mixed response from the ARPAnet.
However, most network people seem to agree that the following solution
(3) is the one toward which we should all work.
3) Register all BITNET domains in the Internet: This should actually be
viewed as a long term solution for the merging of BITNET and the
Internet. The problem with this is that every institution that wishes to
be registered in the Internet, needs to have i ts own "house" in order.
That means that each institution needs complete domain support covering
ALL nodes at that institution. If a few nodes at the institution are not
supported via domains locally or if there are two or three seperate
Ethernets that do not communicate one to the other, then the registration
of a domain type name in the Internet will not solve these problems but
rather compound them.
Once all sites are registered with SRI, then mail flowing from the
Internet can determine how to send it via the domain name server. If the
site has a direct connection to the Internet, then the data will flow
through the Internet until it reaches the correct gateway. If the site
does not have a connection to the Internet, then the data will be pointed
to one of the numerous regional gateways which will move the file over to
BITNET and from there the file will be delivered via Mailer or BSMTP.
For this solution to be most effective, all BITNET institutions should
support domain-style names for all their nodes. The RSCS nodename will
become the equivalent of an IP address, and the dotted domain address
will be transparent whether it originated in NSFnet, ARPAnet or BITNET.
Henry Nussbacher
_______-----___--______________________________________
____------------------_________________________________
_-----__-----------------______________________________
---____----__---_----_-----____________=======_________
-_____---___----_----___----________=============______
______-____----____--_____---______===============_____
_________----________-_______-_____===============_____
_______----_________________________=============______
______----_____________________________=======_________
____----_______________________________________________
__-----________________________________________________
1
Page 8
*************************************************************************
* Relay, Bitnic, and Christmas *
***************************************************************************
from the RELAY-L list
Date: Tue, 01 Dec 87 12:11:49 EST
From: Valdis Kletnieks
Dear fellow Relay Operators:
Due to recent events, I find it in the network's best interests to (at
least temporarily) shut down RELAY@CLVM (the Twilite_Zne). It is not a
decision that is coming easily to me.
The basic problems are as follows:
(1) When I posted my note about file queues last night, the file backlog
was not high. By the time Gary Moss got it, the queue at YaleVM was 450.
As of noon EST today, it is 680 and climbing. (update: It is now 12:30EST
and 760 files are queued). This is reportedly due to a gateway at MIT.
Why it is doing it, and what is being done, I have not the slightlest clue.
(2) Relay@BITNIC has been quiesced for 3 days. The Relay-L list was NOT
told why. This is about par for the course. Those who have been on this
list for a long time have seen me repeatedly flame about this point. (How
long does it TAKE to send a note that says: "We've got a rogue gateway,
we're loaded with files, we're shutting down till it's fixed.."?)
(3) I have been hit with a sudden rash of weenies, a good number of whom
should know better. The people involved know who they are... I won't
comment any more on this point.
(4) The end of the semester is coming. We will be beseiged by a CPU
crunch. This is an immutable fact.
I cannot justify the CPU resources for RELAY if the only place I can
reliably link to is YaleVM, and when our CPU is loaded, and when the
network is so overloaded, and the information (mostly idle chatting) is not
of an urgent nature. When push comes to shove, something must give. RELAY
is currently one of the lower-priority Bitnet services.
Zone is NOT being shut down because of a CPU problem. Although we DO have
a slight problem with cycles, management is willing to overlook RELAY's CPU
use during the off-prime time if it is not TOO outrageous.
The reason I pulled RELAY was because I see it as NOT worth the effort if
all it will talk to is the Yale relay.
1
Page 9
It will be restored to service as soon as it is feasible to have it
connected to the rest of the Relay network.
Unfortunately, I do not see it as surfacing before the end of next week,
given the current speed that problems are being resolved.
Also, I am still debating if I will ever resurrect it unless the problems I
have with the Bitnic relay are resolved. I cannot in good faith rely on a
relay that is (apparently) arbitrarily quiesced without warning or
explanation. Admittedly, it DOES have to be shut down if there is a large
queue in a place that it makes a difference.
However:
It *should not* shut down for files coming TO cunyvm from yalevm - it
should still come up and connect Europe and the rest of the US. Shutting
down to offload the link is Yale's problem in this case. Gary Moss was
nice enough to send a note saying what was done and why.
It *should* be announced why, and on what link the problem is on.
It *should* be woken up in a timely fashion after the queue is cleared.
If the staff at Bitnic cannot see fit to logon at 9PM and check if it
should be woken up, they should assign a few trusted masterops class 4
privs. Then they can post a note saying "689 files queued for Zanzibar.
Wait till it's under 35 before waking it up".
The other possibility is that relay at bitnic either be removed and linked
around, or have some other topology change.
To re-iterate: My problem is not a CPU problem, it's more a problem with
the way the net is managed.
Amazingly enough, I still have enough management support for RELAY that it
will not be going away. If at some time in the future, the network
improves, I will bring RELAY back online.
(End factual discussion, begin political commentary....)
When it first started out, BitNet looked like a great idea. Yesterday was
the third anniversary of CLVM connecting to Bitnet. We were 'node number
421' according to BITEARN NODES.
It is now 3 years later. 1700 more nodes have joined on. This has
provided an unprecedented ability to intercommunicate between colleges and
universities. However, some things have not kept up. We now have
internodal war about 'Bitnic vs EARN tools'. A failing link can cut off a
lot more nodes than it used to. Gateways are folding under the load.
1
Page 10
Crucial links are running further and further behind. I see 5 times the
nodes connected. I do not see 5 times the infrastructure (redundant and
higher capacity links, support personell, network information services,
network leadership).
Bitnet is in a state of chaos not unlike Rome of 300AD. The empire is
falling, but the barbarians are not pounding on the door - yet.
Date: Fri, 04 Dec 87 11:03:01 EST
From: Craig Barefield
In reply to Valdis's last mail message regarding his shutting down his
Relay, I agree with him 1000% to every point he is making.
I too am faced with a similar situation, and am considering shutting down
NYU's Relay. The only difference is that we connect directly to Bitnic
thus when they are quiesced, we are an isolated Relay.
I am also at the point where I can no longer tell the Systems programmers
at our lower level links (vaxes, etc.) not to write their own chat
machines. Once that happens, they will in effect be running PUBLIC relay-
like machines open to message traffic from ANY NODE and I WON'T be able to
stop them from doing it.
I'm sure that will wreak havoc on the network as well as my machine. Then
maybe someone will take notice of what's going on. Then on the other hand,
I think it was mentioned before that nobody from Cunyvm or Bitnic is on the
Relay-L list. Was that true? Maybe nobody will notice, maybe nobody will
care.
Date: Mon, 7 Dec 87 20:40 EST
From: John McMahon
With the advent of Relay@Bitnic going into a permanent (?) state of
comatose, and the complete lack of response from anyone who has anything to
do with the control of it, perhaps we should take some sort of action.
Let's link around Bitnic. (Ack... Blasphemy)
What I am proposing is a test re-link around Bitnic. My reasons are the
following:
a) The file queues at/around Bitnic are nonexistant. I realize Yale still
has a bunch of files sitting there, but they are handling that problem by
remaining unlinked.
b) Relay at Bitnic has not come up in several weeks as far as I can tell.
c) Noone at Bitnic seems to remember that they have a relay.
1
Page 11
I realize Bitnic's importance, and that they often have held life-and-death
over Relay. But, are they keeping up their end of the bargain ? Would we
expect the same kind of treatment from the operators at Urbana ? or
Aggieland ? or TwiliteZne ?
Date: Tue, 08 Dec 87 12:36:28 EST
From: Peter A. Klein
I understand the situation that you are in, However, I have a few simple
questions for you since you have been brave enough to step forward.
o Is it still the policy of BITNIC not to allow users from other nodes than
BITNIC and CUNYVM to have privs on service machines at BITNIC?
o Since no one at BITNIC seems to want to spend the time to look after the
relay there, can someone off node look after it?
I think that most people on this list would agree that we don't expect the
people AT Bitnic to run their relay on a day to day basis but we do expect
them to be responsible enough to make sure it is logged on and that someone
else can monitor it and make the appropriate quiesces and wake ups.
Hence, I would like to make the following proposal.
1) Make Jeff Kell the contact for the BITNIC relay (if you are up to it
Jeff) since he is the person who will live or die if relay screws up.
2) Give several currently trusted master ops class 8 privs at BITNIC and
give several regular ops class 4 privs. The idea behind the class 8 privs
is to allow responsible parties to change the relay's basic operating
parameters when things like file queues, etc... come about. The reason for
class 4 privs is to allow less trusted operators to also watch after the
BITNIC relay. It is my suggestion that two people from each major link off
of BITNIC be given these privs to allow for link failures and the like.
Finally, these ops should be chosen by Jeff since again he is the person
who will live or die if relay screws up.
I hope this proposal or something like it is implimented soon.
__________________________________________
/ /[
/__________________________________________[/
]
] ___________________________________
] ] ] /[
] ] ]_______________________________[/
] ] /
] ]/__________________________________
] /[
]__________________________________________[/
1
Page 12
*************************************************************************
* Finding People in BITNET *
***************************************************************************
People ask me questions. Scattered within the electronic junk mail I will
find pleas for help, information, and assistance. However, the questions
are not what you would expect. There are no questions about why the Relay
is the quiesced today, or how to use a particular server, or how to send
someone a file. No, nothing as mundane or commonplace as that. The Earth-
shattering question of our times?
"How can I find out the userid of X at University of Y?"
Here then, are a number of ways to find the answer on your own:
1. Does the node have a local name server? Not many do, but if so, your
search for information should end here. BITNET SERVERS contains a list of
name servers, and BITNET USERHELP contains an explanation of how to access
them.
2. Check the larger name servers: Some name servers, such as NETSERV or
CSNEWS allow people from all over the network to register themselves. You
may find the person you are looking for listed here.
I make it a point to check the CSNEWS Bitnauts List; it seems to be one of
the more popular places for people to register themselves. If I were
searching for John Doe at YALEVM, I would send CSNEWS the following
commands:
VM/CMS: TELL CSNEWS AT MAINE BIT SEARCH Doe
TELL CSNEWS AT MAINE BIT SEARCH YALEVM
VMS/JNET: SEND CSNEWS@MAINE BIT SEARCH Doe
SEND CSNEWS@MAINE BIT SEARCH YALEVM
This way I will receive two lists: One with all the people in the Bitnauts
list with the name "Doe" (or with "Doe" as a portion of their name or list
of interests) and another lists with the people from YALEVM. The person
you are looking for might be listed there.
At this point there is a strong temptation to contact someone on the list
you just received and ask them if they know your friend John Doe. Well,
there are MANY people at each node, and the chances of someone you randomly
contact knowing Mr. Doe are quite slim. The only thing this strategy will
accomplish is annoying somebody. This is NOT proper network behavior.
3. Reach out and touch someone. If you know the phone number of the person
you want to contact, it may be simpler to call them and ask "What is your
userid@node?" This costs you some money, but saves you some time.
1
Page 13
*************************************************************************
* The Name server LOOKUP@RITVM *
***************************************************************************
LOOKUP@RITVM is a name server at Rochester Institute of Technology. You
should send commands to the server via interactive message. For example:
VM/CMS: TELL LOOKUP AT RITVM /HELP
VAX/VMS: SEND LOOKUP@RITVM /HELP
There are few actual commands for this name server. The text of your
message is the search string, although you may add certain qualifiers. The
default is to search for a particular userid. For example:
TELL LOOKUP AT RITVM POSTMAST will return information on the userid
POSTMAST:
* POSTMAST Jenny Beaven Staff 752 ISC - Technical Support
If you are looking for a specific last name, add the /NAME qualifier:
TELL LOOKUP AT RITVM BEAVEN/NAME will return all entries with the last name
of Beaven:
* JMBSYS Jenny Beaven Staff 752 ISC - Technical Support
* JMBTST J. M. Beaven Staff 752 ISC - Technical Support
* JMB1989 Jenny Beaven Staff 752 ISC - Technical Support
* POSTMAST Jenny Beaven Staff 752 ISC - Technical Support
The /FNAME qualifier work much the same way:
TELL LOOKUP AT RITVM JENNY/FNAME will return all entries with a first name
of Jenny:
* JMBSYS Jenny Beaven Staff 752 ISC - Technical Support
* JMB1989 Jenny Beaven Staff 752 ISC - Technical Support
* POSTMAST Jenny Beaven Staff 752 ISC - Technical Support
The commands /HELP and ? will return a list of commands.
+ ] +
*-[[]//-*
> +--+--+ <
*-//][[-*
+ ] +
1
Page 14
*************************************************************************
* New Mailing Lists *
***************************************************************************
386USERS@UDEL.EDU
A moderated list for Intel 80386 topics, including hardware and software
questions, reviews, rumors, etc. Open to owners, users, prospective users,
and the merely curious.
You can request the archives be sent via mail by sending a note to
386USERS-REQUEST.
All requests to be added to or deleted from this list, problems, questions,
etc., should be sent to 386USERS-REQUEST@UDEL.EDU.
List Maintainer: James Galvin
|