|
|
NetMonth, June 1988
******** **************************************************
* * *
* * * The independent guide to BITNET *
* ******* *
* ******* June, 1988 *
* * * *
* * * Volume 2, Number 12 *
******** *************** *
*************** *
*** * * *
* * * * * *
* * * **** *
* * * **** *
* ** * * *
* * *
* ************************************* *
* ************************************* *
****** * * *
* * * *
* ************************** *
************************** *
******** * * *
* * * *
* ********** *
* ********** *
* * * *
* * * *
******** ***************** *
***************** *
*** * * *
* * * * *
* * ******************************************** *
* * ******************************************** *
*** * * *
* * *
****** ******************************** *
* ******************************** *
* * * *
* * * *
**** *************************************** *
*************************************** *
* * * *
* * * *
****** ********************** *
* ********************** *
* * * *
* * *
******** ************* *
* ************* *
* * * *
* * *
**** **************************************************
1
* * * * *
** * * ** ** * * *
* * * *** ***** * * * * *** **** ***** ****
* * * * * * * * * * * * * * * *
* * * ***** * * * * * * * * * *
* ** * * * * * * * * * * *
* * **** * * * *** * * * * *
***** ******
Christopher Condon Editor CONDON @ YALEVM
Timothy Stephen Contributing Editor STEPHEN @ RPICICGE
Craig White Contributing Editor CWHITE @ UA1VM
Glen Overby Technical Assistant NU070156 @ NDSUVM1
Gary Moss Staff Supervisor MOSS @ YALEVM
******************** Contents - Issue 22 ********************
EDITORIAL PAGE_________________________________________________
Bitnotes .................................................... 1
The Human Factor ............................................ 3
Flames To: .................................................. 7
FEATURES_______________________________________________________
CCNEWS - For Newsletter Editors ............................. 9
LYRICS - The Song Lyrics Server ............................ 10
PHSERVE - The UIUCVMD Phone Book ........................... 12
DEPARTMENTS____________________________________________________
Headlines .................................................. 13
Helpdesk ................................................... 15
New Mailing Lists .......................................... 16
Feedback ................................................... 20
Policies ................................................... 25
* 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: 2930 >--------------------
A publication of the BITNET Services Library
"Because We're Here."
1
Page 1
*********
* * Bitnotes
* *
* * by Christopher Condon
* *
* * Yale University
* *
* * CONDON@YALEVM
*********
"A rose by any other name..."
Suddenly, the air feels very warm. Your palms are sweaty, your
breathing labored. A nervous twitch is working its way up your
arm. You bite your lip. A chill runs down your spine. You
are trying to describe BITNET.
"It's a... well, sort of a... that is..."
You want to convey a feeling, a utility, a sense of community,
but you find yourself not quite eloquent enough. Words fail
you, and a thesaurus is nowhere in sight.
"It's a... kind of... network, see? With computers..."
The computer-guru will demand a technical explanation.
Hardware, link speeds, software. VM/CMS? RSCS? JNET? NRJE?
TCP/IP? Let's wallow in acronyms, shall we? The whole is
greater than the sum of it's parts, however:
"It's a... well, more than hardware! It's people, and..."
Try to explain Listserv and mailing lists to a "non-computer"
person in a minute or less. So they TRULY understand? What is
there to compare it to in real (i.e. non-virtual) life?
"It's a... there are these servers with information..."
True, BITNET is an information service, of a sort. Some might
liken file servers and name servers to similar services on
CompuServe, GEnie, or The Source. That is only small piece of
picture, however.
"It's a... Let's see... we send mail and talk to each other..."
Yes, it is a tool for communications. That is certainly the
largest part of it. However, the same could be said for a said
for a telephone, a television, or a ham radio set. There must
1
Page 2
be something about it that makes it different from these other
devices.
"It's a... we use computers."
You said that before.
"It's a... it's people, dammit!"
People are everywhere. The NRA is people. Scientologists are
people. Even Republicans are people, allegedly. Perhaps there
is something about your people in particular that makes BITNET
different.
"It's a... education and research network."
Oh. Eggheads.
"It's a... No!"
Let's take a different approach. Perhaps you can explain what
BITNET stands for.
"Got you! Because It's There, Because It's Time."
That says a lot.
""
Let's get this straight. BITNET is an information service. It
is a tool for communications. It is a community of people
involved in education and research.
"Yes, yes, yes!"
Oh. Why didn't you just say so?
Virtually,
Chris Condon@YALEVM
*
*******************************************
*******************************************
*
*
*******************************
*******************************
*
1
Page 3
*********
* * The Human Factor
* *
* * by T. D. Stephen
* *
* * Rensselaer Polytechnic Institute
* *
* * STEPHEN@RPICICGE
*********
There is an old bromide, perpetually re-hashed in freshman
communication courses throughout America each Fall semester,
that says, "you cannot not communicate". Usually presented as
an hypothesis, students are challenged to agree or disagree
with it. After sufficient deliberation and debate, the
instructor reveals that "you cannot not communicate" is an
accepted minor tenet of modern communication theory. Everyone
knows that you cannot not communicate because the absence of
communication itself conveys meaning; e.g., if a friend won't
speak to you, you suspect that she's probably trying to tell
you that you've done something wrong.
Suddenly BITNET calls this into question. I can't think of
another communication system that better demonstrates so many
ways in which you *can* effectively not communicate and that
shows so clearly how it is sometimes virtually impossible to
make any sense from communication's absence.
A good example occurs when a new node has been connected to
BITNET before routing tables at existing sites have been
updated. As I understand it, the routing tables allow
computers to know which path to take in sending messages to
each other. People from the new node can send messages
throughout the network because systems personnel there received
a copy of the latest routing table upon joining the net. But
recipients cannot communicate back and, generally, neither
sender nor receiver understands what the devil is going on.
I've seen this periodically when someone from a new node
attempts to contact Comserve@Rpicicge, the communication
studies information system. Jones@Newnode sends the following
message on day 1: "Help". Comserve responds but the network
software rejects the message before it gets very far, often
before it leaves RPI. The new user repeats the "Help" message
on day 2. On day 3 the following: "Hello?". Then on day 4,
"Why don't you respond to me? Please let me know what I'm doing
wrong." That's the end of it; Comserve usually never receives
a message from Jones@Newnode again. Too bad the network can't
1
Page 4
provide Jones with feedback that his/her message traversed
beyond a point of no return.
If information makes the world go around, then it is feedback
that keeps it in its orbit. Feedback corrects, aligns,
adjusts, modulates, attunes; it is the system's defense against
entropy. No system, mechanical or human, can perform
effectively or for long unless its designers have built in
methods for it to monitor and correct its own behavior. It
must have dedicated sub-systems that exist to provide a means
for testing the continued validity of the original assumptions
upon which the system was built and for relaying this
information appropriately. With provision for such feedback,
it is possible for systems to adapt themselves to changing
circumstances. Without it, the system is an inflexible
dinosaur and will begin to break down as its environment
changes.
While there are many points at which mechanical feedback
systems have been built into BITNET and its various services,
there are several critical points at which they are missing and
their absence can be inconvenient and frustrating. Craig White
anticipated this issue in his "Flames-To" column last month
when he identified one of BITNET's principle problems: its lack
of an effective feedback mechanism assuring minimum time to
recovery when a link goes down. Craig noted, as have others no
doubt, that there is a great deal of variance in the degree of
vigilance and responsibility that site personnel display in
monitoring the status of their BITNET connections.
Unfortunately, the network software that allows us to
communicate doesn't do a good job of notifying anybody when it
loses a connection to another computer. A good version of this
software would fix itself, an adequate version would trigger a
flashing light or an audible alarm. Based on what I've seen,
the version we need on BITNET is one that starts deducting from
the salary of the person responsible for maintaining the link
until it is restored.
One feedback system -- the Linkfail mailing list -- was
established to help head off a portion of the confusion
generated by this type of situation. The idea behind Linkfail
is that when a site knows in advance that it will not be able
to provide service for a period of time (due to a scheduled
campus power outage, for example) someone is supposed to send a
note to Linkfail to let the rest of us know about it. Good
idea. In practice, however, this system doesn't work as well
as it should. One problem is that not all sites bother to
inform Linkfail, not even all of the central ones that
virtually everyone depends on (Yale, CUNY, Ohio State, Penn
State, etc.). Another problem is that announcements posted to
1
Page 5
Linkfail are often not channeled to users. It really doesn't
do users any good if, after the systems programmers find out
from Linkfail that the network will be unavailable for three
days next week, they don't tell users at their site about it.
Obviously, it would be better if users could be provided with
more feedback about the status of the network. But in many
cases feedback loops need to be bi-directional, connecting
those who provide BITNET services (file servers, name servers,
mailers, gateways, list servers, etc.) and the people who use
them. Both could profit from each other's feedback. Those who
access services could find out how to use them more
productively and efficiently; those who provide services could
find out how to improve them. Unfortunately, many BITNET
services have not been provided with an adequate system for
human feedback.
Take as an example the common Listserv occurrence of people
sending subscription requests to the address of the mailing
list instead of to Listserv itself. Sometimes hundreds of
copies of the request are delivered to other subscribers, the
subscription request does not itself get processed, and no
feedback is provided to the would-be subscriber (making it a
little difficult to learn from the mistake). Since there
appear to be difficulties in programming Listserv to detect and
respond to these errant requests, there should be, but most
often is not, a human monitor -- someone who can supply the
feedback that the user needs in order to use the system
productively. In addition, there should be an avenue for
*users* to supply feedback to those who provide and maintain
the Listserv software system. There is a "list" named LSTSRV-L
and it provides this function for Listserv operators; they use
LSTSRV-L to communicate among themselves and with Eric Thomas,
the Wunderkind behind Listserv. However, what's lacking is a
similar feedback loop connecting Listserv's users and local
Listserv operators.
As far as I can tell, there has been no formal effort to assess
users' experiences with Listserv, to find out what they like
about it and what they find annoying. Don't misunderstand, I
don't mean to single out Listserv for special criticism;
Listserv merely offers a convenient example, one with which
most of us are familiar. Services on BITNET that provide a
point of human contact or have attempted to gather user
feedback through some other mechanism are a tiny minority.
This phenomenon seems especially dangerous given the computer
industry's well known history of hardware and software ventures
that flop after having been designed without adequate input
from potential users or having gained a reputation for poor
consumer relations.
1
Page 6
One reason that people developing or operating BITNET and its
services may be reluctant to provide mechanisms for gathering
user feedback is that managers may not always place a
sufficient premium on this sort of effort. The word may come
down to "provide users with e-mail access", rather than to
"provide users with an e-mail system that *users* will find
accessible." Basically, the problem is one of leadership.
Certainly most schools that belong to BITNET have the technical
and human resources to provide a higher grade of user-oriented
service; however, without leadership from site managers and
ultimately from BITNET's main administrative body -- the BITNET
Board of Trustees -- these resources may never be brought into
play.
Modeling is one of the most effective forms of leadership and
this is where the Board of Trustees could perform an important
service. They should provide a visible example of responsive
and open communication with the BITNET user community by
sustaining an active effort to solicit feedback about BITNET
and recommendations for its improvement. However, the present
system used by the Board for gathering feedback has no
realistic provision for obtaining input from BITNET's general
user population. If a user has a question, a suggestion, or a
complaint or wishes to have a voice in policy matters, he/she
is expected to channel this through the local BIR (BITNET
Institutional Representative). This individual is supposed to
pass it along to the Board.
Whoever thought this system up was either naive about day to
day business on BITNET, conceived of BITNET as the exclusive
province of computer center personnel, or wanted to create an
appearance of openness while guaranteeing that policy making
would proceed in an environment effectively closed to outside
input. Take a guess: How many of BITNET's users do you think
know who their local BIR is (or their Information Services
Representative or their Technical Representative, for that
matter)? How many sites routinely let new users know who these
people are and that they are responsible for conveying feedback
to the Board? How many BIRs really want to act in this
capacity and have demonstrated so by canvassing users for
input?
I once had a professor who nurtured his reputation as a phrase-
maker and one of his favorites quips was "the facts are
friendly." What he meant by this was that those who actively
solicit feedback will always do better than those who don't,
even if the feedback is negative. Only systems that become
aware of their problems will be able to correct them. So let's
see what we can do to open dialog between BITNET's services,
users, and agencies. Let's come out from behind the automated
1
Page 7
servers and isolated decision-making structures and engage in a
little perception testing. Moreover, let's call on the Board
of Trustees to provide a positive model for effective
communication, one that enfranchises all of BITNET's diverse
groups of users.
***************************************************************
I received a large amount of mail in reaction to last month's
column on making BITNET addresses easier for humans. Much of
this mail was from computer center staff who are sympathetic to
the problem and would like to find solutions and some was from
people who have solutions to offer. Suggestion: write to the
listserv operator at Bitnic, and ask for a new "list" to be
established for discussion of approaches for resolving this
problem. Send me a note when that's accomplished and I'll ask
Editor Condon to announce the list address in next month's
issue.
*********
* * Flames To:
* *
* * by Craig White
* *
* * University of Alabama
* *
* * CWHITE@UA1VM
*********
Hello again,
This month the mail has really poured in. My in-box was so
full at times that it just had to sit. I thought about
different ways to deal with this dilemma but really just
couldn't come up with a very good way to do that. I did get
most of the reading done except for some of the digests. This
month has been a very reliable one in terms of connectivity in
my limited area; I appreciate all the hard work that goes into
that, folks. This month's flame is about, of all things
FLAMES.
As I read mail from the various lists, I often see flames that
are not clearly marked as such. Because we sometimes
misinterpret what we read, I would say that only half of what I
consider to be flames actually are. Most of us are well
acquainted with the phenomena of misinterpretation. Take
computer manuals for instance; I know that many times I have
had problems getting programs to run or commands to work simply
because I misinterpreted what I read in a manual.
1
Page 8
With electronic mail, this misinterpretation seems to be even
more prevalent, and many times with terrible consequences. For
instance, if someone misinterprets one of your postings, you
might get flamed for it. Often, we feel personally attacked
when this happens, and there is a tendency to overreact and
send an inappropriate mailing to the sender of the offending
posting. Or even worse, to the whole list if we feel that we
have been sufficiently slighted.
I suppose that what we really need to keep in mind is that for
most people, mailing to a list is something they didn't put
much thought into. Often, it is a description of a problem
quickly typed and then sent on it's way. Sometimes in the
description of the problem the sender neglects to mention the
pertinent facts and in response someone mails a really
condescending letter back to the group, maybe to make the
person feel that their problem is somehow too trivial for the
group. Many times this is repeated for 10 - 20 times before
everyone feels that they have thoroughly humiliated the foolish
person. The result is usually that even though the problem was
easy to solve, no one remembered to put the answer to it in
their response.
I think that in the above case, the responder who rags the poor
guy for being an idiot, should ALWAYS make sure that their
response is preceded by some kind of FLAME marker. It could be
as cute as "get out your asbestos underwear", or as terse as
***FLAME ON***. The author of such flames should always make
it perfectly clear to whom they are about to flame, and also to
the whole list if it just has to be made public, that they are
about to engage in a display of emotions so that everyone can
get the right perspective about the whole event. If you happen
to be on the receiving end of a flame, try to remember that you
somehow managed to trigger an emotional response on the part of
the flamer and you should keep that in mind as you read their
response. You as the recipient of the flame should avoid
sending a flame back to your flamer for at least one night of
sleep. It seems that many times flames just keeps getting
bounced back and forth until it's an inferno with neither party
able to do anything but fume and send out more fuel for the
other to use. By giving yourself a little time between flames
you give yourself and the sender time to mull over what has
been said, develop a new attitude, or you might even decide
that it's not even worth the trouble to compose a response and
send it off.
Cooling off, I have an LDBASE update. It seems that LDBASE's
ability to search notebooks is totally up to the list owner.
So if you're trying to use LDBASE to help out your in-box as I
am, contact list owners about changing their lists so that you
1
Page 9
don't have to be signed up to peruse their notebooks. Thanks
to Eric Thomas for this LDBASE clarification. As always,
flames, questions, comments to CWHITE@UA1VM.
*********
* * CCNEWS - For Newsletter Editors
* *
* * by Christopher Condon
* *
* * Yale University
* *
* * CONDON@YALEVM
*********
CCNEWS is a weekly electronic magazine for campus computing
center newsletter editors. In it they discuss common interests
and concerns about delivery of news and information. These
include desktop publishing, printing, operational aspects of
developing newsletters, writing, and computing-related issues
relevant to campus computing center information dissemination.
Even if you are not a newsletter editor, but are interested in
desktop or electronic publishing, CCNEWS holds a wealth of
information. A typical piece of information:
"Over the years I have discovered that the programmers and
consultants here generally think they already know how to
write. However, often what I get from them is not necessarily
what I want nor in the form/ style I use in Õmy newsletterå.
Also, many of them take issue when their contributions are
edited into completeness and conformity. I think the
programmers and consultants here do not view writing for
Acronyms as one of their job requirements and would rather
stick to what they like doing -- programming and front-line
consulting. Before developing a seminar to teach these folks
a new skill, I would make sure they wanted to learn!"
Listserv has also enabled the CCNEWS staff to develop an
"Articles Archive" of material submitted by subcribers and
available for downloading for research or reprint (with proper
attribution, of course). The Archive currently contains items
on topics such as piracy, viruses, electronic networking,
stylesheets, microcomputer maintenance, etc.
You can receive a list of thes articles by sending the
following command to LISTSERV@BITNIC via mail or message:
INDEX CCNEWS.
1
Page 10
Likewise, you can subscribe to CCNEWS by sending the command:
SUB CCNEWS Your_Full_Name - Institution. For example:
SUB CCNEWS Henry Chmielewski - Yale University
*********
* * LYRICS - The Song Lyrics Server
* *
* * by the Lyrics Manager
* *
* * University of Massachusetts
* *
* * LYRMAN@UMASS
*********
LYRICS@UMASS is a file server storing song lyrics. It accepts
commands by mail only. The format for a request from the
lyrics server is as follows:
Command/param1=option/param2=option/param3=option
There are 3 commands available for requests.
Lyrics - prints lyrics
Albums - prints album titles and authors
Songs - prints album titles, authors, and songs on albums
These commands will accept 3 parameters.
/Author=xx restricts search to work of author xx
/Album=xx restricts search to album xx
/Song=xx restricts search to song titled xx
Examples:
Albums/Author=Peter Gabriel
lists album titles of Peter Gabriel
Lyrics/Album=So
prints lyrics of any album entitled So
Songs/Album=So
lists all songs on any album entitled So
Lyrics/Song=Red Rain
lists lyrics of any song entitled Red Rain
1
Page 11
Multiple parameters are also valid. For example:
Lyrics/Album=So/Song=Red Rain
lists lyrics of a song Red Rain that is on album So
Albums/Author=Peter Gabriel/Song=Red Rain
lists album by Peter Gabriel that contains song Red Rain
Requesting Lyrics:
To make a request to the server, simply type the appropriate
command line in the body of a message to LYRICS@UMASS. If you
would like to make a request from the server, a good place to
start would be sending just Albums (The Albums command with no
parameters) which will list all album entries.
Multiple requests can be made in one letter by typing each
command set on a separate line. The subject line is ignored by
the server.
The server checks for mail every ten minutes, so a response
shouldn't take any longer than that under most circumstances.
Network replies obviously depend on other factors as well.
Some requests may entail lengthy responses. Users with minimal
file space should be aware of this. Note: a * next to a song
title indicates that it is an instrumental, or no lyrics are
available for it.
Advanced help is available by typing HELP/option where option
is one of the following available topics:
FORMAT - instructions for contributing lyrics
SEARCH - describes the wildcard string search capability
Contributions are always encouraged and appreciated.
Please send all questions, comments, corrections, additions,
and whatnot to: Lyrics Manager, LYRMAN@UMASS.
*
*******************************************
*******************************************
*
*
*******************************
*******************************
*
1
Page 12
*********
* * PHSERVE - The UIUCVMD Phone Book
* *
* * by Charley Kline
* *
* * University of Illinois
* *
* * KLINE@UIUCVMD
*********
PHSERVE@UIUCVMD is a database of faculty, students, and staff
at the University of Illinois at Urbana-Champaign. The server
accepts interactive BITNET message (not files or mail) and
looks up names in an online copy of the phone book at the
University of Illinois at Urbana-Champaign. Specifying a
single name will look up entries with a first last, or email
name. Specifying multiple names will force returned entries to
match each name given.
By default, queries are assumed to refer to the name field of
the entry. Therefore, a query of "john doe" looks for entries
whose name contains "john" and "doe." Fields other than the
name field must be specified. For example, "dorner
address=DCL" would return entries which contained "dorner" in
the name and whose address contained "DCL."
Matching is done on a word-by-word basis. That is, both the
query and the entry are broken up into words, and the
individual words are compared. Although the nameserver is
insensitive to case, it otherwise requires words to match
exactly; "john" does *NOT* match "johnson," for example.
Only entries that match *ALL* of the specifications in the
query are returned. For example, "charles kline" will return
all entries with *BOTH* "charles" and "kline" in the name
field. Note in particular that this query is identical to
"kline charles."
A certain set of fields are returned by default. It is
possible to ask for different fields in a query. This is done
by specifying the "return" keyword, and listing the fields of
interest. For example, a query of "steven dorner return email"
would return only the electronic mail address of Steve Dorner.
Results are returned by BITNET interactive messages if the
reply is sufficiently short; otherwise they are sent in a file
called "PHSERVE REPLY."
Queries may contain any combination of the so-called
metacharacters, *, ?, and Õå. Metacharacters can be used to
1
Page 13
specify wildcards or alternates within a query. People
familiar with UNIX will recognize these metacharacters as
identical to those recognized by the UNIX shell.
The metacharacter "?" represents exactly one unknown character.
Thus, "johns?n" matches "johnson" and "johnsen" but not
"johnsenn."
The metacharacter "*" can be used in a request to indicate zero
or more unspecified characters. For example, "kl*e" will match
"kline", "klemme", and "kluge". Be warned, however, that
queries resulting in too many matches will be refused.
Square brackets represent a match of one of the characters
inside the brackets. For example, "johnsÕoiån" will match
"johnsin" and "johnson" but not "johnsen" or "johnsoin."
For examples and more detailed information, send
PHSERVE@UIUCVMD the command "?".
*********
* * Headlines
* *
* * Smaller specks of news...
* *
* * ...but not unimportant!
* *
* * Send them to BITLIB@YALEVM
*********
* Hey!: Please remember that the file server NYSHARE@WEIZMANN
will only accept commands sent by interactive message, not
mail. Too many mail messages will result in a server shutdown.
* Listserv news: Goz Lyv tells us of yet another FILELIST.
The HELPCONV filelist on LISTSERV@BYUADMIN stores (what else?)
the HELPCONV software package.
* Mike Roberts, Vice President, Networking, EDUCOM: "I am very
sorry to announce that Judy Molka will be leaving the BITNIC
staff in August so that she can pursue a Master's degree in the
Univ of Pittsburgh Telecommunications program. Her talented
and dedicated contributions to BITNET are known far and wide.
I am sure you will join me in wishing her well as she takes
this important career step. We are mailing a position
announcement for a Network Services Consultant to replace Judy
to all BITNET Institutions Representatives. We solicit
applications from all qualified individuals. If you are not an
1
Page 14
IR and would like a copy of the position announcement, please
contact Elizabeth Kilcoyne of the BITNIC staff
(KILCOYNE@BITNIC)."
* TRICKLE: A copy of the TRICKLE file server has been
installed in Denmark. This server is the same as the one
described in the May issue of NETMONTH by Turgut Kalfaoglu
(TURGUT@TREARN). Our TRICKLE can be contacted on
(TRICKLE@DKTC11). TRICKLE provides you with directory listings
and file from the SIMTEL20 personal computer software archives.
To get in touch with TRICKLE you can send it the command /HELP.
Thanks to Alan Jacobsen for this update.
* NICSERVE@BITNIC is being replaced: All files in this
directory are now available through LISTSERV@BITNICs NETINFO
FILELIST. Please use LISTSERV@BITNIC in the future to obtain
these files. On September 1st 1988, NICSERVE will no longer
have access to these files, instead a note recommending the use
of LISTSERV@BITNIC will be the only response to commands.
Since the BITNIC Staff cannot change the format of the NETINFO
FILELIST (because certain operations of the server are tied
into the format of the index), the following procedures have
been initiated to support both old and and new index formats.
They will presently maintain the hand-edited NICSERVE INDEX and
a newly created NETINFO INDEX (an exact copy of the NICSERVE
INDEX), along with the NETINFO FILELIST. After the September
1st replacement of NICSERVE by LISTSERV, the files NETINFO
INDEX and NETINFO FILELIST will be maintained.
To get the "old" format index, you can do one of 3 things:
Send the command INDEX to NICSERVE@BITNIC.
Send the command GET NICSERVE INDEX to NICSERVE@BITNIC.
Send the command GET NETINFO INDEX to LISTSERV@BITNIC.
To get the "new" format index, you can do this:
Send the command INDEX NETINFO to LISTSERV@BITNIC.
Send the command GET NETINFO FILELIST to LISTSERV@BITNIC.
Again, after September 1st, commands sent to NICSERVE@BITNIC
will not work.
*
*******************************************
*******************************************
*
1
Page 15
*********
* * Helpdesk - a Question and Answer column
* *
* * by Marc Shannon
* *
* * Carnegie Mellon University
* *
* * Send your questions to HELPDESK@DRYCAS
*********
Well, here I am! All ready for my first column! (I've always
wanted to be in "print", but I had figured that it would be on
a National Security Administration print-out.) I guess I'll
just jump right in...
*Q* How does interactive messaging affect file transfers on
BITNET?
*A* Messages, either as a "message" between two users (with or
without Relay) or as a "command" from a user to another node on
BITNET, can be considered as small, urgent files. As a file is
being transmitted on a BITNET link, it is broken up into
packets. These packets are used to fill up a "block" on one
computer and are then transmitted to the other computer.
When a message is to be transmitted across that link, it is
inserted into that block (taking up the space that a file
packet might have used). More messages, less file packets.
This is why, generally, large files may take overnight to be
transmitted across heavy-traffic links (such as PSUVM-CUNYVM).
During the day, many small files (such as mail files) are
enqueued and get sent before the larger files. Then, in the
evening and early night, people get on Relay and send messages
(quite a few) across these links. Some large files may not get
a chance to begin transmission until two or three o'clock in
the morning.
*Q* Besides RELAY, what other services does BITNET provide?
*A* BITNET provides one of the best services just in its
existence: the ability to communicate (either online with
messages or offline with mail) to friends and colleagues across
the WORLD. (Mithrandir and I spend time occasionally just
marvelling at the power we have at our fingertips.) (Ed. note:
BITNET is really just the United States. The larger-scale NJE
network includes BITNET, EARN (Europe), NetNorth (Canada), and
AsiaNet.)
The file BITNET SERVERS (sent along with NetMonth and available
in the archive locations listed at the end of this magazine)
1
Page 16
lists many, if not all, of the servers running on BITNET.
Through the file servers and mailing lists available, you'll
find many things to do.
*A* (additional) to last month's question "Can all nodes on
BITNET send and receive interactive messages?" It has come to
our attention that there are non-IBM programs available that
can be installed which allow TSO users to send and receive
interactive messages. If you would like to receive more
information about this, send mail to HELPDESK@DRYCAS and we'll
pass the information on to you.
*********
* * New Mailing Lists
* *
* * from List-of-Lists
* *
* * by Rich Zellich
* *
* * ZELLICH@SRI-NIC.ARPA
*********
AIX-L
This list is intended for the discussion of the AIX operating
system, IBM's Unix solution for small and large computer
systems. Initially, this list will be used for dissemination
of information and technical details of AIX on all levels. It
may be necessary to break this list down into machine types
that AIX will run on.
All requests to be added to or deleted from this list,
problems, questions, etc., should be sent to the Moderator.
Moderator:
Michael R. Gettes
ANDREW-DEMOS
A mailing list to be used simply for demonstrations of the
Andrew system software. You should not subscribe to it unless
you expect to be reading it with the Andrew Message System, as
messages will come to the list in full multi-media format.
Indeed, we encourage people to post lots of neat animations,
music, raster images, and the like to this list.
To be added to the list, send mail to ANDREW-DEMOS-
1
Page 17
REQUEST@ANDREW.CMU.EDU. To submit new items to the list, just
send them to ANDREW-DEMOS@ANDREW.CMU.EDU.
Coordinator:
Nathaniel Borenstein
ANTHRO-L
This list deals with discussions of various techniques and
fields of research in Anthropology. Some suggested topics of
discussion are:
- Computation in anthropology
- Graphics in archaeology
- What programs anthropologists are using at various places
- Where centers of computer interests are in anthropology
- Anglo-Saxon cemeteries
- Palaeodemography
- Some spirited words on political economy
- The development of Anglo-Saxon cemeteries
- The Northumberland landscape
- The population of Anglo-Saxon England
To add yourself to the list, send the following command to
LISTSERV@UBVM via mail or message: SUBSCRIBE ANTHRO-L
Your_Full_Name
Coordinator:
Patrick G. Salsbury
BMDP-L
Discussion group for users of BMDP software.
All requests to be added to or deleted from this list,
problems, questions, etc., should be sent to one of the
Coordinators.
Coordinators:
Michael Walsh
Sander Wasser
CONS-L
This group provides a forum for university computing centre
consultants to discuss such issues as problem tracking,
resource management, training, and consulting strategies.
1
Page 18
All requests to be added to or deleted from this list,
problems, questions, etc., should be sent to one of the
Coordinators.
Coordinators:
Michael Walsh
Sander Wasser
ENVBEH-L
Mailing list on Environmental Behavior: Environment, Design,
and Human Behavior. ENVBEH-L is a discussion on a variety of
topics concerning the relations of people and their physical
environments, including architectural and interior design and
human behavior, environmental stress (pollution, catastrophe)
and behavior, human response to built and natural settings,
etc.
To subscribe, send the following command to LISTSERV@POLYGRAF
via mail or message: SUB ENVBEH-L Your_Full_Name.
Coordinator:
Tony Monteiro
IFPHEN-L
Discussion group on Interfacial Phenomena (Group 1c, American
Institute of Chemical Engineers). Meetings, articles,
software, theories, materials, methods, tools, etc., are
discussed.
To subscribe, send the following command to LISTSERV@WSUVM1 via
mail or message: SUB IBMTCP-L Your_Full_Name.
Coordinator:
Richard L. Zollars
MBA-L
The MBA-L student curriculum discussion mailing list is for any
information or news about MBA programs, their administration,
problems, issues, questions, etc.; it is intended for
administrators, faculty, and MBA students.
To subscribe, send the following command to LISTSERV@MARIST via
mail or message: SUB MBA-L Your_Full_Name.
Coordinator:
Bob Comerford
1
Page 19
STAT-L
An open discussion group dealing with statistical consulting at
university computing centres.
All requests to be added to or deleted from this list,
problems, questions, etc., should be sent to one of the
Coordinators.
Coordinators:
Michael Walsh
Sander Wasser
VIRUS-L
Mailing list for the discussion of computer viruses. The
discussion originally focused on IBM PC viruses but Mac, and
other types of, viruses are sometimes discussed as well.
Archives are available, as is a file called DIRTY DOZEN which
lists a number of viruses, trojan horses, and pirated programs
for the IBM PC.
To subscribe, send the following command to LISTSERV@LEHIIBM1
via mail or message: SUB VIRUS-L Your_Full_Name.
Coordinator:
Jig Shaffer, Jr.
*
*******************************************
*******************************************
*
*
*******************************
*******************************
*
*
**********************************************************
**********************************************************
*
*
******************************************
******************************************
*
1
Page 20
*********
* * Feedback
* *
* * a Letters column
* *
* * "Back in the USSR?"
* *
* * Send your letters to BITLIB@YALEVM
*********
From: Ted Herman
Subject: Suggestions
I'd like to offer some ideas for NetMonth:
1. I've seen several recommendations of "Toward an Ethics and
Etiquette for Electronic Mail" in issues of NetMonth. Yes, a
PREscriptive work on the manners of electronic mail is a worthy
effort and I can well understand why you recommend it. But I'd
also like to see, on a continuing basis, DEscriptive work on
the manners of electronic mail. I'm no anthropologist, but I'm
entertained by comments like:
> I'd be interested to know the mix of people who squaked
> on USENET. What kind of users are they on USENET?
...
USENET, on the other hand, was always the "wild and wooly"
bunch. Much less quick to "authoritarian" standards --
much more libertarian in the belief that not only does
EVERYBODY have an opinion, but that it is one's DUTY to
express that opinion.
...
If one goes to "usenix" one sees "typical" college students
in the majority -- sandles, shorts and t-shirts. If one goe
to "/usr/group" one finds the "typical" business type --
shoes, long slacks and Grateful Dead T-shirts.
( the above excerpted from a recent letter in UG-L )
2. On much the same theme, I would REQUIRE that announcements
and reviews of mailing lists contain edited portions of typical
letters. Have you noticed how samples included in reviews of
Whole Earth Review enhance the reviews? I find that a "Time-
Life" keyword abstract of a mailing list's masthead doesn't
show me the personality of the list. Wouldn't it be nice to
1
Page 21
see some typical samples, synopsis of recent topics and
controversies, rather than go to the trouble of subscribing and
finding out for yourself?
Usual disclaimer/apology: please accept these comments as
constructive criticism, I do not mean to deprecate your effort,
keep up the good work, rah rah rah, etc.
*Editor's Note* Unfortunately there are several obstacles in
providing such a service (although it would be nice). First,
the lists we announce are new, so there would be often little,
if anything, to review. The big problem however, would be that
the length of these reviews would add to an already too-large
NetMonth. Keep the ideas coming!
From: David Benson
Subject: Addresses
I find most of NetMonth very interesting and I appreciate that
the articles are signed with names. But I find it frustrating
that only BITNET addresses are used. UA1VM doesn't tell me
much. Maybe I should know where Craig White comes from, but
I'm a relative newcomer to BITNET and don't. Maybe I'm not
supposed to know where Craig White comes from, but why?
Tim Stephen's article on the problem of user ids makes a good
point, and I THINK his address means he is from Rensselaer
Poly, but I'm not sure. Would it take too much space to
include "real" addresses or at least identifiers for NETMONTH
contributors?
*Editor's Note* See changes this issue.
From: Dave Phillips
Subject: Bring BITNET to the USSR?
A recent article in Netmonth suggested that efforts be made to
bring BITNET to the USSR.
This would be a great idea if and only if access to the links
at the Soviet side were not rigidly controlled and rationed to
"reliable" people.
A more workable trial might be Poland, which has a much freer
society (despite the authorities) than the USSR's, a *very*
Western popular outlook, a large number of young people eager
to work with computers, and (like the USSR) a good percentage
of students know English and/or other European languages.
1
Page 22
Since Poland has entered the International Monetary Fund, and
since the PPR has (like the USSR) participated nominally in
signing and reiterating the Helsinki accords when convenient,
it would be of great interest to see if the PPR regime would
accept an uncensored linkage to BITNET, e.g., via neighboring
Sweden.
From the PPR government's viewpoint, they would have to weigh
the consequences of further 2-way flow of information with the
computer know-how to be gained from Western scientists,
technologists, and students. The decision made would most
likely be a technocratic one, unless the Soviets make the
decision (veto) for Warsaw.
From: Gabriel Basco
Subject: Bring BITNET to the USSR?
About getting the USSR into BITNET. Great Idea!!!! But one
little, if they don't let Western News go in, how are they
going to allow a whole bunch of wild people like the ones that
use BITNET, talk with their students. NO WAY!!!!!
From: Dave Gomberg
Subject: Communicating
Steve McClusky (sp?) writes recently about those who have
little or no reason to use a BITNET connected machine
frequently, and thus do not receive mail promptly. This is
indeed a problem. It is analogous to a situation where I might
rarely (or never) check my US mailbox. The solution for this
case is not to hire someone to check my mailbox, but to advise
correspondents that they should not expect to reach me by US
mail.
If you are at a BITNET institution, but do not access your
mailbox regularly, do not advertise a BITNET address as
effective for reaching you. Advertise those techniques that
are effective for your behavior patterns (US mail, phone, or
whatever). If you elect not to use your BITNET address, that
is your prerogative, just as it is your choice to have or not
have a fax or a phone.
It is not the responsibility of the telephone office to take
messages for you and send them to you by courier if you elect
not to have a phone. It is not the responsibility of your
BITNET site to pass material on to you should you elect not to
be a BITNET participant. Please do not expect the computer
folk to be your messengers.
1
Page 23
From: Terence Sommerville
Subject: Answering unread mail
In last month's issue of Netmonth Stephen McClusky takes up the
issue of people not answering their VM mail. He suggested that
perhaps the local computer centers might generate a daily paper
postal listing of who has mail so as to save the time of
logging on for those that rarely have time to check their mail.
I wish to suggest a slightly different possible solution for
the same problem. What if someone wrote a program to scan all
the mail as already suggested last month, but then to display
this information all day on one or two dedicated terminals at
the main doorways to the campus and perhaps in the library. In
addition it might be better if people were also allowed decide
whether they wish to be included or excluded from the daily
scans of all the mail. In addition a dedicated server on each
node could also hold this data, so that if you were to see a
friend of yours logged on they could query the system for you
thus saving oneself the hassle of getting them to logoff while
you "quickly" logon to check.
However for some places that could afford it the one or two
terminals could be expanded to cover either every major
entrance and or regular meeting places such as main notice-
boards, the canteen/restaurant or perhaps even the college bar!
If one or two sites implemented such as system as above or the
system using the paper listing for a trial period then it might
give an indication as to whether it would be worth the effort.
For the long term I feel that it is essential to get the "non-
computer" people to use BITNET and to prove they can benefit
from it. In this way whenever the issue of funds or money came
up with respect to the site contribution to the network, then
we would not have competing groups for a given amount of money,
but rather the whole community would be unanimous on this
particular issue. In the past it has been seen on BITNET as new
programs and facilities are added new possibilities for network
use are opened up, which increasingly bring in new users that
would not otherwise dream of going near a terminal.
At the end of the day this question of answering unread mail
can only be answered if the whole task of inter-facing to the
"non-computer" type can be made steadily easier to the point
that these people will then want to regularly check their
Readerlist. In effect the job of the normal postal system has
to be emulated in that the mail has more or less to be handed
to them on a plate. To do this by computer printouts would in
the long term only generate masses of paper most of which just
makes the whole thing more confusing, thus defeating the
purpose of stream-lining and simplifying communications.
1
Page 24
From: Tony D'Angelo
Subject: Listserv REPRO (self copy) Option
A while back I started inquiring why the sender of a posting to
a list maintained by LISTSERV did not receive a copy of his/her
message posting, even though every other member of the list
did. Thanks to Jim Gerland (who contacted Eric Thomas) we
found out that there is a LISTSERV distribution option
called "REPRODUCE = YES" which will implement this self copy
feature. The owner of the list cannot make a current list REPRO
but he can make it REPRO for anyone who signs up after he
changes the LISTSERV header for a given list. Also, the owner
as the capability to change each current member's distribution
option to REPRO = yes.
I would like to suggest that future LISTSERV software revisions
have "REPRODUCE = YES" as the default condition when creating a
list (if this hasn't already been done). I think everyone would
always want to receive a copy of his/her posting to a list,
just to see how it looks, if and when it got distributed, if
there are any gross errors in the message, etc. Also, as time
permits, I would like to suggest that all list owners at the
various locations where LISTSERV is being run change the
distribution option of each member of their existing lists to
make them REPRO capable and change the list headers to
"REPRODUCE = YES" for all future subscribers.
In the meantime, individual users can send the SET
REPRO command to any LISTSERV@ of which they are a
member to activate the self copy feature for themselves. To
remove this feature the syntax is SET NOREPRO.
Reminder: the SET command is sent to the *LISTSERV* @
and *not* the .
*
*******************************************
*******************************************
*
*
*******************************
*******************************
*
*
**********************************************************
**********************************************************
*
*
******************************************
******************************************
*
1
Page 25
*********
* * NetMonth Policies
* *
* * Everything you ever wanted to know...
* *
* * ...but were afraid to ask.
* *
* * BITLIB@YALEVM
*********
NetMonth is a network service publication distributed free of
charge to students and professionals in BITNET and other
networks. This magazine and its companion file, BITNET SERVERS,
are the work of the BITNET Services Library (BSL) staff and
contributors from around the network.
BITNET SERVERS is BITNETs list of servers and services. If you
know of servers not listed in BITNET SERVERS, or if some listed
are no longer available, please contact the NetMonth Editor.
* Subscribing to NetMonth and BITNET SERVERS:
Send the following command to LISTSERV@MARIST by mail or
messgage:
SUBSCRIBE NETMONTH Your_full_name
Internet users may use this method, but must address the mail
to LISTSERV%MARIST.BITNET
* Back issues:
BITNET users may get NetMonth back issues from the file server
LISTSERV@CMUCCVMA. The FILELIST for these archives is aptly
named NETMONTH FILELIST. Send the command INDEX NETMONTH to
the server for a list of files.
A subscriber can delete him/herself from the mailing list by
sending LISTSERV@MARIST the UNSUBSCRIBE NETMONTH command.
* Letters to the Editor: If you have questions or comments
about BITNET or NetMonth that you would like to see printed
here, mail your letter to BITLIB@YALEVM. Make sure that you
specify in the "Subject:" header or somewhere in the letter
that it is for the NetMonth letters column.
* Article Submissions: The only requirements for NetMonth
articles and columns are that they be informative, interesting,
and concern some BITNET-related topic. Send your articles and
to BITLIB@YALEVM.
1
Page 26
* Printing this file: VM users can print this file by first
copying it to NETMONTH LISTING and then printing the new file.
This will allow page-breaks and other formatting to be accepted
by your printer.
_
__-
__--- The
__----- BITNET
__------- Services
___________ Library "Because We're Here."
***************************************************************
|
|
