|
|
|
|
|
|
|
|
NetMonth, May 1988
******** **************************************************
* * *
* * The independent guide to BITNET *
* * *
* * May, 1988 *
* * *
* * Volume 2, Number 11 *
******** * *
* *
*** * *
* * * * *
* * * * *
* * * * *
* ** * *
* *
* * *
* * * *
****** * * *
* * * *
* * ***** *
* ********** *
******** * ************* *
* * *** ****** ******* *
* * ****** ******** ***** *
* * *** ** ******* *********** *** *
* * * *************************** *
* * ***************************** *
******** * ****************************** *
* ***************************** *
*** * **************************** *
* * * ******* ********* **** *
* * * **** *** *
* * * *** ** *
*** * *** ** *
* ** *** *
****** **** ** *
* ******* *************** *******
* ***************************** ****************
* ****************************************************
**** ****************************************************
****************************************************
* ****************************************************
* ****************************************************
****** ****************************************************
* ****************************************************
* ****************************************************
****************************************************
******** ****************************************************
* ****************************************************
* ****************************************************
* ****************************************************
**** **************************************************
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 21 ********************
EDITORIAL PAGE_________________________________________________
Bitnotes .................................................... 1
The Human Factor ............................................ 2
Flames To: .................................................. 6
Let's bring BITNET to the Soviet Union ...................... 8
HANET, Confusion, and Electronic Mail ...................... 10
FEATURES_______________________________________________________
Listserv 1.5n .............................................. 11
TRICKLE and the SIMTEL20 Archives .......................... 14
PCSERVER and the SIMTEL20 Archives ......................... 15
The USENET / UUCP Network .................................. 16
DEPARTMENTS____________________________________________________
Headlines .................................................. 18
Helpdesk ................................................... 19
New Mailing Lists .......................................... 20
Feedback ................................................... 25
Policies ................................................... 26
* 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: 2538 >--------------------
A publication of the BITNET Services Library
1
Page 1
*********
* * Bitnotes
* *
* * by Christopher Condon
* *
* * CONDON@YALEVM
*********
"Go ask your mother."
I carry with me a certain sentimentality about BITNET. This is
largely because I have ventured forth (clean-shaven and
yuppified) into the world of the Fortune 100 and learned
something: There is no experience out there quite like being a
part of the BITNET community.
Oh, I can impress people and figure out ways to send PROFS mail
to friends at other divisions of The Corporation. Otherwise
all of my correspondence is related to business: program
problems, system specifications, requests for assistance, and
so on. All of it very fast, extremely useful, and exceedingly
dull.
Of course we all know that there are very lively computer
networks that you can access when one is part of the Business
World. You can join mailing lists on any variety of business,
research, or entertainment topics. What these conversations
lack, however, is that one topic which consumes so much of our
thought, time, and energy. It is a topic unique our network,
one to which on one else can lay a claim.
The topic is BITNET itself. I doubt that the people in other
networks have ever devoted so much correspondence to talking
about themselves as we. Look, I am doing it right now, and you
are reading it. People who read about BITNET reading about
people who read about BITNET.
Part of this, I believe, is our "frontier mentality". Compared
to other networks BITNET is young and disorganized. I have
always felt that by actively participating in the affairs of
the network that I was part of some great, grand experiment.
We have been on the frontier of educational networking, so to
speak.
BITNET is like our child. We nurtured it's growth, watched it
mature, suffered it's agonies, and shared it's joys. We have
left imprints of ourselves on its "personality" and the way in
1
Page 2
which people view it. At this stage we might call it a
teenager; showing hints of independence, only now coming into
it's own.
It feels good to have been... to still be a part of that. Just
by being here we all become part of the miniature legacy of the
Lifetime of BITNET. We are the proud parents of our own little
history, a network that has grown larger and gone farther than
we would have ever imagined. There is no other experience
quite like that.
Virtually,
Chris Condon@YALEVM
*********
* * The Human Factor
* *
* * by T. D. Stephen
* *
* * STEPHEN@RPICICGE
*********
Comserve, like other file servers operating on BITNET, is a
bonehead. It never tires, never complains, responds to anything
that's sent to it, and never thinks for itself. Naturally, it
is "aware" of certain things. For example, if mail arrives that
contains either "Mailer" or "Listserv" anywhere in the return
address, Comserve won't respond -- doing so might create an
endless exchange of error messages. Avoiding such "message
wars" is very important, so in the interest of keeping Comserve
out of trouble, it has been programmed to obey several rules
about when not to respond to messages. In the final analysis,
though, Comserve and all of the other automated communication
systems on the net (e.g., Listserv, Mailer, Netserv, Csnews,
Nicserve, etc.) display only a tiny level of intelligence --
they are all boneheads.
As communication systems, a principal difference between the
boneheads and ourselves is in the way we process messages. The
boneheads are literalists -- they never distort the messages
they receive; they react to exactly what was sent. Human
beings, by contrast, are richly interpretive, assigning meaning
to a message only if we choose to perceive it in the first
place and only then after its full range of connotative nuances
has been analyzed, after the message has been considered within
the context of other messages we've processed (especially other
1
Page 3
messages received from the sender in question), and after
pondering any relational implications the message might convey
(for example, does it imply that we are subordinate to the
sender or superior? -- and how do we feel about this?). Apart
from any formal procedures cooked up by psychologists, on a
day-to-day basis, we often judge intelligence by the receiver's
apparent level of sophistication in processing messages.
Perception is a cornerstone in human message processing and
I've long been fascinated by research on how the human sensory
system handles information. Psychophysicists have constructed
an ingenious variety of illustrations for some of the rules
that govern how we interpret sensory data. For example, the
rule of proximity says that we tend to see things as "belonging
together" that are themselves closer together. In the
illustration below, for example, A is generally experienced as
a series of columns while B tends to be experienced as a series
of rows. Of course, boneheaded computer programs do not
"experience" the world at all and would treat A and B as
equivalent square matrices.
o o o o o o o o o o
o o o o o
o o o o o o o o o o
o o o o o
o o o o o o o o o o B
A o o o o o
o o o o o
Perception researchers also talk about the role of "schemas" in
our ability to recognize patterns and to reproduce them from
memory later on.* The idea of the schema is that it is a
"master form" that helps us to retain and reproduce detailed
information through reference to something familiar. This idea
is illustrated below. The dot pattern in A may be more
difficult to remember or reproduce than when it is turned
upside down, as in B, and seen to resemble the Big Dipper
constellation.
(figures on next page)
1
Page 4
_________________________________
] ]
] ]
] o ]
] o ]
] ]
] o ]
A ] ]
] o ]
] ]
] o ]
] o ]
]_________________________________]
_________________________________
] ]
] ]
] o ]
] o ]
] ]
B ] o ]
] ]
] o ]
] ]
] o ]
] o ]
]_________________________________]
Perceptual schemas of the type illustrated in this example are
iconic, retaining detailed information through reference to a
visual image of an actual object. Human recognition and recall
of written text is non-iconic and is facilitated through
familiarity derived from past experience. For example, our
facility in recognizing and reproducing a user's address in the
"From:" line of a mail message depends upon past experience
with the string of letters and numbers. Obviously, userids or
node names that consist of arbitrary collections are much more
likely to be misread or miscopied by respondents and therefore
more likely to contribute to a needless profusion of error
message files and redundantly transmitted messages.
As a case in point, we've found it desirable to provide a
method of human contact for Comserve's users. Thus, we maintain
a separate address to which users can write and get answers to
questions about the service. During our first year of
operation, that address was Comsprt1@Rpicicge and, though we
didn't keep records, I would guess that about one out of every
20 mail files ended up in our system's dead letter office. The
most common reason was that the sender had misperceived the
1
Page 5
numeral "1" as the letter "l" or, less frequently, the letter
"o" as the numeral "0". Reasoning that the problem was that
users did not find "Comsprt1" familiar or sensible --
perceiving it to be an arbitrary collection of characters -- we
changed our address to Support@Rpicicge. I would estimate that,
in result, our rate of misaddressed correspondence has
decreased to 1 in 200 letters.
There seems to be quite a bit of variation among BITNET sites
in their awareness of this principle, or at least in the
importance that they attribute to it. While some sites
construct userids from the user's name, others appear to prefer
arbitrary strings. Node CALSTATE, for example, often issues
userids of this type: PXXXXXX1 or JQQQQQ2 (quickly, without
counting, how many X's and Q's are in those IDs?). A lot of
other sites like to issue more random userids (e.g., B1L46896
or V90K113C). It would also seem to be the case that students
are issued the difficult IDs more frequently than staff or
faculty. The bonehead service machines, of course, couldn't
care less about the organization of the information in these
userids. But the fact is that humans will have greater
difficulty with them and misaddress their correspondence more
frequently when they are sending to users with addresses of
this form.
I'm not sure why sites issue such difficult userids to their
clientele, but I would guess that there are probably two
contributing reasons: (a) that staff find it more convenient to
do so and (b) that difficult userids are considered more
secure. Neither of these reasons is sufficiently compelling to
warrant the inconvenience this practice generates. With regard
to keeping it easy for the staff, I would guess that it is
virtually as easy to make a userid generating program produce
recognizable userids as it is to make one that produces
unrecognizable ones. As for the security issue, if it's true
that students are more frequently issued arbitrary userids,
then this is not an issue worth taking seriously; surely no one
would assume that students have a greater need to have their
accounts protected than faculty or staff.
As the networks proliferate and their services attract users,
the campus computer center will be seen increasingly as a
provider of communication services. This is a new role and
brings with it a need for new sensitivities, sensitivities to
the ways that people rather than machines communicate. I think
that BITNET can be made easier for people by increasing
awareness of some of the basic differences that exist in the
ways that computers and humans process messages, and by making
it a cardinal rule that network addresses and computer software
1
Page 6
systems be designed to be responsive to human biases in message
processing. Principles of perceptual organization and memory
can be of value in thinking about how to make BITNET a more
humane environment and, from a technical perspective, a more
efficient and more smoothly operating network.
*My source for this discussion is: J. E. Hochberg (1978).
Perception (2nd ed). Prentice-Hall.
*********
* * Flames To:
* *
* * by Craig White
* *
* * CWHITE@UA1VM
*********
This has been a very busy month for me. The semester ended
with all of the assorted last minute problems; a new level of
the operating system being installed and faculty frantically
trying to get work done before the next semester starts. And
of course there's all the mail. I tried unsubscribing to a
couple of lists and using LDBASE to keep up with the major
topics. Boy was I in for a surprise: LDBASE cannot search a
notebook if you are not currently on that list. Oh well, maybe
things will change at some point.
This month's flame has to do with the "You are your brother's
keeper" phrase. At least twice this month I did not receive
any mail for over three days. At least three times I did not
receive any mail for at least two days. A normal day will see
many mail files making their way to my incoming box. Normally,
I do not use network commands to find out about the status of
links on the network. I can usually tell when links are down
because of the reduced flow of mail traffic. This month,
however, after two and a half days of the second three day dry
spell, my curiosity got the best of me and I sent some commands
to find out how my side of the downed node looked. When I
looked there were over a thousand files queued up to pass
through this node.
I do not profess to be a system guru or anything like that but
it seems to me that when your link is down you would be working
hard on getting it back up. If this were to happen at this
site, I am certain that we would work quickly to remedy the
situation if for no other reason than to give the network
holding space a break, as disk space is at a premium here.
1
Page 7
There is a node near us that seems to go down periodically.
Either there aren't very many BITNET users there, or they don't
care about people down link from them. What I would like to
propose in this Flames To: is that we each become responsible
to our fellow networker. What I mean is, that if a node
adjacent to yours happens to go down, you should contact your
BITNET technical representative and have them get in contact
with the representative at the downed node. This way, even if
the lead systems programmer who knows all at the downed sight
is away for one reason or other, maybe your technical
representative can offer suggestions to the operations staff
regarding what could be done to get the network reconnected.
I realize that a lot of people might be upset at me for
suggesting that operators use the advice given by someone who
has no idea what the local situation is. I think that in
today's environment (global communications) this is not such a
bad thing. Furthermore, I will go as far as to say that the
systems people at adjacent nodes should periodically contact
each other just to shoot the breeze for a few minutes and not
just when problems occur. I know of sites who have called over
to their next link to inquire about when the link would be
reestablished and the systems people didn't even know the link
was down. Granted this might be some kind of internal problem
that the operations staff didn't see the problem and initiate
the proper recover action, but the net (pardon the pun) result
was that many nodes where effectively disconnected from the
rest of the world.
Winding down, I have just been notified that some links just
came back up by the 25 or so files that just popped up here.
The Flames to me this month is for my tardiness in getting last
month's Flames To: to the publisher. I'm sorry to all of you
who had to endure the errors that I didn't have a chance to
correct. Provided the links are up, this one should make it
okay. As always, questions, comments and flames should be sent
to CWHITE@UA1VM.
************
*************** ***
******** ************
**
********* ***********
***************** *******************
************************* *************************** ***
*************************************************************
***************************************************************
1
Page 8
*********
* * Let's Bring BITNET to the Soviet Union
* *
* * by Jason Ohler
* *
* * JFJBO@ALASKA
*********
Distance communication can be roughly defined as communication
in which the sender is in one place and the receiver is in
another, separated temporally, spatially or both. The gap in
time and space is bridged by technology which we use to project
three of our senses: sight (through data, graphics, video),
sound (through audio), and touch in a limited sense (through
the mail system).
Yet, touch was the first sense to be projected at a distance in
an organized, state-supported sense not through the mail system
but via ballistics. Ballistics is a crude form of touching,
essentially the extension of a coiled fist sent raging through
the air. It is a medium which has only one message: I hate
you. Ballistics is different than the bow and arrow and the
spear in that enough distance is introduced between sender and
receiver that both parties become faceless entities.
Unfortunately it has been the only real distance communication
medium between some parts of the world, particularly the east
and west as represented by the Soviet Union and the United
States. Until recently.
The real problem with a ballistics communication system, in
addition to its obvious destructive tendencies, is its
inability to carry detail. For decades the US and USSR, and
their allies, have been living the life of the morality play,
where good and evil come to blows in a world of black and
white, against a background of pure ignorance.
Communications technology counteracts such ignorance. With the
addition of mail, audio, and video, embedded in the context of
glasnost, citizens of the US and USSR have the potential of
experiencing new, more detailed and varied kinds of
communication. Nameless entities become authors via electronic
mail memos, conversationalists via phone and television.
Enemies get fleshed out, take form, and become human enough to
invite curiosity, cooperation, as well as disagreement;
anything but enmity.
Fortunately with BITNET we are in the position of being able to
do more than just talk about changing the world. I have
1
Page 9
experienced the power of BITNET at work. I have helped
teachers establish networks with students half way around the
world. This Journal has helped many facilitate the sharing of
ideas and resources in the field of distance education and
communication that would otherwise be too impractical due to
geographic limitations, time differences, and financial
constraints. The routine business that I, and thousands of
others, now conduct with colleagues in countries all over the
world via BITNET is recreating us in the image of the global
citizen. In short, it has become obvious to me that
international networking, whether among university colleagues
or seventh grade science students, politicians or business
people, is our best offense to counteract ballistics.
LET'S BRING BITNET TO THE SOVIET UNION. It will be a struggle
to bridge language barriers and to work through the hardware
problems, but it is certainly doable. The last issue of the
Journal contained an article by a university professor in the
United States who has established an electronic mail
relationship with colleagues in the USSR. The Office of
Automated Systems in Moscow has leased lines into Scandanavia,
an area that is very active in the BITNET, EARN, Netnorth
network.
LET'S BRING BITNET TO THE SOVIET UNION. And let's make it as
easy as possible. Let's send someone to the USSR to help them
with the paperwork, the logistics, the hardware. And let's
invite the Soviets to our facilities as well.
LET'S BRING BITNET TO THE SOVIET UNION. But let's not be
naive. To allow BITNET to become the same kind of force that
it has become in the west is asking a lot from a government
that has presided over an information constrained culture for
half a century. But the Soviet Union is changing. The worst
that could happen is that they would say "no thank you."
LET'S BRING BITNET TO THE SOVIET UNION. More than likely, we
will make history.
************
*************** ***
******** ************
**
********* ***********
***************** *******************
************************* *************************** ***
***************************************************************
1
Page 10
*********
* * JANET, Confusion, and Electronic Mail
* *
* * by Ake Olofsson
* *
* * AAKE@SEUMDC51
*********
Occasionally people have problems in getting through with
electronic mail to addresses in the British JANET. (Questions
in the January, 1988 NetMonth and in PSYCHNET Vol2No38.
Descriptions of JANET and its gateways can be found in the
JANET files at NETSERV or NICSERVE and in the NetMonth issue
mentioned above.) In the last year, I have helped several
people in Sweden having trouble in sending to JANET. In most
cases the solution and explanation goes as follows:
One of the peculiar things with JANET is that addresses are
stated "the other way around" from what is the standard in
BITNET (and most other networks). Thus, a British user can have
the local electronic mail address
MAGGIE@OXFORD.VAX
When this fictitious user wants to give her electronic mail
address to a colleague abroad, she asks her system manager for
her complete address. The manager may give her two pieces of
information:
BITNET/EARN users must use a complete address, i.e. specifying
UK. for United Kingdom and AC. for the academic computing
network. This probably sounds OK to Maggie; she may have seen
her address stated somewhere as MAGGIE@UK.AC.OX.VAX
However, BITNET/EARN users also must write THE LAST PART (the
part after the @) of the address in a different order. The
"real" address is MAGGIE@VAX.OXFORD.AC.UK
What often seems to go wrong is that the reversal needed from
least to more specific constituents is carried out only for
part of the string following @. For example Maggie will
erroneously report her address to be Maggie@oxford.vax.ac.uk
instead of MAGGIE@VAX.OXFORD.AC.UK and the BITNET user will
receive a reply with "undelivered mail" when using this
address.
Thus, if you don't get through with electronic mail to UK,
first inspect the address. Is it possible that the parts
1
Page 11
following the @ are in the wrong order? Figure out which is the
most specific one and should be first, which is the next most
specific and should be second, etc. When you get through,
suggest to Maggie that it would be easier to join the world
rather than fight it.
*********
* * Listserv 1.5n
* *
* * by Eric Thomas
* *
* * ERIC@DEARN
*********
Starting with release 1.5n (which is running on 100 servers as
of today, 88/04/26), a "global list registration" facility has
been incorporated into the base LISTSERV code. It causes all
the (1.5n) LISTSERVs to inform the "backbone" servers of all
the non-local lists they have, so that a global "list of lists"
gets generated and automatically maintained. Along with this
facility, "list location awareness" has been provided, so that
you can send a SUBSCRIBE or SIGNOFF request for just any list
to any server (running 1.5n), and it will take the appropriate
steps to forward your request to the proper place. Thus, you
don't need to worry about the node on which the list is
defined.
In addition, a network-wide unique "List-ID" has been
associated with each list, to solve the problems of peers with
different/conflicting names. This "List-ID", which acts as a
(network-wide unique) synonym for the "real" list name, may be
up to 16 characters, and makes it easier to redistribute ARPA
lists on EARN/BITNET. For instance, a list like "INFO-UNIX-
STUFF" could be defined with a listname of I-UNIXST and a List-
ID of INFO-UNIX-STUFF, which would make it possible for users
to "SUBSCRIBE INFO-UNIX-STUFF" without even knowing the actual
list name. You still have to mail to the real address, of
course.
A new command, available from all the "backbone" servers (63 of
them as of today), has been defined:
LIST GLOBAL
This sends you a 1-line description of each known list. You
can specify a search string (as in "LIST GLOBAL /UNIX") to
select only a limited number of entries. This string will be
1
Page 12
searched in the list name, list-ID and list title, with case
being ignored. BE CAREFUL: there are over 920 lists in the
database today, and you'll get a lot of unwanted output if you
do just "LIST GLOBAL".
In addition, more extensive information is kept on some servers
whose maintainers have kindly volunteered to provide adequate
disk space (some 2-3M). This takes the form of a LISTSERV
database called "LISTS", which is presently available on the
following nodes, which are all "peers" as far as database
management is concerned (ie there is no "master" server, and no
server has "more accurate" information than the others, a
priori):
FINHUTC BNANDP11 HEARN TCSVM CEARN MAINE RUTVM1 MARIST
DEARN CANADA01 BYUADMIN LEHIIBM1 UTDALVM1 UMRVMB DBNGMD12
This LISTS database contains information about the same lists
that are in the LIST GLOBAL output, that is, all the lists
hosted by a Revised LISTSERV running version 1.5n or better.
Obviously, ARPA or CSNET-based lists do not appear there,
unless there is a LISTSERV redistribution on EARN/BITNET. For
each list, the complete list header is available and can be
searched using the standard LISTSERV database functions. This
also implies that you no longer need to use the REVIEW command
to get the description of a list.
A request to access the LISTS database will fail with a
"Database LISTS does not exist" message if sent to a pre-1.5n
server. When sent to a 1.5n server which is not on the
backbone, you will be provided with the userid@node of the
backbone server nearest to the one you sent your request to. A
backbone server which doesn't host the database will give you
the address of the nearest backbone server that does have it.
If you are not familiar with the LISTSERV database functions,
you should probably read "LISTDB MEMO" first (it can be
obtained by sending an "INFO DATABASE" command to any LISTSERV
running 1.5m or better). Please note that "INFO LISTDB" won't
work (I know, this was published in last month's article, but
then this article wasn't really from me.)
The characteristics of the database are as follows:
* DATE corresponds to the date the last update was GENERATED by
the remote server hosting the list (remote server's local
time). Its resolution is the day, ie 'yy/mm/dd' is available
but time is '??:??:??'. Note that this date is network-wide
unique for a given list/update pair, ie two servers which have
1
Page 13
received the same update for the same list will bear the same
date field regardless of their GMT offset.
* LIST-ID (also LISTID or ID) corresponds to the network-wide
"List-ID" keyword contents.
* LISTNAME (or NAME) is the actual name of the list (ie VM
userid thereof).
* NODEID (or NODE) is the nodeid of the server hosting the
list.
* TITLE is the list title.
All the keywords defined in the various list headers are also
available, PROVIDED THAT THEY ARE NOT DEFAULTED. That is, you
can do "Select * in LISTS where send=public and owner contains
ERIC@FRECP11", provided that the list header contains an
explicit definition for "Send" and "Owner". If these keywords
do not appear in the list header, the default values (resp
"PUBLIC" and
|