|
|
|
|
|
|
|
|
NetMonth, September 1988
******** **************************************************
* * *
* * The independent guide to BITNET *
* * *
* * September, 1988 *
* * *
* * Volume 3, Number 3 *
******** * *
* *
*** * *
* * * * *
* * * * ******* *
* * * * ********* *
* ** * ** ** *
* ** *
* * ******* ********* *
* * ****** ********* *
****** * ** ** *
* * ********* ** *
* * ********* ******* *
* ** *
******** * ******* ** ** *
* * ********* ********* *
* * ** ** ******* *
* * ** *
* * ******* ********* *
* * ****** ********* *
******** * ** ** *
* ********* ** *
*** * ********* ******* *
* * * ** *
* * * ******* ** ** *
* * * ********* ********* *
*** * ** ** ******* *
* ** *
****** * ******* ********* *
* * ****** ********* *
* * ** ** *
* * ********* ** *
**** * ********* ******* *
* ** *
* * ******* ** ** *
* * ********* ********* *
****** * ** ** ******* *
* * ** *
* * ******* ********* *
* ****** ********* *
******** * ** ** *
* * ********* ** *
* * ********* ******* *
* * ** *
**** **************************************************
1
* * * * *
** * * ** ** * * *
* * * *** ***** * * * * *** **** ***** ****
* * * * * * * * * * * * * * * *
* * * ***** * * * * * * * * * *
* ** * * * * * * * * * * *
* * **** * * * *** * * * * *
****** ******
Christopher Condon Editor CONDON @ YALEVM
Timothy Stephen Associate Editor STEPHEN @ RPICICGE
Craig White Associate Editor CWHITE @ UA1VM
June Genis Contributing Editor GA.JRG @ STANFORD
David Hibler Contributing Editor ENGL0333 @ UNLVM
Henry Mensch Contributing Editor HENRY @ MITVMA
Deba Patnaik Contributing Editor DEBA @ UMDC
Gerry Santoro Contributing Editor GMS @ PSUVM
Marc Shannon Helpdesk Editor HELPDESK @ DRYCAS
Glen Overby Technical Assistant NU070156 @ NDSUVM1
Gary Moss Point of View MOSS @ YALEVM
********************* Contents - Issue 25 *********************
EDITORIAL PAGE_________________________________________________
Bitnotes .................................................... 1
Flames To: .................................................. 3
An EARN-Poland Link ......................................... 5
FEATURES_______________________________________________________
The White Pages for Albany .................................. 8
Using IDSERVER .............................................. 9
Exchanging Mail Among Usenet, BITNET, and FidoNet .......... 11
DEPARTMENTS____________________________________________________
Headlines .................................................. 17
Feedback ................................................... 20
Policies ................................................... 24
* 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: 3221 >--------------------
1
Page 1
*********
* * Bitnotes
* *
* * by Christopher Condon
* *
* * Yale University
* *
* * CONDON@YALEVM
*********
"We learn by doing."
I hid her notebook. In retrospect I suppose it was a silly
thing to do, but we learned a lot from it. She was a bright,
intelligent Co-op student who made my grade point average look
like burned waffles. I was the Co-op student she was
replacing. As such, I was given the task of passing knowledge
to a person obviously more intelligent than me. Worse, she was
a snappy dresser.
She had a little stenography notebook that she carried around
during her training period, and she would write down almost
everything I said and did. When it came time to perform a
particular task, she would flip to the appropriate page in the
notebook and follow the instructions therein. When she ran
into trouble she would call me over to help her. She would
then add whatever I did to her instructions.
I began to wonder whether she was really learning anything at
all. The whole idea of working as a Co-op was to gain a kind
of knowledge and experience that one can't get from reading a
book or taking a test. This was a reasonable facsimile of the
real world of computers, with all of its delights and dangers.
Somehow this Co-op was taking this experience and reducing it
back to the textbook (in this case, notebook) level.
So I hid the notebook and asked her to perform some task. She
of course protested that she couldn't do it without a reference
of some kind. I suggested that there was a real rush on this
particular item, and that she had better hurry.
It took her a little longer to reach her goal, but when she was
done she had a better understanding of the software we were
using. It wasn't a matter of pressing F1, typing "A", pressing
Control-Q and so on. If the commands were changed or the
software was different, she now knew that she had the mental
tools to *figure it out*.
1
Page 2
This is true every time a new user begins using the network to
communicate. The concepts of electronic mail, messages,
mailing lists, and forums become real tools and challenges, not
words and pictures in a book. When a student passes from the
world of education to the world of business, they will
inevitably be faced with other networks and other software.
After BITNET, however, many of these people will have the
ability to use these tools and use them effectively.
The benefits of exposure to BITNET vary from user to user and
from discipline to discipline. The key to maximizing these
benefits is education and training. Handing someone a userid
and a copy of BITNET USERHELP is a nice idea, but it hardly
matches the payback of sitting people at terminals and saying,
"Do it." Watch them receive mail and send messages to each
other. The concepts come to life before their eyes. Suddenly,
the network isn't a burden, but a tool to be used. It can even
be fun.
When they understand this, give them real examples of how they
can get the most out of the network. If you are training a
psychology class, give them information on the Psychnet
magazine and server. If you are teaching Communications
majors, show them COMSERVE and CRTNET. Then let them explore
and find other services and topics to thrill and amaze them.
The value of BITNET isn't just in the information and services
that these students receive today. It is in the understanding
and abilities they will take with them when they are no longer
part of this network.
Virtually,
Chris Condon@YALEVM
1
Page 3
*********
* * Flames To:
* *
* * by Craig White
* *
* * University of Alabama
* *
* * CWHITE@UA1VM
*********
Hello everyone,
I have been hopelessly behind this month. I hope your month was
slower. Around here it's time for the students to return for
the fall semester and things are really hopping. I have gotten
a ton of mail this month and at one point I just deleted the
whole lot and got a fresh start with an empty in-box. From my
perspective, the network seemed to be down more than it was up
this month. I would go for days without receiving a single
piece of mail, and then very suddenly many files would arrive
all at once. I really think that this is a serious problem
with BITNET but that's a flame for another day.
This month's flame is about the sending of large files over
BITNET. I understand that under some circumstances sending a
large file is unavoidable. A reason that comes to mind is when
the information is needed quickly and there's not enough time
for a tape, granted that the time variable is very subjective.
From my experience, those who attempt to send or receive a
large file, are generally new to BITNET. Usually they know
nothing about networking and the concept of a limit on the size
of your files comes as a shock.
At least twice in the past month I have had people who were new
to networking either trying to send large files or waiting on
files to arrive that were way over the 300K limit. The ones
who were trying to send the files were the easiest to deal with
because they were local. The ones that were on the receiving
end of a large file were more difficult to deal with. It was
obvious to me that the files had been put on hold or even
purged at some point along the way.
I've found that nine times out of ten when I start hearing
things like "What is taking my file so long to get here?" or,
"Do you think my file got lost?", it's time to ask about the
size of the file. Most of the time, the file is in fact over
the limit and I go into a standard BITSEND/BITRCV talk with the
user.
1
Page 4
Now for the flame, when a file is put on hold or purged because
of size problems, both the SENDER and the RECIPIENT should be
notified of this fact and, in addition, both should be informed
as to where they can get BITSEND/BITRECV. Some people may
argue that only the sender should be notified or only the
recipient. My reasoning for both is that most files are not
unsolicited, both parties have probably discussed the file in
question and reached a decision that the recipient needs the
file. Because of this, they both should have a good idea of
the size of the file. If this is the case, and the file gets
sent anyway, then both people should be told the fate of the
file.
Winding down, I think that the sending of large files is done
mainly by uninformed users of the network, and purging or
putting the file on hold without any notification of this fact
is cruel. If it was the US Postal Service it would be
criminal. At the very least notification should be sent to one
of the parties. Optimally, the file sending program would
check the size of the file and BITSEND it if necessary , but
that is just too much to expect right now.
Finally, LDBASE.COM for VAX sites is now available. It is in
the tools filelist at a LISTSERV near you. To obtain a copy
you could use the LISTSERV command GET LDBASE COM TOOLS
FILELIST. I understand that it is written in FORTRAN and comes
with everything you need to get it up and running. As always,
questions, comments and flames to CWHITE@UA1VM.
1
Page 5
*********
* * An EARN-Poland Link
* *
* * by Dave Phillips, et al.
* *
* * State University of New York at Buffalo
* *
* * V184GAVW@UBVMSA
*********
A May, 1988 NetMonth article proposing an academic computer
link to the USSR spawned a series of discussions, a couple of
which surfaced in subsequent issues of this publication.
Since June a discussion group has formed, comprised of Polish
graduate students studying in the West, Western scientists who
have worked in Poland and/or who have Polish colleagues, and
others on the network who are familiar with the potential
scientific and cultural benefits offered by a link between EARN
and Polish universities. The private list is small but
growing, and extends from Vancouver to Lund, Sweden.
This group has as its purpose to identify the problems involved
in establishing such a link, and to elaborate the benefits, and
to place a developed proposal before EARN and some of the more
autonomous institutions in Poland.
From John Duchowski, 4th year PhD student, Carnegie Mellon
University, originally from Warsaw:
"Being a chemist, I fully appreciate the need for rapid access
to information. The advent of Chemical Abstracts On-Line has
greatly simplified and improved the usual literature searching
methods. However, personal communications between scientists
in the West and the East still have to rely on sometimes
lengthy standard mailing procedures. At present, we in 'the
West' have only a limited access to 'Eastern' publications and
vice versa. Providing an EARN link could be set up, both of
these problems would be alleviated.
"Historically, since the end of World War II, people on both
sides of the 'iron curtain' have also been drifting apart
culturally. Open discussions on subjects other than science
are few and far between. Access to electronic discussions,
such as RELAY, would also lead to a greater and presumably more
open minded exchange of cultural viewpoints. Idealistic as all
this sounds, and where the initial discussions on subjects such
as history may be heated, with time the differences on certain
issues may become of purely academic interest. This would of
course lead to the decrease in tension between the two sides.
1
Page 6
"Finally, from a purely social point of view, the benefits of
open communication are particularly easy to see. Although this
may be looked upon as a glorified 'pen pal' aspect of the
Electronic Mail, the free exchange of ideas and opinions
between private citizens on both sides should not be
underestimated.
"The above comments apply equally well to any Eastern European
country. Nothing has been said thus far about why the first
candidate for a BITNET connection should be Poland. Being of
Polish origin, I may indeed be accused of some kind of a bias
in that direction. From a historical perspective however,
Poland has always been a very western-oriented country. Even
as a member of Soviet bloc Poland probably enjoys the least
controlled society, vis a vis Bulgaria or even Hungary, albeit
at the expense of a ruined economy. Therefore, an EARN link to
Poland would probably be under a lesser degree of government
control as compared to other Soviet bloc countries.
"We also have to consider the drawbacks on equal footing with
the benefits. The most obvious is the sad state of Polish
economy. To maintain a good quality telephone line in Poland
is far from cheap and frequent breakdowns should be taken into
account. Moreover, the cost of EARN membership, yet another
drain of badly needed Western currency, may not be seen as one
of the first priorities by the Polish government. Also, the
existence (or lack of it) of a sufficiently up-to-date
technical base, such as mainframe computers, may limit the
number of candidate sites. Another question that needs to be
asked is how is the access to the EARN-linked computer going to
be controlled. Even minimal (by East Bloc standards)
government control might invalidate the benefits mentioned
above."
From Andrew Duchowski, Simon Fraser University:
"I just learned recently from a friend of mine here in
Vancouver of another example of potential for scientific
exchange. Biochemistry at several educational institutions in
Poland is at a fairly close level to some research institutions
here in Canada. Specifically, protein purification research is
one such example. With an EARN link, this research may be
assisted by the use of information exchange between the East
and West. "
From David Phillips, SUNY at Buffalo:
"The benefits to the world outside the Soviet bloc would
outweigh any real or imagined risks incurred in establishing
such a link, particularly if that link is connecting a
relatively independent society like Poland's.
1
Page 7
"Although Poles suffer official censorship, a pervasive secret
police and laws similar to those in the USSR, there are
thousands of underground publications, a legal independent
Church, private agriculture, and the East bloc's first and only
independent trade union federation, NSZZ Solidarnosc, which is
an affiliate of both the International Confederation of Free
Trade Unions and the World Confederation of Labor. There is
literally a world of difference between Poland - even in its
present state of collapse - and Soviet society at the peak of
its "glasnost." This difference has been maintained at great
cost by the Poles since 1944.
"There is also a thriving independent student movement in
Poland, and thus there is a strong possibility (though no
guarantee) of making an EARN-Poland link, should it ever come
about, a genuine link - not a vacuum cleaner attachment for a
Bloc information gathering apparatus rationed to trusted
apparatchiks.
"The problems are at four levels: 1) Faculty, students and
administrators at the more autonomous universities and
polytechnics in Poland have to be made aware of the potential
for a link and of our support for such a venture; they will
request it once it appears possible, of this (viz. the students
at least) we're certain. 2) EARN must decide in principle that
such a link, if requested, is OK; this involves in part EARN's
members' relationship with the US government, which leads to
3) the assessment by the US government of the relative merits
versus risks in acquiescing to a positive decision by EARN.
Finally, there are 4) the technical problems of a first link
itself, involving site selection, phone line, money and
institutional commitment.
"The perception of the US government would seem to hinge on
concerns of technology leakage and perhaps potential sabotage.
How much such a link would expose genuine US security interests
is hard to say, but there would seem to be a large and ongoing
exposure in the territory of the USA itself (from East Bloc
diplomatic personnel, intelligence gatherers, communications
monitoring, illicit export of hardware).
"Finally, we cannot guess in advance whether the regime in
Warsaw will accept requests from schools for a link; this would
depend in part on their perception of the international
climate."
John Duchowski - Pittsburgh (jd3a+%andrew.cmu.edu@CMCCVB)
Andrew Duchowski - Vancouver (USERQP4C@SFU)
David Phillips - Buffalo (V184GAVW@UBVMSA)
1
Page 8
*********
* * The White Pages for Albany
* *
* * by Deba Patnaik
* *
* * University of Maryland
* *
* * DEBA@UMDC
*********
WHOIS@ALBNYVM1 is an online white pages for the University at
Albany. It accepts commands by both interactive message and
electronic mail. If you send a command by mail it should be
places on the Subject line or on the first line of the message
area.
Your command, as such, is the last name of the person for whom
you you are looking. For example, to look for people with the
last name of "Jones" you would send the command JONES. The
response would look much like this:
Name: Jones, Arthur; Phone: (518)442-1234;
Office: Service Bldg A 904B; E-mail: none
Name: Jones, Heidi; Phone: (518)442-1001;
Office: Social Sciences 290; E-mail: HUGGA@ALBNY1VX
If you are unsure of a spelling, wildcards are allowed, as long
as they are preceded by two characters. For example, a search
for S* is invalid, but a search for SM* would work:
Name: Smirensky, Hubert; Phone: (518)442-7717;
Office: Library A23A; E-mail: none
Name: Smith, Wayne; Phone: (518)442-5290;
Office: Service Bldg A; E-mail: WAYNE@ALBNYVM1
If the server can not find a match for your search, it will
respond with names that sound much like it. In this example I
was searching for the name TOMAS:
Name not found. Possibly similar name(s) are:
Name: Thomas, Andrew; Phone: (518)442-1623;
Office: Earth Sciences 132F; E-mail: none
Name: Tomaski, Herb; Phone: (518)442-1158;
Office: Computing Svcs 05; E-mail: HERB@ALBNY1VX
1
Page 9
*********
* * Using IDSERVER
* *
* * by Gerry Santoro and Chris Sacksteder
* *
* * Pennsylvania State University
* *
* * GMS@PSUVM and CJS@PSUVM
*********
IDSERVER@PSUVM is a service machine that looks up the name and
userid of persons with accounts on node PSUVM. You send it a
message containing either a name or userid. It's main purpose
is to provide PSUVM userids to BITNET users.
If a person is not found that does not necessarily mean they
are not at Penn State or are not joined to a system operated by
another department and accessible via e-mail. Student accouts
expire at the end of every semester and are given only to
students taking course requiring mainframe use. Also, not all
faculty and staff have accounts on PSUVM.
USING IDSERVER:
IDSERVER accepts interactive messages only. Mail is not
accepted at this time. For example, on an IBM VM/CMS system
connected to BITNET, a command to send a message to IDSERVER
would be of the form:
TELL IDSERVER AT PSUVM
|