|
|
|
|
|
|
|
|
NetMonth, April 1987
* * * * *
** * ** ** *
* * * * * * * * * * *
* * * ***** ******* * * * ***** ****** ******* ******
* * * * * * * * * * * * * * *
* * * ******* * * * * * * * * * *
* ** * * * * * * * * * * *
* * ****** * * * ***** * * * * *
* *
* The guide to BITNET servers and services *
* *
* Volume 1 Number 10 April 1987 *
* *
*****************************************************************
* *
* Editor: Chris Condon CONDON@YALEVMX *
* Assistant Editor: Steve Sutter SUTTER@YALEVMX *
* NetMonth Staff Supervisor: Gary Moss MOSS@YALEVMX *
* *
*****************************************************************
* *
* *
* *
* Leaders are people who do the right things. *
* Managers are people who do things right. *
* There has been too much attention to doing *
* things right, and not enough emphasis on *
* doing the right thing. *
* *
* -- Warren Bennis *
* *
* *
* *
* *
* *
* *
* *
* elephant is like a wall ke a *
* An i p *
* l i l *
* a o e i *
* r f c k ake *
* o c e e n *
* p loth a s *
* e *
* *
* *
* An ele phant *
* is is lik e a t *
* mushy ree t runk *
*****************************************************************
1
*************************************************************************
* Contents *
***************************************************************************
Bitnotes ................................................................ 1
TAKE NOTE__________________________________________________________________
Scuttlebut .............................................................. 2
The PSUVM/OHSTVMA Link .................................................. 4
Global Students Network ................................................. 5
FEATURES___________________________________________________________________
Mail Manners ............................................................ 7
The BITNET Domains Task Force Report .................................... 8
SERVERS AND SERVICES_______________________________________________________
Spotlight Server: DATABASE@BITNIC ..................................... 13
New Mailing Lists ...................................................... 15
DEPARTMENTS________________________________________________________________
Feedback ............................................................... 16
Policies ............................................................... 17
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.
BITNET SERVERS is BITNET's 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@YALEVMX.
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: 820 >----------------------------
A publication of the Bitnet Services Library "Because We're Here."
1
Page 1
*************************************************************************
* Bitnotes Issue 9 *
***************************************************************************
* * *
* * *
* * *
* * *
* * * * *
* * * *
* * * * * * * * * * * * * * *
* * * * * * * *
* * * * * * * *
* * * * * * * *
* * * * * * * *
* * * * * * * *
The Bitnet Services Library (BITLIB) is an online help facility providing
Yale VM users with information on file servers, name servers, electronic
magazines, and other services. It includes specific usage information
for each server, explanations of basic concepts (such as "What is a file
server?") and a set of useful EXECs to make life with BITNET easier.
All documentation has been tailored to the VM environment.
BITLIB is currently undergoing conversion from YHELP to the new SP4
HELP facility. After the changes have been made, we would like to
make BITLIB available for installation at other nodes. Distribution and
monthly updates would be handled in the same way as Listserv and Relay.
BITLIB has been serving users at Yale since May of 1985. At this time
the we would like to monitor interest in the service. If you are
interested in installing BITLIB at your node, or would like more
information, please send mail to BITLIB@YALEVMX.
---------------------------------------------------------------------------
This announcement was posted on the LIAISON list in mid-April. Response
has been much greater than expected. Conversion to SP4 HELP has been
completed, and a beta-test site will be implemented soon.
---------------------------------------------------------------------------
There are new instructions for subscribing to NetMonth! We have finally
given in to technology and will now let LISTSERV handle subscription
requests. If you are already on the mailing list you do NOT need to
request a subscription from LISTSERV. Many thanks to A. Harry Williams for
setting up the list at MARIST.
1
Page 2
* Subscribing to NetMonth and BITNET SERVERS:
VM users can be added to the mailing list by issuing the following command:
TELL LISTSERV AT MARIST SUBSCRIBE NETMONTH Your_full_name
VAX/VMS users can subscribe in a similar way:
SEND LISTSERV@MARIST SUBSCRIBE NETMONTH Your_full_name
If you cannot send messages in this way, you can send the following command
as the first line of a mail file to LISTSERV@MARIST:
SUBSCRIBE NETMONTH Your_full_name
Arpanet users may use this method, but must address the mail to:
LISTSERV%MARIST.BITNET@WISCVM.WISC.EDU
---------------------------------------------------------------------------
They said it couldn't be done: Pending successful completion of all my
classes, I will graduate on May 16th. After that I will be going to NetCon
Spring 1987 (New Orleans) to speak on the Past and Future of BITNET. I
will still be working on BITLIB and NetMonth after these momentous events
(just in case you thought that my graduation meant that I wouldn't keep
doing this. I'm having too much fun).
Chris Condon@YALEVMX
*************************************************************************
* Scuttlebut *
***************************************************************************
The Lives and Deaths Relays:
* Thanks to Jeff Kell and Jose Flores for the notice that there is now a
Relay at UCSVM.
* This news from Jeff Kell:
Due to the withdrawal of the Relay server at NCSUVM, coupled with heavy
network traffic which prohibits reassigning the affected sites to another
server, the following nodes are being excluded from Relay service pending
establishment of another server with better placement:
APLVM ARSBARC AUVM BAGAMCOK BKNLVMS BRCVAX BUCKNELL CEBAFVAX
CUA DICKINSN DUKE* ECSVAX ECUVM1 GALLU* GMUVAX GUNBRF
1
Page 3
GUVAX GUVM GWUVAX GWUVM HUMAIN IUP JHU* JMUVAX1
JPSPHVAX LOYVAX MUSCVM NBS NCSU* NIH* NRAO NSF
ODUVM PSU* SCF* SEASVM TUCC* UC780 UDCVM UMAB
UMBC* UMCINCOM UMD* UME* UMUC UNC* UNIVSCVM USGSRESV
USUHS VCU* VIRGINIA VP* VT* WMHEG WMMVS
I am providing this information in advance in anticipation of inquiries
and/or flames from users at these sites. There is simply no way to
continue service to these sites without undue load being placed on one or
more critical hub links (CUNY-PSU, PSU-CORNELL, PSU-OHSTVMA).
The server at UWF will continue to service sites south of TUCC; the
affected region is from TUCC to PSUVM, including the area around PSUVM not
on the CUNY, Cornell, or OHSTVMA paths.
To avoid a lengthy discourse that won't change anything, accept it.
Due to network loading and the sites served by NCSUVM, it is necessary to
exclude (yes; exclude, omit, delete, no-speakie) their prior service area
until some other suitable server can be found or established. This too is
a fact which cannot be changed.
PLEASE don't post 20-30 entries of how terrible this is, how somebody
should do something, how node XYZZY should get a Relay, why can't Y2's
Relay serve them for now, etc., etc. There is nothing more to be done.
Cornell can't pick them up since it would load PSU-Cornell, Bitnic can't
pick them up since it would load PSU-CUNY, and Pittsburgh can't pick them
up since it would load PSU-OHSTVMA. And UWF can't serve the universe from
the bottom of the southeast branch of the network (nothing critical
intended -- wish I was in Florida).
We have avoided denial of service for nearly two years now, that's good
enough, but it can't last. Those of us who actually host a Relay and
donate the time (personal as well as CPU) and resources, usually going
against all odds to justify in the first place, have done quite well. NCSU
did an outstanding job... they were one of the first, Relay has a lot of
Alan's code in it, and when Cornell and Bitnic had to close the doors to
the PSU area due to CPU and/or link loading, it was NCSU that let them back
in. That very well may have contributed to their downfall in the end. And
I don't want to see any other Relays face similar cases simply because we
are *still* trying to provide service to *everyone*. I'm sure some of you
out there know what I mean (UWAVM serving half the west coast by
themselves, among others).
Well, enough of this discourse, I should hush. On with the actual mail
postings related to the event... I have to find my asbestos underwear as
I'm sure my personals are going to be flamed in the near future...
* Thanks to Tony Dahbura for the news that SERVER@SUZEUS (just announced
last month) will no longer be avaialble due to system performance problems.
1
Page 4
*************************************************************************
* The PSUVM/OHSTVMA Link *
***************************************************************************
Summary by Ross Patterson, Rutgers University
Bill Rubin, City University of New York
RSCS Incompatibilities Cause Link Backlog
We recently experienced a heavy backlog on the PSUVM/OHSTVMA link,
apparently caused when OHSTVMA installed RSCS Version 2 to replace RSCS
Version 1.3. As a result, PSUVM had to run the DMTNJI line driver on the
link, rather than on DMTVMB. Since the DMTVMB line driver is unavailable
for RSCS V2, OHSTVMA could no longer use it. Previously, this driver, used
for RSCS V1-to-RSCS V1 connections, provided performance benefits when both
ends of the link ran RSCS V1. When IBM built RSCS V2, they selected the
DMTNJI line driver as the network standard since it could communicate with
any IBM networking system as well as a number of non-IBM systems.
RSCS V1's DMTNJI line driver has weak points. For example, messages from
one user to another and commands from a user to a remote system were not
blocked. RSCS V1 sends each message or command (over a DMTNJI link) in a
separate buffer, regardless of length. Since the usual buffer size for a
DMTNJI link is 400 bytes and the maximum message/command size is 256 bytes,
resources were being wasted. Consequently, RSCS V2 programmers implemented
message blocking procedures, so that several messages could share a buffer.
Since all systems, including RSCS V1, can receive such buffers, it seemed
pointless to retro-fit this feature into RSCS V1.
A second weakness involved RSCS's preference to send messages and commands
before it sends data blocks or files. Because BITNET uses messaging
extensively, a problem began to develop when the PSUVM/OHSTVMA link was
apparently sending messages almost to the exclusion of files.
Fixes
OHSTVMA ran another RSCS V1 (called OHSTMPA) to communicate with PSUVM, so
they could both use the DMTVMB line driver. The OHSTMPA/OHSTVMA link, a
DMTNJI line, runs over a virtual Channel-To-Channel adapter, a fast
networking connection. Consequently, the problem is avoided on the slow
(PSUVM/OHSTMPA) connection, and the with the speed of the fast connection
(OHSTMPA/OHSTVMA) the problem never existed.
IBM has accepted an APAR (Authorized Problem Analysis Report) against RSCS
V1, and will modify the Version 1 DMTNJI line driver to send multiple
messages in a single buffer. When this fix is installed at PSUVM, the
PSUVM/OHSTVMA connection will be operational, and OHSTMPA will be
eliminated.
1
Page 5
Who might have this problem?
Most VM-to-VM sites, currently running the DMTVMB line driver between them,
could have this problem when only one site converts to RSCS V2. No problem
exists if both sides convert to RSCS V2. If one site converts to RSCS V2,
the RSCS V1 site should apply the APAR fix.
How can the problem be avoided?
Once the APAR fix VM27826 is tested and becomes available through IBM
Support Centers, all RSCS V1 sites should install the APAR fix.
*************************************************************************
* Global Students Network *
***************************************************************************
By Toshi Tsubo Tokyo
The Global Students Network is a student organization interested in
building a global community of students using computer networks. We feel
that such a network will help develop necessary human resources such as a
global perspective and communication skills for conflict resolution.
We plan to organize our group through a multi-media communication system
including:
o BITNET : e-mail, mailing lists gatewaying with ARPA Internet (USA), CSNET
(USA), JANET (UK), EANnet (Europe), CDNnet (Canada), COSAC (France), DFN
(Germany), ASCNET (Australia), UUCP/USENET (USA), EUnet (Europe), SDN
(Korea), JUNET (Japan).
o DASNET : e-mail, parallel conferences linking ARPANET, BITNET, BIX,
CompuServe, CSNET, EasyLink, EIES, ENET, GEnie, MCI Mail, NWI, Santa Clara
Univ, The Source, Stanford Univ, TWICS, Unison, UUCP.
o Other media : Telephone, Telex, Fax, Video and Paper.
Our group will concentrate on several projects. They will be :
o General Administration and Finance.
o Creating, maintaining and distribution a network map and a members
directory.
o Inter-networking and networking technologies.
1
Page 6
o Establishing and organizing a mailing list or other communication system
where students can interact in other language environments. This will be
called the "Multi-Language Learning Environment".
o A service to assist students in their travels and facilitate face to face
meetings.
o An electronic pen pal system for younger children using the network
established by the Global Students Network. This will be called the
"Global Kids Link".
If you are anyone you know is interesting in participating or knowing more
about this project, please write to one or more of the following addresses:
Toshi Tsubo
Central Meguro 102
2-7-10 Mita, Megruo-ku
Tokyo 153
Joichi Ito
4800 South Lake Shore Drive
Apartment 1910-S
Chicago, IL 60615
Kevin Barron, Vancouver, Canada
Bitnet: USERZABL@SFU.BITNET
PeaceNet: jito
Telemail: ŐJ.ITO/BUSCOMMĺ TELEMAIL/USA
The Source: BBJ294
NWI/PARTI: JOICHI ITO
Unison: JOICHI (partiname: JOICHI ITO)
CompuServe: 70116,502
TWICS: TSUBO (partiname: TOSHI TSUBO)
GreenNet: TOSHI
MCI mail: Toshihiro Tsubo
elephant is like a wall ke a
An i p
l i l
a o e i
r f c k ake
o c e e n
p loth a s
e
An ele phant
is is lik e a t
mushy ree t runk
1
Page 7
*************************************************************************
* Mail Manners *
***************************************************************************
From the file MAIL MANNERS, available from NICSERVE@BITNIC.
The Phenomenon of FLAMING
The following was from: Toward an Ethics and Etiquette for Electronic Mail
written by Norman Z. Shapiro and Robert H. Anderson prepared for the
National Science Foundation and published by The Rand Corporation.
Perhaps the attribute of electronic mail systems that most distinguishes
them from other forms of communication is their propensity to evoke emotion
in the recipient--very likely because of misinterpretation of some portion
of the form or content of the message--and the likelihood that the
recipient will then fire off a response that aggravates the situation.
Possible causes for this phenomenon include:
- Difficulty in determining the formality of a message from its appearance.
- Attempts at humor, irony, sarcasm, and wit are often misinterpreted.
- Cues such as body langauge are lacking in electronic mail.
- The ease of an immediate "reply" encourages "off the top of the head"
responses.
- Electronic messages containing hasty or ill-chosen words can stay in
electronic inboxes or can be printed in a way (injet, etc.) that gives them
an importance never intended.
- Although anonymity is often mentioned as a factor, we have observed no
significant difference in "flaming" between remote correspondents who don't
know each other personally, compared with communication among people who
know each other.
What can be done to minimize the problems of escalating emotions that
arise?
- Carefully label messages that have a deliberate emotional content.
Sometimes just the annotation "Flame! Flame!" alerts the reader to the
fact that the writer knows he or she is being emotional.
- Resist the temptation to fire off a response. Write the response, file
it away, and wait 24 hours. Reconsider the response later, in the light of
a new day (and perhaps a rereading and reinterpretation of the original
message).
1
Page 8
- Use alternative media to break the cycle of message-and-response. A
telephone call or personal conversation can do wonders, when we can use
body language, eye contact, and the other cues we've developed.
Much of the problem seems to stem from the lack of cues that electronic
mail affords its readers. Perhaps the technology that spawned electronic
mail can help reduce the misunderstandings it creates. One can imagine
message systems in which the boldness of the characters displayed is a
function of the force with which the keys are hit. More certainly (because
the systems are in prototype form already) there will be systems in which
the characters will be accompanied by voice annotations, so that the
humanity and state of the sender will be retained and "read" by the
recipient.
Toward an Ethics and Etiquette for Electronic Mail, published by the Rand
Corporation with support from the National Science Foundation, discusses
issues related to the use of electronic mail and the effect of these
systems on the quality and appropriateness of communication. More
importantly, it presents a set of guidelines that should help lead to
effective electronic mail use.
Readers should be familiar with electronic mail systems or considering
adopting them for individual or institutional use. Copies are available
for $4 from The Rand Corporation, Publications Department, 1700 Main
Street, P.O. Box 2138, Santa Monica, CA 90406-2138. Ask for publication
R-3283-NSF/RC.
*************************************************************************
* BITNET Domains Task Force Report *
***************************************************************************
This article was condensed from the original report. You can get the
complete report (the file DOMTASK LISTING) from NICSERVE@BITNIC.
BITNET DOMAINS TASK FORCE
Report and Recommendations
to the BITNET Executive Committee
The BITNET executive committee directed Joe Yeaton of UCB and Leland
Williams of TUCC to form a Domains Task Force. The stated mission of the
task force is to identify BITNET's requirements for domains and domain
servers and then to propose technical solutions to those requirements.
The task force recently met during the SHARE 66 conference in Anaheim,
discussed the issues, and developed a set of recommendations which follow.
The meeting was led by Jim Walker of TUCC and David Wasley of UCB, each
appointed to the task by their respective directors.
1
Page 9
The Domains Task Force recommends that the following actions be taken by
the BITNET Executive Committee, the Domains Task Force, and the BITNET
Network Information Center, respectively:
1. The Executive Committee should officially acknowledge that
BITNET will adopt the DARPA Internet domain hierarchy and
top-level domain names.
2. The Executive Committee should contact the appropriate Defense
Communications Agency (DCA) representative to obtain formal
cooperation and coordination of use of top level domain names.
The flat name space has become difficult to manage and is too
restrictive. Therefore, a hierarchical name space should be adopted.
For essentially the same reasons that the ARPANET community decided to
move from a flat to a hierarchical name space, we also feel that it is time
to begin the move in that direction:
1. Maintaining unique and still meaningful node names within the 8
character limit is difficult. This limit has led to the problem
that the user of BITNET has trouble determining what site a
given node name represents.
2. Maintaining and distributing a database containing the name of
every machine on the network is awkward and will continue to
impose delays in making new nodes accessible.
Adopting a hierarchical naming strategy built on top of the underlying
link-level RSCS node names addresses both the naming and management
problems:
1. Domain names are not artificially limited to some small number
of characters. With domain names, the common misconception that
"CUVMA" and "CUNYVM" are both nodes at Columbia University or
City University of New York (or Cornell University) can be
eliminated; a domain name of "CUVMA.COLUMBIA.EDU" clearly
identifies the site as an educational institution named
Columbia.
2. Hierarchichal naming gives the organization control over its own
namespace and only requires agreement on a single name in the
containing namespace used to identify that organization. Two
sites can even have a machine with the same name ("VMA" for
example) and not have a conflict since their containing domain
name will be unique ("VMA.COLUMBIA.EDU" and "VMA.CORNELL.EDU"
for example).
1
Page 10
Within the constraints of the RSCS network, unique node names are still
required to maintain full connectivity. However, node names, although
unique, need not be meaningful to the user since he or she will be dealing
with a higher-level domain name.
The fundamental concept here is to consider the RSCS node name as a
low-level "network address." The user sees a domain name which
higher-level software will map to the network address "under the covers."
This is analagous to the mapping done on the ARPANET between domain names
and IP host numbers (which are 32-bit integers). These network addresses
(RSCS nodes, IP host numbers) still need to be unique, but the problem of
making them meaningful to the user goes away; the user gets the meaning
from the domain name.
The use of domain naming may eventually allow a reduction in the number
of BITNET nodes that require full RSCS-level connectivity. Only the node
at a site physically connecting that site to the RSCS network need be in
all other sites' RSCS route tables. That connected node serves as the
routing gateway between the long-haul RSCS network and the rest of the
site's nodes. A complete domain-level software layer that minimally
provides the same functionality currently provided at the RSCS level must
exist in order for this to work.
An example where this domain-level software capability currently exists
is with mail: If all other BITNET sites that wanted to communicate with
Columbia users also ran a mail transport agent like UCLA/Mail (MVS) or the
Columbia Mailer (VM), then only RSCS node CUVMA would need to be in other
site's route tables; their mailers would know that all mail for the
COLUMBIA.EDU domain should be routed to the mailer on CUVMA which would
take care of local redistribution within the university's local area
network. Of course, other network functions such as interactive messaging
(TELL) or file transfer (SENDFILE) would need to be modified to incorporate
similar routing algorithms.
Assuming that a hierarchical name space is adopted, it is recommended
that this name space be based upon the DARPA Internet model and use the
same top-level domain names.
The DARPA domain model is geography and network independent; it reflects
the natural admininistrative hierarchy of organizations and their
peer-to-peer relationship -- not location or how they are connected.
Domain names that reflect the method of interconnection such as .ARPA or
.BITNET are to be avoided. The .ARPA domain was used in the transitionary
period between the flat and hierarchical name spaces in the ARPANET. The
implementors have since stated that it was a mistake to ever get people
accustomed to this naming hierarchy. The task force feels that there is no
point in reinventing the wheel. We would rather adopt the DARPA model (as
has been done before for mail) than come up with our own model. This has
1
Page 11
special importance to the large number of BITNET sites that are also on the
other DARPA Internet-compatible networks (ARPANET, MILNET, CSNET).
Use of the same top-level Defense Data Network (DDN) domain names
(.EDU,.COM, etc.) will require the cooperation of the DDN Program
Management Office (PMO) of the U.S. Defense Communications Agency (DCA) and
coordination with the DDN Network Information Center and with the DDN PMO
contracting department(s) on those campuses that are on both networks. At
a meeting at SRI attended by Candy Willut of EDUCOM and representatives of
ARPANET, CSNET, and UUCP it was agreed that these networks joining the
Internet would be beneficial to all concerned. However, SRI is not the
official policy-setting representative of the DCA.
We recommend that formal cooperation be agreed upon by the executive
committee and the appropriate DCA representative. Furthermore, for sites
on both networks, administrative cooperation is necessary between the
BITNET site administration (typically the computer center) and the DDN site
administration (typically the computer science department).
The current unoffical (from the standpoint of DARPA) use of DARPA domain
naming within BITNET has led to problems when mail crosses the boundary
from BITNET to ARPANET; when the user on the ARPANET tries to reply to the
mail, it is found that the BITNET site's top-level domain or some
sub-domain is not registered in the appropriate domain names database.
For example, mail sent from CUVMA.COLUMBIA.EDU (RSCS node CUVMA on
BITNET) to someone on ARPANET results in something similar to the following
scenario: The replying mail server will query the SRC-NIC name server
(since it is the authorized server for the EDU domain) for the name server
for the COLUMBIA.EDU domain. SRI-NIC will respond with the address of
COLUMBIA.EDU, a VAX 11/750 administered by the Columbia Computer Science
department. Upon asking this name server for the address of
CUVMA.COLUMBIA.EDU, the mail server will be informed that
CUVMA.COLUMBIA.EDU does not exist since it is not registered.
Although the CS department could register the BITNET hosts at Columbia in
their name server, they might be reluctant to carry mail traffic from DDN
to BITNET and especially vice-versa unless the DDN PMO acknowledges that
this is a valid use of DDN resources. This is why explicit cooperation
between the BITNET Executive and DDN is a requirement.
Some organization is required to administer the name space for sites that
have only a BITNET connection, from the DDN point of view. BITNIC, as an
agent of the executive committee, is the place for such an administrative
function. Since SRI-NIC is the official registrar for subdomains within
the top-level EDU domain, a means of registering these BITNET-only EDU
1
Page 12
BITNET can not count on IBM to provide software to support the above.
Therefore, we are explicitly acknowledging that non-IBM software will be
required.
Unmodified, vendor-supported network transport mechanisms (e.g. RSCS,
JES, jnet, etc.) should be used; hierarchical name support will be layered
on top with additional software developed by BITNET members. This is not
an endorsement of the vendor software as being the best way to interconnect
BITNET. It is recognition of the fact that this is the way the network is
currently connected. We do not wish to recommend that sites must modify
their vendor-supplied software to participate in the network (at the
transport layer).
We do wish to drive home the point that although vendor software for the
network transport functions can be vanilla, sites will have to run
modified, complete replacement, and/or additional applications software in
order to participate effectively in the Internet. It should be made clear
to existing and potential BITNET members that they can not expect to have
the same functionality as other members unless they use this additional or
changed software.
The use of hierarchical names rather than RSCS node names as the
fundamental user-visible method of addressing another user implies that
this hierarchical support should encompass all or many of the functions
currently provided by the base RSCS network:
- mail
- file transfer
- interactive messaging
- RJE/RJO
- remote commands
- remote login (not really feasible using current low-speed links)
- etc.
We recognize that some or all of these recommendations may not apply to
the environments of our peer RSCS networks, EARN and NETNORTH. The use of
DARPA domain names is not meant to address their environment but that of
United States BITNET sites and should not be construed as the only solution
or one that we expect non-US sites to adopt.
Specifically, EARN/NETNORTH sites may prefer to implement some other
naming scheme more compatible to their environments (e.g. CCITT X.400).
We of course intend to maintain and enhance the interconnectivity of our
networks. Nothing recommended here should be construed as impeding
cooperation with EARN/NETNORTH.
We believe these recommendations to be the current best solution and
realize that there will be and fully expect future changes that will
augment or supersede the recommended solutions presented here.
1
Page 13
*************************************************************************
* Spotlight Server: DATABASE@BITNIC *
***************************************************************************
DATABASE is a sophisticated database server developed for BITDOC by Henry
Nussbacher, consultant, City University of New York. DATABASE provides
user specified keyword access to subsets of larger databases. Retrieval
capabilities are based on SPIRES, the Stanford Public Information Retrieval
System.
A Subfile is the largest structure in which information is stored within
SPIRES on DATABASE. Three types of subfiles include Demonstration Files
such as MOVIES or RECIPES used to gain experiance with DATABASE, Network
Digests such as AI-LISTS an archive of a discussion forum maintained within
ARPANET, and General Information Files such BITINFO the BITNET node
identification subfile.
DATABASE is available to BITNET, EARN, and NetNorth users via interactive
messages, mail, and files in CMS PRINT or PUNCH format, and responds based
upon a node's preferred file format. DATABASE will also respond to
Internet requests from other networks using mail which conforms to ARPANET
standard RFC822.
Issue the following interactive message from an IBM/VM environment, to get
the initial DATABASE HELP file.
TELL DATABASE AT BITNIC HELP
From a VAX/jnet environment, issue the command
SEND DATABASE@BITNIC HELP
Create mail, or an appropriate file or send an interactive message to
DATABASE@BITNIC with the commands HELP, HELP ARPANET, and HELP DESIGN for a
complete set of help files.
Below are examples using the DATABASE server. While commands can be sent
by any of the methods previously mentioned, these examples are based on the
IBM/VM TELL command.
TELL DATABASE AT BITNIC LIST
This command returns a list of retreivable subfiles as follows.
DRINKS Demonstration subfile
MOVIES Demonstration subfile
. .
BITINFO Database System subfile
AI-LIST ARPANET discussion forum (digest)
1
Page 14
TELL DATABASE AT BITNIC FIND TEXT BITNET (IN INFO-NETS TABLE
This command tells DATABASE to use the FIND command to search the TEXT of
all the entries in the subfile INFO-NETS for all instances of the word
BITNET and reports the results as a table rather than full text since the
file would most likely be too large. (Any result larger than 1000 lines of
text will be returned in a TABLE format or will respond as if the HOWMANY
option had been specified.) A table returned may look like:
GRANDS SUBJECT
-----------------------------------------------
498 Subject: PHYSnet
499 Subject: Sitelists and General Info
. .
. .
583 Subject: gateway to NJIT
TELL DATABASE AT BITNIC FIND GS 583 (IN INFO-NETS
DATABASE will return the contents of the entry whose subject is "gateway to
NJIT". GS 583 specifies the GRANDS SUBJECT number 583 from the ARPANET
digest INFO-NETS.
Unlike the ARPANET digest subfiles some subfiles are not searchable by by
the index TEXT. For example, BITINFO is the BITNET database subfile. It
is a compiled version of the bulk of information contained in BITONLY
NAMES, EARN NAMES, and NETNORTH NAMES and identifies and characterizes
nodes and contacts on the network. An example of some search commands are:
FIND SITEDESC CUNY (IN BITINFO
FIND NODE CUNYVM (IN BITINFO FORMAT LONG
FIND STATE NY (IN BITINFO FORMAT SHORT
The indices being searched on are SITEDESC, NODE, and STATE. To find out
what indices are valid to seach on within any subfile, issue the command:
TELL DATABASE AT BITNIC SHOW INDEX (IN subfile
The values chosen here to search on are CUNY, CUNYVM, and NY. To get an
idea of what values can be searched upon within an index, issue the
command:
TELL DATABASE AT BITNIC BROWSE indexname (IN subfile
The format in which the results are returned in the examples above are
standard SPIRES format (if no other is specified), SHORT, and LONG. To
find out what formats are valid for a particular subfile issue the command:
TELL DATABASE AT BITNIC SHOW FORMATS (IN subfile
where BITINFO can be substituted for the word "subfile".
1
Page 15
Users who wish to use DATABASE via RFC822 mail, must first signon and
receive a user number (UN) and supply a password. To signon, send the
following command to DATABASE:
SIGNIN mypassword
where mypassword can be any string of contiguous characters that is more
than or equal to 8 and less than or equal to 20. You will receive a mail
file in return like this:
Your signup has been processed and you have been assigned a
user number (UN) of 00012.
You are from that point onward, registered in DATABASE and can use any of
the commands listed above. If you no longer wish to be registered by
DATABASE, execute the command:
SIGNOUT 00012 mypassword
You will no longer be known to DATABASE and will have to SIGNIN again if
you wish to use DATABASE by sending RFC822 mail.
*************************************************************************
* New Mailing Lists *
***************************************************************************
ICECNET#@ANDREW.CMU.EDU
ICEC, the InterUniversity Consortium for Educational Computing, is a
consortium of universities and colleges committed to developing high-
quality educational applications for advanced computing environments.
ICECNET has been the newsletter of ICEC for several years. Paper
publication continues, but a copy of each issue of the newsletter will also
be released about once a month via this mailing list.
ICEC has supported software development at member schools and conducted
activities for faculty from member schools (e.g. developers' conference,
training programs in courseware development for advanced workstations).
Other mechanisms are evolving to promote development of good educational
programs for advanced, graphics-intensive workstations and to aid in
sharing these developments among interested parties.
ICEC is therefore initiating an internet mailing list (1) for publication
of information about ICEC, (2) communication among member schools related
to internal business, and (3) as a forum for discussing issues related to
the general objectives of ICEC. Examples of the third category might be
"what constitutes high-quality courseware?", "what Unix workstations are
best suited to general educational use?", "what mechanisms are best for
sharing educational developments using advanced technologies?", etc., etc.,
1
Page 16
etc. Individuals, both from member schools and from non-member
organizations, are invited to contribute in this third area.
All submissions for the monthly (paper) newsletter should be sent to:
Patricia Clark,ICECNET editor
|