|
|
|
|
|
|
|
|
NetMonth, October 1988
******** **************************************************
* * *
* * The independent guide to BITNET *
* * *
* * October, 1988 *
* * *
* * Volume 3, Number 4 *
******** * *
* *
*** * *
* * * * *
* * * * *
* * * * *
* ** * ____ __.---""---.__ ____ *
* /####\/ \/####\ *
* * (/~~~~~) (~~~~~\) *
* * \__OO/ \OO__/ *
****** * __/ \__ *
* * .-" . . "-. *
* * ] ] \.._ _../ ] ] *
* \ \ \."-.__________.-"./ / / *
******** * \ \ "--.________.--" / / *
* * ___\ \_ _/ /___ *
* * ./ ))))) ((((( \. *
* * \ / *
* ******\ \_ _/ /******
* ********\ \____/""-.____.-""\____/ /********
******** **********\ \******************/ /**********
* \. .] ]. ./ *
*** * ." / ] \ / ] \ ". *
* * * ." / ] \ / ] \ ". *
* * * /.-./.--.].--.\ /.--.].--.\.-.]. *
* * * *
*** * *
* *
****** * *
* * *
* * *
* * *
**** ~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~~ ~~~~ ~~~~~
~~~ ~~~~~~~ ~~ ~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~ ~~
* ~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~~ ~~~~ ~~~ ~~~
* ~~~~~~~ ~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~~~~~~~ ~ ~~~
****** ~ ~~~~ ~~ ~~~~~~~ ~~ ~~~~~ ~~~~~~~ ~~~~~ ~ ~~
* ~~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~~ ~~~~ ~~
* ~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~~ ~~~~ ~~~~~~
~~~ ~~~~~~~ ~~ ~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~ ~
******** ~ ~~~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~~ ~~~~ ~~~ ~~~~
* ~~~~~~ ~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~~~~~~~ ~ ~~~~
* ~~~~~ ~~ ~~~~~~~ ~~ ~~~~~ ~~~~~~~ ~~~~~~~~ ~~
* ~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~ ~~~~~ ~~~~ ~~~
**** ~~~~~~~~~~ ~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~ ~~~~~ ~
1
* * * * *
** * * ** ** * * *
* * * *** ***** * * * * *** **** ***** ****
* * * * * * * * * * * * * * * *
* * * ***** * * * * * * * * * *
* ** * * * * * * * * * * *
* * **** * * * *** * * * * *
***** *****
Christopher Condon Editor CONDON @ YALEVM
Timothy Stephen Associate Editor STEPHEN @ RPICICGE
Craig White Associate Editor CWHITE @ UA1VM
June Genis Contributing Editor GA.JRG @ STANFORD
David Hibler Contributing Editor ENGL0333 @ UNLVM
Henry Mensch Contributing Editor HENRY @ MITVMA
Deba Patnaik Contributing Editor DEBA @ UMDC
Gerry Santoro Contributing Editor GMS @ PSUVM
Marc Shannon Helpdesk Editor HELPDESK @ DRYCAS
Glen Overby Technical Assistant NU070156 @ NDSUVM1
Gary Moss Point of View MOSS @ YALEVM
********************* Contents - Issue 26 *********************
EDITORIAL PAGE_________________________________________________
Bitnotes .................................................... 1
The Human Factor ............................................ 3
Flames To: .................................................. 7
An Oprn Letter to Dr. James Conklin Jr. ..................... 9
FEATURES_______________________________________________________
BIOSCI Novw Available to BITNET/EARN ....................... 12
Four Internet File Servers ................................. 14
The Chaos Mailbox System ................................... 16
DEPARTMENTS____________________________________________________
Headlines .................................................. 18
Feedback ................................................... 19
Policies ................................................... 23
* For information on subscribing to NetMonth, submitting *
* articles, sending letters, and printing this file, see *
* the "Policies" section on the last pages of this issue. *
---------------------< Distribution: 3389 >--------------------
1
Page 1
*********
* * Bitnotes
* *
* * by Christopher Condon
* *
* * Yale University
* *
* * CONDON@YALEVM
*********
"One size fits all."
One of the more frustrating experiences I have to go through is
shopping for clothing. Somewhere along the line my body
stopped growing at a point where no one keeps my dress-shirt
size in stock (15/32), my pants are hard to find (32/30) and my
shoes are better suited to a duck (7 1/2 EEE). Somehow all of
these factors come together to form a relatively good-looking
human being, but finding clothes for him is an exercise in
head/wall pounding.
Likewise, finding the BITNET service that fits your needs can
be difficult. Perhaps the descriptions of the mailing lists
to which you subscribed were inadequate, and they weren't what
you were expecting. Maybe the file server you were accessing
didn't organize its files in any particular way, and you had to
wade though alphabetical listings. It might have been that the
Relay was not operational during the hours you needed it.
As we have mentioned in the past, most servers and services are
proviced by volunteers. As such, it is often difficult to
criticize their efforts without seeming ungrateful. Not one
wants to send someone who has devoted many hours of their own
time to making BITNET better a note that says, in effect
"Compared to such-and-such, your server stinks." (Substitute
your own socially unacceptable adjectives where needed).
People either stop accessing these services in favor of
something else (often not on BITNET) or they continue because
"it's all there is." Everyone loses in this scenario. The
users lose time and convenience they could and should have had.
The server people lose valuable input. BITNET loses some
functionality.
The key to resolving this problem is to provide a means of
feedback, preferably one which allows some comparisons among
different serverices in the same category. For example, what
do people like about CSNEWS as opposed to COMSERVE (and vice-
1
Page 2
versa)? They provide similar services to large audiences in
different ways. Is there some overlap in their user base?
What features make one or the other easier to access?
In distributing the latest BITNET USERHELP I have been very
lucky in that many people have sent me mail listing comments,
corrections, and so on. While people seem to like the document
a lot, these changes can make the difference between "very
good" and "excellent". The same is true for the servers. You
are the users, so you are the experts. Tell the people who run
these services what you think. As they say, "the customer is
always right".
Virtually,
Chris Condon@YALEVM
1
Page 3
*********
* * The Human Factor
* *
* * by T. D. Stephen
* *
* * Rensselaer Polytechnic Institute
* *
* * STEPHEN@RPICICGE
*********
Believe it or not, there are still people in administrative
positions at computer centers who think that undergraduates
should be barred from the net. I had assumed that this issue
had breathed its last, that the advocates of this type of
discrimination had finally realized that their position was
ill-considered -- in fact contrary to the best interests of
academic computing -- and had changed their minds. Alas, not
so. Ill-informed about what actually happens on BITNET and
wrong in their assessment of the consequences of student use,
the advocates of a student-free network are still out there,
like kinks in a garden hose.
The POLICY-L "list" jolted to life recently when someone wrote
to inquire about arguments that might persuade computer
administrators at Southern Illinois University to allow
undergraduates to use BITNET. Well known for its excellent
university press, its leadership in post-modern scholarship,
and its beautiful campus near the Shawnee national forest, it
would appear that SIU is also distinguishable as home to one of
a small number of computer administrations that continues to
hold out against an expanded future for computing in higher
education.
The keep-students-off-the-net crowd tend to defend their
position with three arguments: (a) a bureaucratic argument that
claims that student access places undue strain on computer
center resources, (b) an economic argument that claims that
student access costs too much money, and (c) a moral argument
that claims that student message traffic is frivolous and slows
down "legitimate" message traffic on the net. I'd feel more
hopeful if (c) was the only argument made. If that were the
case, we could lay the issue to rest by simply assessing the
uses to which the net is actually put. I believe that after
spending just one afternoon pursuing this, two things would
become abundantly clear: (1) that researchers, professors, and
computer center staff engage in quite a bit of "frivolous" use
themselves; and (2) that distinctions between "educational" use
and "social" use or between use consistent with "research" and
use for other purposes would be virtually impossible to defend
1
Page 4
or maintain. Since no one has yet found the royal road to
knowledge, it is very difficult to pass judgment on what is
educational and what isn't. All that can be said with
certainty about the variety of ways of knowing and learning
that flourishes in higher education is that protecting and
nurturing this variance probably ranks as one of the most noble
goals that we in university life can aim for. At any rate, it
will take someone bolder than me to say what is an educational
use of the net and what isn't.
But last December someone from Akron University reported on the
UG-L list that administrators banished their students from the
net after discovering "...undergrads obtaining obscene and
porno material through BITNET...". A similar report from
Southwest Missouri State noted that students had been
"...discovered using BITNET relays for social chatting, and a
small number of students have been discovered sending obscene
messages and pictures." Assuming that we are not talking about
students of anatomy, human sexuality or art, it could be
difficult to extend a reasonable definition of educational use
to include exchanging electronic pin-ups or messages that
describe sexual intercourse.
Frankly, however, I really don't know why anyone cares if
consenting students (or faculty) exchange this sort of material
or if they use BITNET to do it; every communication medium ever
invented has carried sexually explicit messages at one time or
another and all new ones will too. Those who would try to
eradicate communication about sex may as well try to halt the
rain from falling or the trees from losing their leaves in the
fall; they have chosen to swim against one of life's most basic
and powerful currents. On the other hand, these reports are
deeply disturbing in their suggestion that computer center
staff have felt qualified to make decisions about what
constitutes pornography and obscenity; and, even worse, have
apparently not felt timid or guilty about violating the civil
rights of their users by reading their mail. Imagine if your
dean decided to start eavesdropping on phone calls or opening
campus mail. Now there's a way to get your school some
attention in the national press!
The economic and bureaucratic arguments against student access
usually reduce to fairly vague suggestions about student use
leading to increased mainframe costs or student access tying up
resources and thus interfering with the ability of the computer
services unit to fulfill its mission on campus. I'm not a
computer center administrator so perhaps I'm thinking about
this incorrectly; however, I assume that an idling mainframe
costs the university the same to operate as a mainframe that is
used to capacity. In other words, the mainframe, just like the
1
Page 5
university's BITNET connection, is a static expense. It seems
to me, therefore, that its sensible to look at BITNET as being
a little like an all-you-can-eat restaurant: the more of its
resources the university can make use of, the better its value.
Use of printers, tape drives, and disk packs is another matter,
but one that is essentially irrelevant to the question of costs
associated with using BITNET.
I wonder if one of the roots to the problem might be that some
computing centers are funded under a model that actually *is*
more appropriate for a restaurant than for a university
information center. If schools treat computing resources as
though they are consumable goods, people may be tempted to view
each use of the computer as though it represented a dollar loss
to the institution -- in the same way that a hamburger consumed
at a dining hall represents a real expense. If computer
administrators take this model too seriously, they may come to
view BITNET access as a potential drain on their pool of finite
resources.
Imagine if the campus library was run on the same model: the
more books checked out, the greater the drain on the library.
Charges would be higher for checking out hefty tomes like War
and Peace than for checking out shorter works. Those who
checked out many books would be expected to get a grant to fund
their reading. Ridiculous, of course, but only because the
university library has come to be viewed as an integral
component in the educational process. The more books in
circulation -- in fact, the more volumes that there are to
circulate -- the greater the mark of distinction for the
library and for the university as a whole, and the greater the
value of the university library within the academic community
it serves.
So why aren't computing centers run on the same model as
libraries? One reason, I suspect, is that external funding
agencies (e.g., the National Science Foundation or the Dept.
of Defense) permit universities to charge real money for
computer time used toward fulfillment of grants and contracts.
To take advantage of this, computing centers have needed to
develop accounting systems. The centers need to have a way to
show not only what everything costs, but also *that* everything
costs. Under normal circumstances, however, funding agencies
do not allow charges for time researchers spend using library
materials. Thus, there has never been an incentive to think
about running libraries on a for-charge basis.
But it is important to consider that other point of distinction
between libraries and computer centers -- the nature of the
mission that they perform on campus. The library functions as
1
Page 6
an integral component in educational practice but the campus
computer center tends not to. Certainly you can't have a
computer science major without a computer facility, but only a
handful of other departments would see the computer center as
vital to their undergraduate programs. BITNET brings good
reason for this to change. BITNET offers access to
educationally oriented network services (e.g., Comserve) and
thus invites computing centers to assume an expanded role, one
that, in time, will substantially increase the relevance of
computing across the academic spectrum.
The arguments against students using BITNET are best understood
as an expression of a deeper anxiety. The real concern, I
suspect, is not over how student message traffic will affect
the ability of the net to carry "legitimate" messages or the
amount of computer "funny-money" that gets consumed when a
student sends an electronic note over the net. It is not even
over the degree to which students are responsible in their use
of the network. The real concern is the future of academic
computing itself. BITNET membership invites computer center
administrators and staff to move from their relatively limited
(but clearly defined) role in providing researchers and
administrators with numerical and textual tools, to a more
ambitious though unfamiliar role in facilitating inter-
university communication for the entire campus. This move will
propel computer services organizations to a center-stage
position in educational programs across the disciplines. This
is a major evolutionary step and one that may take time for
some administrators to come to terms with.
Will campus computing centers universally accept the invitation
BITNET offers to assume an expanded role in a future of
networked education? Of course they will -- the issue has
already been decided. Each year more faculty are
enthusiastically exploring ways of integrating student use of
the network into their courses. They are experimenting with
educational designs that use BITNET to connect students with
peers across the country and with faculty from other schools
and disciplines. The time when computer center administrators
will be able to deny students access to network resources is
quickly running out. A few schools will hold out, but not for
long.
1
Page 7
*********
* * Flames To:
* *
* * by Craig White
* *
* * University of Alabama
* *
* * CWHITE@UA1VM
*********
Hello once again,
I've been so busy this month that I don't even have a comment
about how well my little corner of the net world was connected.
I've received too much mail from the lists and have seen a
couple of mail-list faux pas. I was very annoyed at one point
by some mail that got loose on a couple of the lists that
really made my in-box "look" full. Maybe that problem has been
fixed. Even so, I am still excited about networks, and
continue to find new reason to become even more so. This is
another one of those months where I really can't classify what
I have to say as a flame, but I feel that these issues need
some of your brain bandwidth.
I've been writing this column for some months now and I feel
that I should give you some information about myself. I work
in User Service at the University of Alabama and have been
using BITNET ever since our node was connected in 1984. I have
been a network fanatic ever since. I am continually trying to
persuade friends, acquaintances, and anyone else who will
listen to take advantage of opportunities that mail systems and
computer networks have to offer. Occasionally people return to
me with horror stories of one type or another. This month was
one of those months.
I have mentioned the Rand book entitled "Toward an Ethics and
Etiquette for Electronic Mail" which was written by Norman Z.
Shapiro and Robert H. Anderson. As you might know, I think
that everyone who uses electronic mail, whether on a computer
network, a host based mail system or even PC bulletin boards,
should read this book. It discusses many of the potential
problem areas involved when people choose to exchange
electronic mail instead of using more traditional forms of
comunication. I do not keep copies of this publication around
to give to these people; rather, I tell them where they can
find it and send them on their way. Many times, maybe even
most of the time, no one takes the time to find a copy of this
book and read it. (By the way it's more like a booklet and you
should be able to read it in about the same amount of time it
would take to read a news magazine from cover to cover.) Most
1
Page 8
of the horror stories I hear are covered in this book and
although it's not quite on the level of Stephen King, I really
think that all of you should make the trek to your library and
get this book. I would like to give those of you who haven't
read the book a taste of what exciting topics are covered. The
following is based on a true story (only the names have been
changed to protect the innocent).
This one is from a friend of mine, we'll call him Fred, in
corporate America who's company decided that electronic mail
was the way to increase productivity. Their reasoning was
sound: there would be no line to report to the boss, they
wouldn't have to play telephone tag with co-workers, etc.
Things were going great until Fred was told by a friend in
another department of a situation that might have some bearing
on Fred's department. It seems that Paul, who works in a
different group within Freds department, had done a less than
bang-up job on an job outside the department. Fred decided
that since this related to his department it should be relayed
to Ms. Bigg, the departmental boss, so she would be informed
in case anything was ever said. He quickly prepared a piece of
electronic mail and sent off to Ms. Bigg. As it turned out,
Ms. Bigg, who had also been using electronic mail, knew how to
forward a piece. Can you imagine what happened? Ms. Bigg
forwarded the note to a manager that was over several groups.
That manager forwarded it to Paul's manager, who finally
forwarded the note to Paul, UNCHANGED.
I am of the opinion that you should not send a piece of mail if
it would bother you if it ended up typeset on the front page
the newpaper. My freind in this case wishes there ware such
things as a mail tag that says "this is for informational
purposes only, no action required".
Electronic mail can be be both a blessing and also a royal pain
as evidenced by my friends horror story. Nevertheless, I feel
that we should continue to try and make as much use of
electronic mail as is possible, bearing in mind the possible
pitfalls. As always flames, comments and suggestions to
CWHITE@UA1VM.
1
Page 9
*********
* * An Open Letter to Dr. James Conklin Jr.
* *
* * by Eric Keller
* *
* * Universite du Quebec a Montreal
* *
* * FONETIKS@UQAM
*********
* Editor's note: Dr. Conklin was recently named Director of
the BITNET Network Information Center.
Dear Dr. Conklin,
I have recently learned via NetMonth that you are the incoming
director of the BITNET Network Information Center. I would like
to take this opportunity to communicate to you some concerns I
have concerning BITNET's operation, concerns that I think need
to be addressed as BITNET and its associated networks move into
a mature phase of serving a wide variety of needs of a
worldwide academic community.
I have networked seriously for close to two years. Since March,
I have been the editor of foNETiks, a monthly news magazine
serving members of the phonetic sciences community. Our
magazine typically runs from 30 to 40 pages and presently
reaches some 200 email addresses worldwide. As a result, I am a
fairly heavy user of BITNET. While reader satisfaction with
this rapid means of scientific dissemination runs high, I think
some operational concerns need to be addressed at BITNET over
the next few years.
My main concern is the occasionally haphazard manner in which
mail gets delivered. Often, mail bunches up for days and
suddenly arrives in gobs. It is certainly strange to be logged
on in Quebec and to receive a message from a BITNET site in
Indiana saying that the mail sent out a week ago was just
delivered. According to reports in recent issues of NetMonth,
mail sometimes even gets deleted when mainframe usage is
particularly high. With some nodes, a regular exchange of mail
has turned out to be impossible because of the delays or the
uncertainty that the link entails.
I consider that a VERY HIGH LEVEL OF ASSURANCE ABOUT MAIL
REACHING ITS DESTINATION WITHIN A REASONABLE DELAY should be at
the very top of BITNET objectives. Network mail is no longer a
luxury or a lark. It comes close to being an essential service
within the academic community, and thus needs to be supported
1
Page 10
with the requisite amount of technical and administrative
seriousness.
No doubt the BITNET technical staff will be better equipped
than I to make suggestions as to how improvements should be
implemented. But at least from this perspective, I think that
more intelligent routing programs are called for, in order to
be able to automatically circumvent nodes that are down or
overloaded. Also, some automatic feedback program should be set
up to oversee the operation of the whole network, to report on
nodes that are down, and to "wake up" support personnel in the
affected nodes. Although the lack of strong centralized control
is a hallowed tradition of BITNET, some supervision *is*
required. It is important to have a mechanism for soliciting
the cooperation of nodes that are not pulling the weight
they've contracted to pull.
Another concern is the explicit or implicit limit on long mail
files. Issues of foNETiks often run longer than 100k. Some
nodes will simply not accept mail this large, and all of BITNET
actively discriminates against large mail file transmission by
priorizing the transmission of shorter files. Our present
solution is to segment the magazine into 15-page portions and
to mail them separately. That may circumvent the problem for
now, but it does not address the central issue.
The point is that much academic discourse and scientific
information quite naturally runs to more than 100k. A small
printed science news magazine (like Discover, Psychology Today
or Physics Today) contains between 700 and 2000k of
information. I don't see why foNETiks should be artificially
constrained to 100k. My colleagues and I write papers in
international collaboration via BITNET, and many such
collaborations generate files longer than 100k. Some of us send
data files from one lab to another via BITNET, and these files
are seldom shorter than 100k if they are to be useful at all.
Yet everywhere we turn, the active discrimination against
larger mail files slows us down, and sometimes even imperils
the very transmission of our files.
I have full comprehension for the physical and economic limits
that originally led to the establishment of the small-is-faster
philosophy. But the reality is that BITNET is now evolving into
a more mature phase of its existence and thus needs to plan
ahead to a period where a much larger set of academic needs can
be served. One of these needs is the possibility of sending
longer files more rapidly and with complete assurance that they
do not get deleted along the way.
1
Page 11
This means that nodes will have to make available more
substantial resources. More parallel links between nodes should
be planned for and established. Letters such as this one should
be used to convince computer center support staff in
participating nodes that scientific publications and academic
exchanges often run much longer than the traditional one-page
letter. Long files have a natural place on BITNET and should
get more respectful treatment than they do at the present.
Finally, I think that access to the other networks should be
simplified. In the March 1988 issue of NetMonth, I have
commented on some of the difficulties I have encountered in
this respect ("Comments of a So-so Happy Crossnet User", pp.
9-11 ). Ultimately, this will only be possible if some simple
mail addressing convention is agreed upon by all networks. This
will probably involve a high level of abstraction to permit all
networks to translate the addressing convention into their
particular internal code. Again, the BITNET technical staff
will be much better equipped than I to make concrete
suggestions. What I am concerned with is that the need for
better and more transparent universal addressing be recognized
and be translated into the necessary high priorization on
BITNET's agenda for future improvements and investments.
Before this letter turns into a file longer than 100k, I would
like to send you my best wishes for your upcoming term as
director. I hope that you will be able to share in some of the
concerns I have voiced here, and will be able to do your part
in bringing these to the attention of BITNET's regents.
1
Page 12
*********
* * BIOSCI Now Available to BITNET/EARN
* *
* * by Niall O'Reilly
* *
* * University College, Dublin
* *
* * NOREILLY@IRLEARN
*********
The Irish National EARN node, IRLEARN, has joined the
international network of BIOSCI nodes which provide electronic
mail distribution and bulletin board services for
biotechnologists.
IRLEARN is the fourth such node to date, joining others at the
BIONET National Computer Resource for Molecular Biology,
Mountain View, California for subscribers in the Americas,
Daresbury for subscribers in the United Kingdom (mainly on
JANET), and the Biomedical Centre, University of Uppsala,
Sweden for subscribers in Scandinavia (mainly on NORDUNET).
IRLEARN will be the primary distribution point for BITNET/EARN
users, and will also serve users of the Irish Academic Network,
HEANET.
BIOSCI services provided from IRLEARN will include:
* Automatic distribution to BIOSCI subscribers at all BIOSCI
nodes of electronic mail messages sent to a BIOSCI address at
IRLEARN;
* Automatic distribution to BIOSCI subscribers at IRLEARN of
electronic mail messages sent to a BIOSCI address at any other
BIOSCI node;
* A BIOSCI archive from which collections of recent BIOSCI mes-
sages may be retrieved by network users;
* BIOSCI bulletin boards which will give local IRLEARN users
access to the BIOSCI archive.
It is expected that the archive and bulletin boards will hold
the messages of the current month and those of the immediately
previous month.
Several different BIOSCI addresses for electronic mail will be
available at IRLEARN, as at the other BIOSCI nodes. Each
address is intended for messages on a particular topic, and all
current addresses are shown below.
1
Page 13
Each address also has a corresponding distribution list at
IRLEARN, automatically managed by the Revised LISTSERV
software. This software allows network users to become
subscribers to any of the distribution lists, and so to receive
electronic mail messages sent to the corresponding BIOSCI mail
address at IRLEARN or at any of the other BIOSCI nodes. You
may, of course, subscribe to as many of these distribution
lists as you wish. To subscribe, send the command
SUBSCRIBE listname your_full_name
to LISTSERV@IRLEARN via mail or message.
The BIOSCI listnames are:
BIONEWS - General announcements
BIOMATRX - Applications of computers to biological databases
BIOTECH - Biotechnology Issues
SOFT-CON - Information on molecular biology programs
EMBL-DB - Messages to and from the EMBL database staff
BIOJOBS - Job opportunities
GENBANKB - Messages to and from the GenBank database staff
GENE-EXP - Gene Expression
GENE-ORG - Genomic Organization
METHODS - Requests for information and lab reagents
MOL-EVOL - Molecular Evolotion
ONCOGENE - Oncogenes
SOFT-COM - Information on communications software
SOFT-PC - Information on PC-software for scientists
PIR-BB - Messages to and from the PIR database staff
PLANT - Plant Molecular Biology
PROTEINS - Protien Analysis
RESEARCH - Reseach News
SCI-RES - Information about funding agencies, etc.
SWISSPRT - Messages to and from the SWISS-PROT database staff
YEAST - Yeast Genetics
1
Page 14
*********
* * Four Internet File Servers
* *
* * by Deba Patnaik
* *
* * University of Maryland
* *
* * DEBA@UMDC
*********
Mail based servers are simple yet elegant. They run in
background all day long and provide access to a large col-
lection of files, whcih may contain reports, source programs,
binary executables and bulletins. In this month I am reporting
four new Internet servers which may be accessed by sending
electronic mail. They are:
ARCHIVE-SERVER@TITAN.RICE.EDU - This Rice University server
stores sun-spots digests, contributed and software for SUN
workstations.
ARCHIVE-SERVER@SUN.SOE.CLARKSON.EDU - The CLarkson University
server offers contributed LaTex and Postscript files.
ARCHIVE-SERVER@BCM.TMC.EDU - The server stores NFS (Network
File System) bulletins, contributed software for NFS and UNISYS
related files. It is run by Baylor College of Medicine
WRL-TECHREPORTS@DECWRL.DEC.COM - The server stores abstracts of
technical reports and complete reports in postscript format. It
also allows you to add your address to the technical reports
mailing list and order hardcopy reports. It is run at the
Digital Equipment Corpoaration Western Research Lab.
These servers use the same software and allow you to write
three basic commands: HELP, INDEX, and SEND. The fourth server
allows three additional commands; they are: ADD, ORDER and
STATUS. Each command must be the first word on a line of a mail
message. The server reads your entire message before it does
anything, so you can have several different commands in a
single message. The server treats the "Subject:" header line
just like any other line of the message. You can use any
combination of upper and lower case letters in the commands.
The files are organized into a series of directories and
subdirectories. Each directory has an index, and each sub-
directory has an index. The top-level index gives you an
overview of what is in the subdirectories, and the index for
each subdirectory tells you what is in it. The following
1
Page 15
explainations of the commands are extracted from the help file
of the servers.
HELP - The command "help" or "send help" causes the server to
send you the help file explaining all the commands.
INDEX - If your message contains a line where the first word is
"index", then the server will send you the top-level index of
the contents of the archive. If there are other words on that
line that match the name of subdirectories, then the indexes
for those subdirectories are sent instead of the top-level
index. For example:
INDEX
or
INDEX PROGRAMS
or
INDEX RECIPES
You can then send another mail message to the archive server,
using a SEND command (see below) to ask it to send you the
files whose names you learned from that list.
SEND - If your message contains a line where the first word is
"send", then the server will send you the item(s) named on the
rest of the line. To name an item, you give its directory and
its name.
SEND RECIPE AFRICAN-STEW
or
SEND PROGRAM RCKEEP
Once you have named a category, you can put as many names as
you like on the rest of the line; they will all be taken from
that category. For example:
SEND RECIPE CHOC-SHIP-1 CHOC-CHIP-2 CHOC-CHIP-3
The following three commands are supported by WRL-TECHREPORTS
server:
ADD - If you are not on the mailing list for DECWRL, you can
add your mailing address (USPS) by a sending add in the body of
your message, followed by your mailing address.
ORDER - Allows you to order a harcopy of a technical report.
STATUS - This command allows you to check the status of your
order.
1
Page 16
*********
* * The Chaos Mailbox System
* *
* * by Frank Simon
* *
* * Universitaet Oldenburg
* *
* * 151133@DOLUNI1
*********
(Translated into English by Thomas Zielke, 113355@DOLUNI1)
CHAMAS (the Chaos Mailbox System) is a bulletin board which has
been running at Universitaet Oldenburg since April, 1988. It
supports the GEONET-standard, developed previously for the
GEO1-Mailbox.
Commands should be sent to 107633@DOLUNI1. The first command
you send should be HELPME, which can be sent via mail or
message. You will then be prompted to specify the language
(English, French, etc.) which you will be sending commands to
CHAMAS. You can then send the command CMD for a list of
commands.
After subscribing to CHAMAS with the command NICK
|