|
|
|
|
|
|
|
|
NetMonth, March 1988
******** **************************************************
* * *
* * The independent guide to BITNET *
* * *
* * March, 1988 *
* * *
* * Volume 2, Number 9 *
******** * *
* *
*** * *
* * * * *
* * * * *
* * * * *
* ** * *
* *
* * *
* * *
****** * *
* * *
* * *
* *
******** * *
* * *
* * *
* * *
* * *
* * *
******** * *
* *
*** * *
* * * *
* * * *
* * * *
*** * *
* *
****** * *
* * *
* * *
* * *
**** * *
* *
* * *
* * *
****** * *
* * *
* * *
* *
******** * *
* * *
* * *
* * *
**** **************************************************
1
* * * * *
** * * ** ** * * *
* * * *** ***** * * * * *** **** ***** ****
* * * * * * * * * * * * * * * *
* * * ***** * * * * * * * * * *
* ** * * * * * * * * * * *
* * **** * * * *** * * * * *
***** ******
Christopher Condon Editor CONDON @ YALEVM
Mike Patrick Contributing Editor PATRICK @ 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 19 ********************
EDITORIAL PAGE_________________________________________________
Bitnotes .................................................... 1
The Human Factor ............................................ 3
Forty-two ................................................... 8
Comments of a So-so Happy Crossnet User ..................... 9
Flames To: ................................................. 11
FEATURES_______________________________________________________
NetCon88 ................................................... 13
foNETiks ................................................... 15
The DECWRL Archive Server .................................. 16
CDNet and EAN .............................................. 18
DEPARTMENTS____________________________________________________
Headlines .................................................. 20
Helpdesk ................................................... 21
Feedback ................................................... 22
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: 2331 >--------------------
A publication of the Bitnet Services Library
1
Page 1
*********
* * Bitnotes
* *
* * by Christopher Condon
* *
* * CONDON@YALEVM
*********
"You can't get there from here."
I have a large, yellow notebook in my bookcase, filled with
notes and printouts from my first months in BITNET. There are
old node lists, documentation on long-forgotten servers, early
issues of FSFNET... a treasure trove of network history. You
might say that the notebook is the beginning of all we have
come up with in the past few years. Everything from Bitlist to
NetWeek has it's origins in those tattered pages.
When looking through those printouts, I realize how much the
network has changed over the past few years. Oh, it has grown,
to be sure, but there are other, less obvious, changes to
consider. The very way in which we access information in
BITNET has been altered... dependant upon the actions of a
relatively small number of individuals.
For example, take LISTSERV (please). In little over a year it
has become the dominant type of server in BITNET, changing
drastically the way we communicate. It has made mailing lists
and forums the norm rather than the exception. Previously
there were a few well-informed people who belonged to ARPANET
mailing lists (SF-LOVERS and INFO-NETS come to mind), but the
vast majority of people knew nothing of these. The most common
information resources were file servers and electronic
magazines.
Enter, stage left, LISTSERV. The first BITNET list server was
developed and installed by BITNIC. It worked fairly well but
did not receive much in the way of support or accolades.
Enter, stage right, Eric Thomas at FRECP11 and his improvement
on the concept of the mailing list server. What he added
(among other things) was the ability for a mailing list to
exist at multiple servers by "peering" the lists. People could
subscribe to a list at a LISTSERV close to their node, rather
than subscribe at a cental location. This spread out the load
which would be caused by a mailing list, rather than bog down
the links around a central list server.
1
Page 2
More importantly, the spread of these servers made mailing
lists accessable to everybody. You'd like to start a forum for
people interested in pond scum? Contact the coordinator for a
a nearby LISTSERV and ask him about it. You want to subscribe
to an ARPANET mailing list? There is a LISTSERV nearby where
you can send your request. The growth in mail volume over
BITNET has been tremendous.
All of this might not have happened if Eric Thomas hadn't
decided to improve upon the original LISTSERV concept. PERHAPS
someone else would have thought of it, and PERHAPS someone else
would have taken the time to produce such a server, but I doubt
it.
A similar turn of events took place a few years earlier. Henry
Nussbacher took the time to point out the weaknesses and
problems with single-node conference machines. Jeff Kell took
it upon himself to address these problems. Today we have the
Relay Conference Machine system, allowing real-time BITNET
conversations among groups of people (as opposed to only two
people).
These and other contributions by a few determined people have
changed and improved the way we access information in BITNET.
They have, in fact, become prime selling points in promoting
the use of the network. I am not suggesting that these Eric
Thomas and Jeff Kell did this on their own. There are many
people who have worked very hard to build and support the
Listserv and Relay systems we have today. However, the initial
effort, sacrifice, inspiration, (whatever you want to call it)
was theirs alone.
This is keeping with the original spirit of BITNET: A network
where most of the development and support were provided on a
voluntary basis. It is to the people who gave their time while
the network was growing that we owe round of thanks, a pat on
the back, a pedestal on which to stand, praises sung it jazz
harmony....
Now that I have established the religion, allow me to play
Devil's Advocate and trample on it.
Where does this voluntary effort lead us? Some applications
get extreme attention (Listserv) while development on others
doesn't get a second thought? Who decides what services are
important enough to work upon and which ones are not? Are we
held by the whim of a Rexx programmer somewhere who may or may
not decide to develop the next major server? If he/she doesn't
do it, will someone else?
1
Page 3
What if someone builds an alternative to Listserv that is
better, faster, and more efficient? Will a working Listserv
network be dismantled? Who would supervise the transition?
Would there be any, or would the idea die on the vine, crushed
by the popularity of the current system?
To but it bluntly:
Who will coordinate servers and services in BITNET?
Who is planning the future of BITNET, if at all?
Who is at the helm?
Virtually,
Chris Condon@YALEVM
*********
* * The Human Factor
* *
* * by T. D. Stephen
* *
* * STEPHEN@RPICICGE
*********
Last month, in an aside during my discussion of BITNET's
culture and its specialized language, I challenged readers to
find a common language equivalent for that ghastly phrase, so
familiar to many who use BITNET on CMS systems, "spool your
virtual punch to rscs" (in fact, what one actually types is "sp
pun to rscs cl m"). I'm sorry to report that that challenge
has not been satisfactorily met. The one attempted translation
I received took half a screen and began with "Send your
electrons...". It was an interesting effort, but nothing
beginning with "Send your electrons..." is quite what we are
after.
"Spool", I understand, is actually an acronym for "Simultaneous
Peripheral Operations On-Line" and provides a good example of
how fantastically obscure network communication concepts can
be. Not only is "simultaneous peripheral operations on line"
entirely without meaning for anyone who is not a computer
specialist (try turning conversation toward "simultaneous
peripheral operations on-line" the next time your family gets
together), but it's acronym, "spool", actually misleads in its
apparent association with the weaving trades. "RSCS" ("Remote
Spooling and Communications Subsystem"), the other acronym in
1
Page 4
that phrase and a gem in its own right, at least doesn't steer
you wrong in its associations. Since it has no vowels, it can
be readily filed as just another vague acronym.
Requiring users to type "spool pun to rscs cl m" before sending
mail over BITNET is linguistic tyranny, pure and simple. It is
a bit like the public schools requiring children to recite the
pledge of allegiance. In many cases young children may not
understand the significance of what they are uttering and may
not even get the words right. But they do understand that it
is somehow important that they engage in the ritual.
Similarly, anyone interested enough in BITNET to make the
effort learns that, whether "sp pun to rscs cl m" ultimately
means anything or not, it's the right thing to type. From the
user's point of view, being required to type "sp pun to rscs cl
m" is no more sensible than being required to chant "nasa
flapjack to naacp form 1040a" before being allowed to use the
rest room.
Primitive computer concepts like "sp pun to rscs cl m" are not
unique to IBM CMS computers. Try a Unix system sometime if you
want to experience this phenomenon at its hair-raising worst.
There, when you want to see a list of the names of all of your
files, you type "ls"; when you want to see the names of all of
the files that contain the word "flapjack," you type "grep
flapjack." Even more awe-inspiring in its obscurity, in its
utter disregard for common sense, in its sheer nose-thumbing at
the user's frame of reference -- to list the contents of a
particular file on your screen, you type "cat" followed by the
name of the file (the new user wonders if typing "dog" will
send the file to the printer).
The newcomer to BITNET confronts a maze of obscure concepts, a
fog of "techno talk" that we simply have to lift if BITNET is
to become a useful tool. You can argue, if you wish, that
every academic specialty requires newcomers to learn unfamiliar
terms and obscure ideas and you would be correct. Even in
human communication studies newcomers confront "sememe",
"kinemorph", "pentad", "talkover", and "double interact" to
mention only a few. But BITNET is meant to be a service, not a
discipline of study. And in order to be a useful service, it
needs to communicate with its users in a manner that they
understand and find familiar.
Not long ago computer communication systems were used almost
exclusively by computer scientists and engineers and it is
sensible that the language system they evolved to work with the
technology would reflect their own habits of thought and
economies of expression. In fact, the creation of the "spool"
1
Page 5
process marked an important technological advance and its
metaphoric reference to winding threads around a cylinder is
not inappropriate given what actually occurs when computers
"spool" things (thanks to John Fisher, RPICICGE, and David
Chess, IBM Yorktown, for this information). However, now that
the technology has moved from the specialized domain of
computer scientists and has been placed in service as a
communication medium for as diverse an audience as exists in
higher education, there is a profound need to translate its
operational concepts to ones that are appropriate for people
with little time and sometimes, I'm afraid, little interest in
computer science itself.
To accomplish this, many sites have obtained or created
software that protects users from having to confront primitive
commands like "sp pun to rscs cl m". Here at RPI's Center for
Interactive Computer Graphics, for example, we can type
"Bitnote" and a much friendlier program comes alive that
handles sending mail over BITNET without the user ever having
to type or even think about "sp pun to rscs cl m". The Bitnote
program also packages the mail in a way that saves the user
from having to learn about RFC822, the "standard" for network
mail. This is a good thing because reading about RFC822 is
enough to drive anyone from BITNET for life. (The RFC822
document is available from Nicserve@Bitnic as file RFC822
STANDARD, but take my word for it, you'd rather read your
income tax forms.)
Though many sites provide Bitnote or an equivalent program,
there are others that do not and in some cases, though such
programs are provided, not enough has been done to let users
know that they exist. The University of Connecticut maintains
a program named "Memo" that is similar to Bitnote but to use
it, users have to create a "link" to a detached "virtual mini-
disk" and then "access" the disk. Although a little program is
provided to help users to do this, the extra step is apparently
enough to keep people away. Most of the mail that my
colleagues from Uconnvm send continues to arrive in non-
standard formats. Comserve users from a number of other sites
seem to be similarly disadvantaged.
"Bitnote" is a particularly good name for that program because
its associations imply its purpose -- Bitnote is used to send
"notes" over "BITNET". Bitnote comes easily to both the tongue
and the fingers, and is not built upon obscure words or
concepts like the Unix "cat" command. "Cat" is, in some
strange way, short for "concatenate", a word that should have
been avoided since "join" or "combine" could have done as well
and are far more commonly used (of course, the fact that
1
Page 6
listing a file on your terminal screen has nothing whatever to
do with joining, combining, or concatenating anything is
another problem).
The suffix "serve", derived from "file server", as in
"Netserv", "Nicserve", "Bitserve", "Comserve", etc. is also a
poor choice, although I think it is here to stay. Serving is a
weak metaphor for what these programs actually do and "file
servers" are something that computer specialists relate to, not
ordinary people, not the educational and research community
that BITNET ostensibly is in place to serve. "CSNews" was an
excellent choice for an information service for computer
science and "Relay" a defensible choice for a method of
relaying messages. The choice of "Listserv", however, was a
mistake for a service that is, potentially, the most valuable
asset of BITNET. People rarely aspire to belong to "lists" and
if the name has any metaphoric value at all, at best it
suggests that Listserv is where one goes to get lists of
things, which, of course, it is not. A similar system that is
available to local users on RPI's MTS system is called "Forum"
-- a much better name.
The social entities that form via Listserv are sometimes
referred to as "groups", sometimes "conferences", and sometimes
just "lists" (as in "I'm a member of the Mail-L list").
Obviously, people do not form into "lists", but, perhaps less
obviously, what occurs via Listserv does not much resemble what
happens in group or conference interaction either. Our feeling
at Comserve was that what usually happens on Listserv is more
like what happens on hotlines than anything else -- people use
them to deliver news or write asking for help; others respond
with advice or opinion. Since we switched to calling our
"lists" "hotlines," we've found it easier to orient faculty and
students to the service.
I think it a failure of foresight that so many computer
commands and programs have been inappropriately named. Anyone
who has brought a child into the world -- or has been close to
new parents -- knows how much care and thought goes into the
selection of a name. We all recognize that the name we choose
will influence the way that the world relates to the child
throughout life. Why has this simple truth been so often
ignored in the realm of computers and technology? Why, for
example, was a sophisticated file transfer and terminal
communications program, "Kermit", named after a frog puppet?
What did the authors of "Grand" hope to accomplish by naming it
that? What did the Unix community have in mind when they chose
"finger" as the name for a command that tells you who another
user is? Did they expect that Unix would be popular among
mobsters?
1
Page 7
Even in the choice of the name "BITNET", it would seem that the
desire to communicate our technological orientation outweighed
whatever advantage might have been gained by choosing a name
that said something about the network's purpose or user
population (but perhaps this wasn't clear during the network's
beginnings). Interestingly, the Europeans chose differently:
"EARN" stands for "European Academic and Research Network".
"BITNET" is a jazzier acronym than "EARN". But when you unpack
it ("Because It's Time Network") it is unclear what it
communicates except, God forbid, that we are the network for
Ernest and Julio Gallo's production vineyards.
BITNET's limitations and problems are often discussed with
reference to its technology. Items such as queue sizes,
transmission speeds, limitations in the RSCS network protocol,
and ambiguities in the RFC822 standard are frequently
identified as key problems, the solutions of which are not
self-evident, cheap, or easily implemented. However, the
quality of service provided by BITNET could be improved
substantially, quickly, and at little cost if only we would
give more consideration to the frames of reference that
characterize the population that BITNET serves. Immediate
gains could be made if the names of the commands and services
that are related to using the network were brought in line with
the language of every day life.
Perhaps Shakespeare did us a disservice when he had Juliet
question whether Romeo Montague would be any different if he
had been named something else ("What's in a name? That which we
call a rose by any other name would smell as sweet.").
Frankly, if he had been named "Sp-pun-to-rscs-cl-m Montague" I
doubt if their romance would have ever gotten off the ground.
*************************************************************
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
*************************************************************
1
Page 8
*********
* * Forty-two
* *
* * by Mike Patrick
* *
* * PATRICK@YALEVM
*********
"I'm goin' down, down, down, down."
- Bruce Springsteen
Hello boys and girls. Welcome to my neighborhood. Today we
are going to learn all about "links". Can you say "links"? I
knew you could!
A link, as defined by the dictionary, is "anything connecting a
single part of a series or chain". Therefore, those meaty,
cylindrical wads of pig flesh you eat for breakfast are
"sausage links". Those cloudy pictures of Bigfoot and the
abominable snowmen for which Leonard Nimoy is always searching
are called "missing links". The things that connect Relays
from all over the world are called "Relay links". These are
the focus of our lesson today.
To illustrate the operation of BITNET "links", let's talk to
our friend Mr. Mudface. You remember Mr. Mudface, don't you,
boys and girls?
TELL RELAY Hello Mr. Mudface! How are you today?
FROM YALEVM(RELAY):
|