|
|
NetMonth, February 1988
******** **************************************************
* * *
* * The independent guide to BITNET *
* * *
* * February 1988 *
* * *
* * Volume 2, Number 8 *
******** * *
* *
*** * * *
* * * * ** *
* * * * *** *
* * * * **** * *
* ** * * **** ** *
* ** **** *** *
* * *** * **** *** *
* * **** ** **** *** * *
****** * **** *** **** *** ** *
* * **** **** **** **** ** *
* * **** * **** **** **** *** *
* **** ** **** **** **** **** *
******** * **** *** **** **** **** **** *
* * **** **** **** **** **** **** *
* * **** **** **** **** **** **** *
* * **** **** **** **** **** **** *
* * **** **** **** **** **** **** *
* * **** ****** **** **** **** **** *
******** * **** ******* **** **** **** **** *
* **** ******* **** **** **** **** *
*** * **** ***** **** **** **** **** *
* * * ***** **** **** **** **** **** *
* * * **** **** **** **** ***** ***** *
* * * ***** ***** **** ***** ***** ***** *
*** * ****** ****** **** ***** **** ***** *
* ******** ******* **** ***** **** **** *
****** ********** ******** ***** ****** **** **** *
* *********** ******* ******* ***** **** **** *
* *********** ****** ******** **** **** **** *
* ********** ************** **** **** ****** *
**** ********* ************** **** **** ****** *
******** ************** ***** *** ****** *
* ********* ************** ***** **** ********
* ********** *************** ******* **** *******
****** ********** ********************** ****** *******
* ********** ********************* ******* *******
* ******************************** ***************
********************************* ****************
******** ********************************* ****************
* ********************************** ***************
* *********************************** ****************
* *********************************** ****************
**** **************************************************
1
* * * * *
** * * ** ** * * *
* * * *** ***** * * * * *** **** ***** ****
* * * * * * * * * * * * * * * *
* * * ***** * * * * * * * * * *
* ** * * * * * * * * * * *
* * **** * * * *** * * * * *
***** ******
Christopher Condon Editor CONDON @ YALEVM
Mike Patrick Contributing Editor PATRICK @ YALEVM
Glen Overby Technical Assistant NU070156 @ NDSUVM1
Gary Moss Staff Supervisor MOSS @ YALEVM
******************** Contents - Issue 18 ********************
EDITORIAL PAGE_________________________________________________
Bitnotes .................................................... 1
The Human Factor ............................................ 3
The Life in a Day at the BITNIC ............................. 7
Flames To: ................................................. 10
I, Undergraduate ............................................12
FEATURES_______________________________________________________
Accessing ISAAC through BITNET ............................. 14
LifeSci - Coming Soon ...................................... 19
The Space Physics Analysis NetWork ......................... 22
Software Archives at RPICICGE .............................. 23
The On-Line Journal of Distance Education .................. 26
Bioserve - The Bioscience File Server ...................... 27
DEPARTMENTS____________________________________________________
Headlines .................................................. 28
Helpdesk ................................................... 29
New Mailing Lists .......................................... 31
Feedback ................................................... 32
Policies ................................................... 35
* 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: 2048 >--------------------
A publication of the Bitnet Services Library
1
Page 1
*********
* * Bitnotes
* *
* * by Christopher Condon
* *
* * CONDON@YALEVM
*********
"Life is NOT a Cabaret... and stop calling me Chum."
----
I am no fan of cliches, and yet I find myself falling back on
them again and again. This time is no exception. Try as I
might to think of an original, witty way to get my idea across,
I must fall back on something tried and true. The fact that I
feel the idea is important makes matters worse, as I want to
catch your attention, make you think, promote some action.
One doesn't promote action with a cliche, but here it is:
"Happy networking begins at home". It's not particularly
original, but it sets the stage for this month's topic.
This past week we held a meeting of the Yale BITNET Users'
Group (YBUG). Gary Moss (our Inforep) and myself have formed
this organization to find out how we can improve BITNET service
on the local level. The users tell us what they feel we are
doing right, what we are doing wrong, and what we aren't even
doing at all. In turn, we attempt to get their help and
support in making changes.
Now, of all places, you would expect Yale to have its house in
order when when it comes to BITNET. YALEVM is one of the two
original network nodes. It is the home of the Bitnet Services
Library. NetMonth, NetWeek, and the other BSL publications
were born here. This is where the BITLIB online help system
originated. Gary has held numerous informational meetings
promoting BITNET use and explaining how to gain access. He
wrote a users' guide to electronic mail. There are more
pamphlets and flyers than I care to mention.
We have a long way to go. We still lack a BITNET Users' Guide.
We would like to hold "hands-on" Getting Started classes (an
afternoon should do it). Much of the online documentation for
commands such as TELL is plain IBM (meaning you need a
translator to figure out what they are saying). Very often
Gary and I simply take for granted the knowledge level of the
average user. After having used the network for several years,
it becomes easy to assume they know what we mean when we say
"Name Server". "It is hard for the expert to think like a
novice."
1
Page 2
As I said earlier, happy networking begins at home (Gosh, that
sounds awful!). We have to address these weaknesses, because
they hurt the effectiveness of everything that DOES work. All
of the network promoting we do becomes muddled if the users
can't figure out how to access the services we've touted so
vigorously.
It is not for lack of trying. The task at hand is a big one
and we cannot devote our lives to it. Inforep is not Gary's
primary duty. I am here only evenings and assorted weekends.
To coin a cliche, there are only so many hours in the day.
That is where we hope YBUG will become effective. If the
YBUGgers tell us how we are doing, we can learn from that. Our
ultimate goal, however, is to work as networking partners with
them, enlisting their help, knowledge, and insight to improve
services.
How clean is your house (or rather, how good are your
networking services)? Call a local BITNET User's Group
meeting. You may be surprised that things are not as tidy as
you think.
***************************************************************
Last month's Bitnotes column (the "Hows" and "Whys" of BITNET)
generated such a positive response that we have added a new
section to the magazine. Look for the "Applications" section,
beginning with the next issue. If you know of an interesting
use for BITNET, write about it and send it to BITLIB@YALEVM.
This month Mike Patrick's Forty-two column goes on hiatus as we
attempt to get him connected to the network via his Commodore
64 (oh is THIS going to be strange!!!) Many thanks to Murphy
Sewall and William Lott of UCONNVM for their help on this
project.
However, there are plenty of columns and editorials this month
to keep you happy:
"The Human Factor" Another thought-provoking column by Tim
Stephen. This month he writes about BITNETs developing
culture.
"Flames To:" A new regular column by Craig White. Is there
something about BITNET that really irritates you? Tell Craig
about it!
1
Page 3
"The Life in a Day at the BITNIC" Judith Molka takes us
through a day at the Network Information Center. It's not all
fun and games, you know. (Guest Column)
"I, Undergraduate" Tom Limoncelli explains what it is like to
be an undergraduate in BITNET. In his case, he tried to learn
something. (Guest Column)
I hope you enjoy it.
- Chris Condon@YALEVM
*********
* * The Human Factor
* *
* * by T. D. Stephen
* *
* * STEPHEN@RPICICGE
*********
Culture is a very hot concept in several areas of the
social sciences and humanities these days. It's used to help
explain a wide range of human phenomena including corporate
success and failure, the nature of intimate bonds and
family life, problems in communication between the sciences and
humanities -- even the rise and fall of sports teams. When
social scientists talk about culture, they are not talking
about fashion and art; rather, they are referring to
idiosyncratic ways of thinking and communicating that
evolve within different social groups.
To a large degree, culture determines what people take for
granted versus what they see as controversial; thus, in
a way, culture "imprisons" the minds of its members. Members
of one cultural group can be blind to ideas or ways of doing
things that seem patently obvious to outsiders. Conversely,
outsiders may have considerable difficulty understanding
the shared outlook that is the corporate mental property of
cultural members. We recognize that we've crossed a
cultural boundary when we find ourselves feeling unsure about
how to behave, what to say, how to accomplish things, how to
evaluate what's going on around us. Communication -- normally
more or less automatic -- becomes more of a conscious activity,
overlaid, perhaps, by a sense of uncertainty.
There are signs that voices on BITNET's Listserv
discussions are evolving a cultural or sub-cultural
identification. Certainly Listserv authors bandy an
1
Page 4
elaborate set of concepts that probably have little meaning
to outsiders. "Relay," "listserv," "RFC822," "inter-network
gateway," "file class," "mailer," etc. are fairly difficult
ideas to communicate to someone with no experience with
computer communications (this month's challenge: try to
find a common language metaphor to represent the meaning of
"spool your virtual punch to RSCS"). However, the presence
of unique language is not sufficient in itself to
demonstrate the existence of an emergent culture; many
technologies and activities require the use of specialized
language in order to express what is unique about them. To
claim that BITNET is evolving its own culture, we need
evidence that its voices are united to some degree in a unique
outlook, a shared set of assumptions whose validity
is established and sustained solely in inter-member
communication.
I've followed several listserv discussions for some time
including LstSrv-l, Mail-l, UG-l, Rexxlist, Servers,
LinkFail, Bitnews, and a number of others. I've tended to
subscribe to lists that have potential relevance for the
operation and development of Comserve@Rpicicge, our BITNET
information resource for the communication studies
discipline. Though not in any sense a random selection,
these lists (especially LstSrv-l, Mail-l, Bitnews, and UG-l)
carry writing about the network itself and contributions to
these lists often implicitly indicate the writers'
conceptions of BITNET. Based on this, on perusal of the BITNET
organizational documents on Nicserve, and on three
years of corresponding with various site personnel, I think
it is possible to identify some basic propositions and
corollary notions that are often, though not always, implicit
"givens" in network interaction and which therefore have the
potential to serve as critical building blocks in the emerging
structure of BITNET's culture.
Perhaps the most basic of these is apparent in the way that
listserv respondents tend to write about what BITNET is.
It is possible, of course, to see BITNET in many different
ways -- a campus information service, a pedagogical tool, a
forum for discussion, a bridge to other cultures, a news
service, a method for resource sharing, etc. However, I think
that BITNET is written about most often, and without
challenge, as a set of specifications and associated technical
problems. At least the voices on BITNET spend an
inordinate amount of time discussing specifications --
protocols, procedural rules, command syntax and so on. Most of
what's available to users from BITNIC, the conceptual hub of
the network, is also of this form -- hundreds of files
containing specifications, node tables, etc., as compared to
1
Page 5
their tiny collection of files containing orientational
information for users, and the complete absence in their
collection of a single file describing potential
educational applications of BITNET. Now there is nothing
inherently wrong with envisioning BITNET as a set of
specifications and corresponding technical problems and
possibilities. It is no more or less "accurate" a vision
than any other, and its predominance is probably a natural
consequence of the very strong computer science and
engineering presence in the network.
But what of the implications of the widespread adoption of
this particular vision of the network? What are the
consequences of this way of thinking about the network? One
(and one that I feel very strongly ought to be kept in check)
is the possibility that people may come to believe that
making the specifications available is most of what's
needed in terms of orienting new users. The deduction is
that if the network is envisioned as a set of technical
specifications, then those who have access to the
specifications will be able to use the network. Of course it
*is* vital that the specifications are publicly available and
BITNIC does a good job in this regard. But that is
decidedly not enough to make the network comprehensible
to people who are not technically oriented.
A second potentially negative implication of the
"network as specifications" view is that it may tend to
foster and sustain the corollary notion that the most important
problems in BITNET's future are problems of refining
specifications or adopting better ones. When you look at the
future of BITNET in this light it makes good sense that its
central policy making body (the BITNET Executive Committee)
consists, as it does, exclusively of computer science
personnel. But imagine, if only for the sake of contrast,
that the dominant shared vision of BITNET was that it is a
resource for education and research. If you started from
this alternative vision, would it not follow that you would see
it as "given" that the policy making body that allocates
BITNET's resources and decides BITNET's future would include
a representative sample of educators and researchers?
Perhaps under this alternative vision, instead of concluding,
as did the Executive Committee, that resources should be
allocated to demonstrate BITNET at a DEC computer convention,
you might conclude that resources should be allocated to
demonstrate BITNET at the national conventions of the major
academic disciplines -- the American Psychological
Association, the Modern Language Association, the
International Communication Association, etc. -- places where
you could effectively demonstrate its relevance for education
1
Page 6
and research. The shared vision that a group constructs
determines the courses of action and policy that the group is
likely to undertake.
If you listen to the voices of BITNET, you may notice that when
they speak in judgment of the network, the criteria are
almost exclusively technological and quantitative. Of
course, BITNET's success could be assessed in a lot of ways:
in terms of the number of faculty who find its services
relevant to their work, the number of educational
activities that it hosts, the extent to which novices find it
easy to use, and so on. But the voices of BITNET tend to
judge it in terms of link speeds, queue sizes, the degree to
which protocols are adhered to, etc. The adoption of this set
of criteria rather than any other set is a logical extension
of the predominance of the "set of specifications" view of
BITNET.
I wrote last month of the danger that BITNET may come to be
viewed as a private service for campus computing
personnel unless more attention is given to marketing
its relevance within the broader academic community. It
will become increasingly difficult to even conceive of
making such an effort if the evolving culture of BITNET
orients itself ever more strongly around engineering and
computer science concerns and continues to tend toward the
view of BITNET as a set of technical specifications and
associated problems. If this particular cultural "set"
increases its hold, it will leave less and less room for
alternative conceptions and, inevitably, it will begin to have
consequences for the types of activities that are undertaken on
the network. For example, staff at many sites have often
volunteered their efforts in the solution of technical
problems -- inventing mailers, listservs, setting up
gateways and so on. They do so because the emerging
culture of BITNET recognizes and values this sort of technical
effort. But given the current prevalence of the "set of
specifications" view, what are the possibilities that a
site could win widespread recognition for its efforts in
devising novel ways to involve faculty and students in
BITNET?
In thinking about the evolution of the culture of BITNET, I
think that it is important to keep two points in mind: first,
whatever shared vision of BITNET ultimately predominates among
its users, it will be no more natural or "given" than any
other -- such things are idiosyncratic social conventions.
Second, as Richard Weaver put it, "ideas have
consequences," and, thus, the cultural vision that
predominates -- whatever it is -- will profoundly affect the
reception of BITNET within the broader academic community.
1
Page 7
*********
* * The Life in a Day at the BITNIC
* *
* * by Judith A. Molka
* *
* * AKLOM@BITNIC
*********
Click, Click, Click, Click... Its 8:10. Reading the overnight
email before America wakes up. Looking at the reader, eight
new pieces from LSTSRV-L, four from EARNTECH, a few late
nighters from NODMGT-L, LIAISON and POLICY-L. I could read the
BITNIC LISTSERV mail by linking to our LISTSERV disk and
reading the notebooks, but the mail in my reader prompts me to
look at them sooner.
The rejection mail from our 50 private and public LISTSERV
lists has also arrived. I'm glad these are easily discernable
as class N. Some of the rejections are failed attempts on the
Internet. "Can not deliver for 2 days, will try for 1 more
day." These are deleted. Several of the returns are marked "No
such user". If the list is Open, the id is removed. If it is
a Closed subscription list, then someone at the site is
contacted for a substitute address.
Some of the mail is directly for me. Gary Sponseller requests
three more files presently stored on NICSERVE to be also stored
our LISTSERV. I agree, since these files are requested
frequently and updated each month. Steps taken include telling
Elizabeth Kilcoyne to add a filename to her list of files to be
"PUT" on LISTSERV each month and I change the NODEINFO
FILELIST. I keep in mind that it takes Elizabeth more time to
update files on LISTSERV than to renew them on NICSERVE.
Whenever updating a file on LISTSERV, Elizabeth will need to
Xedit the file, add a "PUT" line, file it and send it. (If
there is a better way, let me know.)
Next mail, "My NETSERV password is going to expire but I don't
know what it is so I can't change it." A few months ago,
someone told me I was listed as a NETSERV Coordinator. Well,
that's what the help documentation said. I think the BITNIC
maintains about one file on the NETSERVs but my role allows us
to look up passwords. This time it was "12345678". Last time it
was "ABCDEFGH". These are the two default passwords assigned
by the EARN Master Coordinator about two years ago to all
persons in BITEARN NODES with a role of "Contact". If the
password was not changed, it seems likely it was not used. The
password is basically used by EARN Node Administrators to
access privileged files. (BITNET sites that create their own
1
Page 8
route tables may use it and the BITNIC can issue passwords with
reason.) BITNET Technical Representatives cannot use the
NODEUPD function of NETSERV to change their site data. They
must send changes (preferably in Names format) to
UPDATE@BITNIC.
Next mail message, a request to change a node name. Forward
this to UPDATE. A question, "How do I obtain the archives for
BITNEWS?" Suggest the command "GET BITNEWS LOGyymm" for files
after October 87. Issue a "GET NEWS FILELIST" for archives
before October 87.
The phone rings. Dublin, Ireland calling, "We're not getting
much mail. Know what's wrong?" I message Bill Rubin. "Bill
how do I see what is in the FRMOP22 queue?" Bill replys, "You
don't, its JES2, and there are 6000 to 8000 files queued at
FRMOP22 for CEARN." "Oh.", I reply "Well then how do you know?"
"I asked them", says Bill. "Oh", I relay the message.
Recently we received word from the BITNET Board of Directors to
give class D members the opportunity to reapply as class C
members because under a new "Criteria for BITNET Membership"
(CRITERIA INFO1) the qualifications had changed. The revised
criteria was adopted by the Board at their October 26th
meeting. Revisions were made to file on NICSERVE on 11/18/87.
Elizabeth and I discussed how to proceed. It was decided a
letter would be sent to all BITNET Institutional
Representatives inviting all class D members to reapply and
pointing out the changes in the criteria form. We considered
the letter to the non-class D members to be equally important
because several of these sites sponsor class D sites and
additionally the revised criteria somewhat relaxes the
restriction on class D communications. The important use
modifications are as follows. The documents CRITERIA INFO1 and
APPLY INFO1 are to be enclosed with the letter.
"All transmissions from Class D and E members to
Class D and E members are prohibited except to the
extent they relate to conference or committee
activity sponsored by a Class A, B, or C member.
"By mutual agreement cooperating networks will be
treated as equal partners, with usage rules applied
to individual network members rather than to the
network as a whole (i.e., if a cooperating network
has a Class D member equivalent, usage restrictions
will apply only to that individual Class D member,
not to the network as a whole).
1
Page 9
"A Class C nonprofit organization must satisfy one of
the following: (i) a majority of its Board members
are from higher educational institutions, or (ii)
be a professional society which publishes a
recognized scholarly journal or (iii) be a foundation
which funds University programs. A governmental
agency or laboratory must satisfy either of the
following: (i) be a funding agency which provides
research or training grants to higher education, or
(ii) be a research laboratory performing research
compatible to that performed in University
laboratories."
We drew up modifications for the Application form so it would
match the Criteria form. We added a request for budget data in
the supplement section for applicants not listed in the HEGIS
directory. As a result we hope to need fewer phone calls in
seeking out the necessary information. We gave the specks for
the letter and APPLY INFO1 to our new Technical Writer Patricia
Noeth to put it into proper English. Pat at the same time is
picking up some knowledge of SCRIPT.
The mailing labels would be produced in INGRES on EDUCOM's VAX
machine. We produced reports to compare our BIR names in
INGRES and SPIRES to be certain they were in sync. (Note: The
BITNIC recognizes that SPIRES could produce output for labels.
The individual BIR addresses are maintained in INGRES as part
of our invoicing procedure. The invoicing is done in INGRES
because a program already exists, the accounting department
gets the appropriate reports, no invoice numbers are created
which duplicate EDUCOM invoice numbers.)
Earlier this afternoon I received mail from June Genis about
the Node Management Group and scolding us for not "nurturing
your volunteers". Basically she said, "If you guys are doing
anything to help us, we don't see it from the trenches."
Additionally, my VP of Networking requested that employees
write job descriptions as part of our evaluation process.
Last, Chris Condon keeps asking me for articles. Therefore, I
took note of what happened one January day at the BITNIC (from
my point of view). As Patricia Noeth our new technical writer
obtains a deeper background of BITNET and the activities of the
BITNIC, we hope to provide you with more frequent
correspondences thru BITNEWS, the representative lists, and
Netmonth. Scott Earley, for his part will organize BITNET
Technical Meetings prior to SHARE and DECUS conferences as
another means of input. Finally, this all did happen in one
day, along with phone calls and mail that I did not take note
of. Almost forgot to mention my lunch hour. Picked up an
insurance estimate of damages to my car which was hit while
1
Page 10
parked in front of my home on December 25th. $4500 worth of
damage and won't be fixed till mid-March! Holy Christmas Exec
Batman!
*********
* * Flames To:
* *
* * by Craig White
* *
* * CWHITE@UA1VM
*********
Hello everyone!
Welcome to the first installment of the Flames To: monthly
column. This column will be about such things as network
etiquette, crazy happenings on mailing lists and maybe even
some helpful how-tos.
First order of business: I would like to recommend a very
short book for everyone to read. The name of this book is
Toward an Ethics and Etiquette for Electronic Mail, and most
likely is available from your school library. I believe that
everyone who has access to a computer network should read this
book before they use that network. My definition of a network
is very broad and includes any NET, all Bulletin
Boards Systems, Compuserve etc. A short excerpt from the book
can be found on NICSERVE AT BITNIC under the file name of MAIL
MANNERS.
Copies are available for $4 from The Rand Corporation,
Publications Department, 1700 Main Street, P.O. Box 2138,
Santa Monica, CA 90406-2138. Ask for publication
R-3283-NSF/RC.
More from this book in future issues.
Flame of the month: PLEASE SEND REQUESTS TO BE ADDED/DELETED
FROM LISTSERV MAILING LISTS TO LISTSERV AT INSTEAD
OF TO THE LIST.
This has to be one of the most annoying happenings on mailing
lists. My personal favorites are the users who really get
upset after sending "Please unsubscribe me" mailings and then
start making threats like "I'll send this mail everyday until I
get deleted from this list." In some cases the person who can
delete them might not even be on the list.
1
Page 11
Please be sure when you help someone subscribe to a mailing
list that you also show them how to get off the list. When l
help someone subscribe I always start by sending TELL LISTSERV
AT HELP and then explain the concept of
LISTSERV to the person. By that time the help stuff has
arrived and I show them the commands for both signing onto a
list and for signing off. I will then sign them onto the list
and then sign them off the list. This way they can see the
responses from LISTSERV as it adds them to a list and also the
responses when they are deleted from a list. The reason I
don't just leave them signed on the list is so they have to go
away and actually redo the whole thing again by themselves,
hoping that the practice will help them develop a deeper
understanding of the concept of mailing lists via LISTSERV.
Dealing with mailing lists on networks other than BITNET
requires a slightly different approach which I'll deal with in
another issue.
Disclaimer: It is always a good idea to put a small disclaimer
at the end of each mail message you send out to a mailing list.
This is not such a big deal with personal correspondence but to
a mailing list it is an imperative. I remember my mother
always telling me "Please be on you best behavior because you
are a reflection on me". I think that this also happens with
mail, people look at it and form ideas about your school or
business from what you say. Now I'm sure that some of you
might be thinking "Your going a little bit far to imply that
people would think I somehow represent my school, look at my
USERID." What I'm really saying is don't give anyone the
chance, use a disclaimer. A very simple one at the close of
your mailing to the effect of:
The above was the opinions of an individual and in no way
reflect the views of my school, employer, etc.
And finally, FLAMES TO ME: I am guilty of sending out a
mailing that had as a part of the disclaimer my InterNET
address in the form of @WISCVM.WISC.EDU. My apologies to the
Net. Please remember WISCVM is no longer the way to get to and
from the InterNET. If you have any comments, questions or
flames about this column send them to CWHITE@UA1VM.
* * *
*** * * ** * * *** * *
**** *** * ** *** * ** * **** *** * ** *
************* *** *** ** **** *** ************** *** **
******************** *****************************************
***************************************************************
1
Page 12
*********
* * I, Undergraduate
* *
* * by Tom Limoncelli
* *
* * TLIMONCE@DREW
*********
Can a nymphomaniac be cured? What about an "infomaniac"? In a
book by Elizabeth M. Ferrarini, _Confessions_of_an_ Infomaniac_
(Sybex, 1984) she portrays a woman who finds a computer network
named CompuServe that makes her social life expand beyond
belief.
Are the majority of undergraduates infomaniacs? Do they find
BITNET as a method of expanding their social life, as a form of
recreation, or as a educational tool? Too many see it as a
toy. How much is too many? I don't know. I am an
undergraduate who uses BITNET daily. My major is undeclared
but will undoubtedly be Computer Science. Unlike most techies
though, I do look at BITNET from a social perspective as well
as from a technical standpoint.
Initially I saw it as a way of getting messages to friends at
other colleges easily. When I learned about LISTSERVs it
became a tool. I still send an occasional message to friends,
but the education that I am getting from the bitnet discussions
is immeasurable.
I subscribe to a number of LISTSERV discussions. One concerns
the C programming language. I read a great many posts from it
a day. Do I get credit for reading this? No. Do I plan on
getting credit? No. I do feel that it has added so much to my
knowledge of the C language that my computer science degree is
greatly enhanced. How could I be given credit for this? As
part of a course on C? Independent study? Would that would
then require me to write a report or do some project. This is
like asking a music major to read The Village Voice and write a
report at the end of the semester. The subjects are varied
anyway. I could write about conflicting opinions on points of
the Draft ANSI C Standard, or programming debates, ad nauseam.
It's just not possible. I'm not learning anything I can show
my professor. Without bureaucracy let me learn in this mode on
my own. Don't give me credit. I will tell other friends who
are interested in C to subscribe and because of their own
interest will take the initiative.
The next discussion I subscribe to is AIDSNEWS, a forum
concerned with the latest in research, treatment and politics
1
Page 13
of AIDS. The experts say our best defence against AIDS is
education and though I often feel that I am the only non-bio
major reading that reads AIDSNEWS I pick at the information and
feel more up-to-date then I could by reading any textbook. My
subscription will certainly last longer than one semester.
Again, I get no credit for this but the information that I have
gotten and have been able to share with my friends is more
important than credits. It may save a life.
Lastly I subscribe to i-amiga. This group is a technical
discussion concerned with the Amiga line of computers from
Commodore. Since my University has standardized on IBM PC
compatibles, finding people to discuss Amigas with on campus is
impossible. Through this discussion, I have been able to get
help and get help from other Amiga users. My resources have
expanded from campus-wide to international. An independent
study project that I am planning will be based on the Amiga.
All the theory can certainly be taught by my professor(s) here
but they have little experience with this "non-mainstream"
computer. Luckily, I will be able to draw on BITNET as an
indispensable resource.
Chris Condon suggests that BITNET should be integrated with
curriculum and, not being an educator, can give little
direction except as something for telecommunication courses to
examine. I have showed how I applied my major to BITNET.
Certainly other majors can be applied; there are discussions
out there for majors of all types. If we publicize what is
"out there" to the students the interested ones will certainly
take the initiative. If we publicize it to more educators they
will suggest it to their students. The real challenge is for
educators to find ways to integrate BITNET with class directly.
There you go; one Undergrad's view.
*
**
***
**** *
* **** **
** **** ***
*** * **** *** *
**** ** **** *** * **
**** *** **** *** ** ***
**** **** ***** **** ** ****
**** * **** ************ *** **** *
****** ** ****** ***************** **** *
********* **** * *************************** ****** ****
************ **************************************************
***************************************************************
1
Page 14
*********
* * Accessing ISAAC through BITNET
* *
* * by Lorraine Edmond
* *
* * ISAAC@UWAEE
*********
Isaac is the Information System for Advanced Academic Computing
(formerly the AEP Bulletin Board). Isaac is funded by IBM to
serve as a clearinghouse for information about the use of IBM
computers and compatible software as aids to instruction and
research in higher education. Access is open to all faculty,
students and staff at institutions of higher education and to
members of participating professional societies.
While access to Isaac is free, you must apply for access using
the form at the end of this article. Note that both PC/modem
dial-up access and BITNET access are available. BITNET access
is specific to your userid. Using Isaac through the PC is much
faster and more interactive, but if you don't have the
equipment, BITNET access is possible. This article will
explain the how this works, but you STILL must apply for access
before trying any of these commands.
Isaac consists of a bulletin board and three databases.
* The bulletin board is made up of rooms which contain entries
relating to particular topics.
* The AEP Database contains descriptions of projects, funded
under the AEP program, which use or develop IBM hardware or
software for use as aids to higher education and research.
* The Special Studies Database contains descriptions of joint
research projects by IBM and university investigators.
* The SoftInfo Database is a guide to sources of information
about IBM-compatible software.
* The Academic Software Database is a catalog of software
available through Wisc-Ware.
For security reasons access to Isaac via BITNET is granted to
individual BITNET accounts/addresses rather than to individual
persons. Thus, if you have more than one BITNET account, you
will be able to access Isaac only from the authorized account.
1
Page 15
Access to Isaac via BITNET is accomplished by sending
interactive messages to a server called ISERVE@UWAEE. Note
that ISERVE will NOT accept commands sent by mail.
The commands for accessing the bulletin board rooms and those
for using the databases are different, so we will explain them
separately.
Note to users on VM systems: We have developed some software
which makes the process of getting the text of an entry from
the bulletin board or one of the databases simpler for VM
users. We send this software to VM users electronically a few
days after we mail their BITNET authorization packet. If your
BITNET account resides on an IBM mainframe which is running a
VM operating system and you do not receive this software,
please send a message to ISAAC@UWAEE.
The Bulletin Board:
The entries on the bulletin board are divided among "rooms"
according to their subject matter. Each room has a table of
contents which lists the entries it contains. In order to get
the text of one of these entries you will first have to
identify its title, as follows.
1. Send an interactive message to ISERVE asking ISERVE to send
you a list of the rooms and databases in Isaac. You will do
this with the command ROOMS:
CMS: TELL ISERVE AT UWAEE ROOMS
VMS: SEND ISERVE@UWAEE ROOMS
2. Go to your BITNET "mailbox" or readerlist and look at the
file Isaac has sent. Decide which room you'd like to see
entries from, then get out of the file and exit the mailbox.
3. Ask ISERVE to send you a list of the titles the room
contains. For example, to view the titles in the Announcements
room, type:
CMS: TELL ISERVE AT UWAEE ANNOUNCEMENTS
VMS: SEND ISERVE@UWAEE ANNOUNCEMENTS
Note: You don't have to type the entire room name; you can
abbreviate it to the the first 3 letters.
4. Go back to your BITNET mailbox and look at the new file; it
will contain a numbered list of titles. Decide which titles
you're interested in.
1
Page 16
5. If you're calling from an IBM VM system and you have
installed the GETTEXT XEDIT and PROFPEEK XEDIT files that we
sent you, move the cursor under the title you're interested and
press [PF10]. Repeat this step to obtain other entries.
If you're not calling from an IBM VM system, make a note of the
numbers next to the titles you're interested in. Then get out
of the file, exit the readerlist, and ask ISERVE to send you
those titles:
CMS: TELL ISERVE AT UWAEE ANNOUNCEMENTS 40 12 18
VMS: SEND ISERVE@UWAEE ANNOUNCEMENTS 40 12 18
Using the databases:
You will use interactive messages to perform keyword searches
of the databases. If you don't specify which database you want
to search, ISERVE will assume that you want to search the AEP
Database. To specify which database you want to search,
substitute the following abbreviations for in the
commands below.
AEP Database aep
SoftInfo Database sof
Special Studies Database spe
Academic Software Database aca
CMS: TELL ISERVE AT UWAEE [ISERVE command]
VMS: SEND ISERVE@UWAEE [ISERVE command]
[database] [keyword]
Searches the database for entries associated with that keyword
and sends you a numbered list of their project titles.
[database] [keyword] [title #]
Sends the full details of the project corresponding to an
earlier search of a keyword).
Sends the full details of that project.
Examples:
CMS: TELL ISERVE AT UWAEE AEP FRENCH
VMS: SEND ISERVE@UWAEE AEP FRENCH
1
Page 17
Searches the AEP Database for all projects associated with the
keyword "FRENCH" and sends you a numbered list of their titles.
CMS: TELL ISERVE AT UWAEE AEP FRENCH 1 2
VMS: SEND ISERVE@UWAEE AEP FRENCH 1 2
Sends the full text of the projects numbered 1 & 2 on the list
of projects associated with the keyword "FRENCH."
CMS: TELL ISERVE AT UWAEE AEP UTX001
VMS: SEND ISERVE@UWAEE AEP UTX001
Sends the full text of the project with ID "UTX001."
Sending files to Isaac via BITNET:
You can add entries to the rooms on the bulletin board as
explained below.
Example:
To make an entry in the Announcements room,
1. Create a file called ANN ISC (ANN.ISC on VAX systems) or
rename an existing file.
2. Use the BITNET command for sending a file to another
address.
CMS: SENDFILE ANN ISC ISERVE AT UWAEE
VMS: SEND/FILE ISERVE@UWAEE ANN.ISC
In addition, all entries must meet the following requirements:
1. The first line of the file must say "Title:" followed by the
title of the entry. For example, Title: New software builds
indexes from text files. (Note: the "T" of "Title:" must be
capitalized and the title line may not be more than one,
80-character line long.)
2. The filename must match the name of the room that it is to
be sent to (use the first three letters of the room name).
3. The filetype/extension must be "isc"
4. File width must not exceed 80 characters
1
Page 18
Request for access to Isaac:
Complete this application and mail it to:
Isaac Access
m/s FC-06
University of Washington
Seattle WA 98195
or use BITNET to send answers to the questions on this
application to ISAAC@UWAEE. User materials will be mailed to
you. This may take two to three weeks.
1. Name
2. Address, City, State, Zip
3. Phone: (w) Please include area code.
4. University
5. Your BITNET address
6. You may connect to Isaac in two ways. Each method requires
separate authorization. Please indicate which method(s) you
would like to use. If you choose modem access, we will provide
the communications software you'll need.
* IBM PC, XT, AT or compatible and a modem. (U.S. except WA)
Please specify diskette size 5-1/4 or 3-1/2
* BITNET. (You must include your BITNET address above.)
*
**
***
**** *
* **** **
** **** ***
*** * **** *** *
**** ** **** *** * **
**** *** **** *** ** ***
**** **** ***** **** ** ****
**** * **** ************ *** **** *
****** ** ****** ***************** **** *
********* **** * *************************** ****** ****
************ **************************************************
***************************************************************
1
Page 19
*********
* * LifeSci - Coming Soon
* *
* * by Ami Zakai
* *
* * RPR1ZAK@TECHNION
*********
A new service for the medical and paramedical profession is
scheduled to open in March 1988 at the Technion, Israel.
Did you ever want to talk to professionals in your field in
other countries using a computer but thought it was too
complicated?
How about locating experts in other medical centers or creating
work groups with daily contact and information transfer?
Ever wondered how multidisciplinary "Think-Tanks" can aid your
research?
Do you feel you were left behind? if so, I might have the
answer for you:
LifeSci is a machine intended to enhance interaction and
cooperation among researchers and scientists working far from
each other who can benefit from fast, cheap and continues
contact with their colleagues, it can make international work
groups and "Think-Tanks" into a reality by giving you tools
that you can use.
The audience for whom LifeSci was written knows little of
computers and is too busy to learn. It wants simple access
without having to bother with the internal works of the system.
For the past few years the availability of the communication
networks has grown to bring computer access to almost all
researchers in the life sciences. Most research institute
today have access to one of the various computer networks
(BITNET,UUCP,ARPANET etc.).
Though the tools are there, relatively few researchers from the
life sciences are active on the nets. Maybe its because people
from the exact science fields have used computers for years and
are more aware of the possibilities, perhaps the busy
physician does not have the time to learn the complexity of
syntax that is involved in conducting joint research over the
networks today and needs a more natural multilingual and
intuitive approach... To find the answer to this we wrote
LifeSci.
1
Page 20
LifeSci is short for "The Life Science Research Server" and is
a dedicated computer program developed at the Rappaport Family
Institute and running on the main computer at the Technion,
Israel (RPRLSCI@TECHNION). Its purpose is to enhance
communication among people in the life related fields
(medicine, physiology, psychology, social work etc..).
It has several integrated parts:
* DIGEST server: Digests are computerized magazines. They do
not appear in paper form but exist as electronic media. A
group of people interested in a common subject can create their
own little journal. Such a digest can have an editor or be an
open forum. Its as simple as saying "CREATE DEMENTIA" and
every one can do it, once created this "topic" will bind a
group of users who will subscribe to it and make them into a
work group. Just create your own or join an existing topic.
Unlike its paper counterparts all digests are archived and
indexed and can be searched and retrieved using simple
commands.
* NAME server: To locate people from other places according to
their name or interest is one of the prime objectives. As you
join, you will be asked to fill up a registry form with your
vital statistics, interests and area of expertise.
* APPLICATION server: If you need a special computer program
to aid in a specific experiment, preform a special analysis or
run laboratory equipment there is a fair chance someone has
already written it or something similar elsewhere, so why
reinvent the wheel? LifeSci will not keep the programs
themselves but will keep records of computer applications
developed elsewhere with instructions on how to get them, whom
to contact and what you need to use them.
* CONFERENCE server: "Chatting" is the interactive sending and
receiving of computer messages, more then two people can chat
using special relay machines. Registered users of LifeSci will
be able to hold conferences by calling members of their TOPIC.
The log of a conference can be distributed as a digest to the
missing members. The interface to BITNETs well known RELAY will
be complete shortly.
* BBOARD: Just a small bulletin board, the BBoard is a public
clipboard to post messages of general interest and is
accessible by all users.
LifeSci is a dynamic tool. It monitors its own use and records
the problems and difficulties of those who use it, so enabling
improvements according to what YOU need.
1
Page 21
Since we try to learn your needs, the registry is not automatic
and all registered users will be asked to fill questionnaires
periodicly as to the function of LifeSci and their use of it. I
promise to make those sparse and short.
LifeSci is designed to be a practical tool according to our
concept of the needs of a scientist or a physician, but its
only the beginning of a process, it will evolve or die
according to your feedback.
So what do you need to join LifeSci?
1. A computer account on a network that can at least mail
BITNET.
2. Minimal knowledge on how to logon and basic use of the
editor and mail tools on your system. Sending messages is
useful but not essential.
The LifeSci machine has been thoroughly debugged by a test
group for a period of over 6 month, however as Murphy used to
say we can't make a system foolproof and I am sure you will be
able to find rough spots in the design and usage.
For a list of LifeSci commands, send the HELP LIST command to
RPRLSCI@TECHNION via mail or message.
*
**
***
**** *
* **** **
** **** ***
*** * **** *** *
**** ** **** *** * **
**** *** **** *** ** ***
**** **** **** **** ** ***
**** **** **** ***** *** ****
****** **** ***** ***** ***** ****
******* ***** ***************** *****
******** ******* ****************** ******
********** ********** ******************* ********
************ *****************************************
************* *******************************************
**********************************************************
*************************************************************
***************************************************************
***************************************************************
1
Page 22
*********
* * The Space Physics Analysis Network
* *
* * from the SPAN HELPFILE
* *
* * NETSERV@BITNIC
*********
This article is second in a series about other networks.
The Space Physics Analysis Network (SPAN) has rapidly
evolved into a broadly based network for cooperative,
interdisciplinary and correlative space and Earth science data
analysis that is spaceflight mission independent. The
disciplines supported by SPAN originally were Solar-
Terrestrial and Interplanetary Physics. This support has
been expanded to include Planetary, Astrophysics,
Atmospherics, Oceans, Climate, and Earth Science.
The SPAN utilizes up-to-date hardware and software
for computer-to-computer communications allowing binary
file transfer, mail, and remote log-on capability to over
1200 space and Earth science computer systems in the
United States, Europe, and Canada. SPAN has been reconfigured
to take maximum advantage of NASA's Program Support
Communication Network (PSCN) high speed backbone highway that
has been established between its field centers. In addition
to the computer-to-computer communications which utilizes
DECnet, SPAN provides gateways to the NASA Packet
Switched System (NPSS), GTE/Telenet, JANET, ARPANET,
BITNET and CSNET. A major extension for SPAN using the TCP/IP
suite of protocols is also being developed.
The SPAN first became operational in December 1981 with
three major nodes: University of Texas at Dallas, Utah State
University, and MSFC. Since that time it has grown
rapidly (see Section II). Once operational, SPAN
immediately started to facilitate space-data analysis by
providing electronic mail, document browsing, access to
distributed data bases, facilities for numeric and graphic data
transfer, access to Class VI machines, and entry to
gateways for other networks.
The SPAN is currently managed by the National Space Science
Data Center (NSSDC) located at Goddard Space Flight Center
(GSFC). All SPAN physical circuits are funded by the
Communication and Data Systems Division at NASA
Headquarters. Personnel at the NSSDC facility, at the NASA
SPAN centers, and the remote institutions work in unison
1
Page 23
to manage and maintain the network. Detailed information on
how SPAN is managed can be found in the SPAN Management
Guide which is published by the NSSDC.
Sending mail to people in the SPAN is quite simple: The syntax
sends you through a gateway at Stanford in ARPANET:
spanuser%spanhost.SPAN@SU-STAR.ARPA
For example:
FRED%SATCOM.SPAN@SU-STAR.ARPA
*********
* * Software Archives at RPICICGE
* *
* * by John S. Fisher
* *
* * FISHER@RPICICGE
*********
Selected portions of the SIMTEL20 Internet public domain
archives are available from LISTSERV@RPICICGE. These are:
PD: -- Info-CPM software archives.
PD:*.* -- SIG/M software archives.
PD:*.* -- PC-Blue software archives.
PD:*.* -- IBM PC (and friends) software archives.
PD:*.* -- Miscellaneous software archives.
New commands have been added to this list server so that you
may retrieve these files. Please note that these
modifications are EXPERIMENTAL. The server's primary goal is
to support the Info-CPM people on BITNET, but as long as that
goal is still achievable, the server is available to all.
Commands may be sent to LISTSERV@RPICICGE by either mail or
message.
The /PDDIR command is used to list the names of files that
match some pattern. The syntax for this command is as follows:
/PDDIR PD:filename.ext
The directory name must be one of CPM, SIGM, PC-BLUE, MSDOS, or
MISC. The subdirectory, filename, and ext may include
asterisks ('*') as "wild-card" characters. If any of the
three are omitted, an asterisk is used. The following are
examples.
1
Page 24
/PDDIR PD: Lists files in the MSDOS archive.
/PDDIR PD: Lists VAX/VMS related files.
/PDDIR PD:UUDECODE*.* Lists uudecode software for CP/M.
The /PDGET command is used to request specific files. No
pattern-matching is allowed. The syntax for this command is as
follows:
/PDGET format simtel.filename ( encoding
The format specifies how the file is to be transmitted.
Allowed values are NETDATA, PUNCH, and MAIL. The encoding
specifies any special translation for the file data:
NETDATA: suitable for transfer to BITNET hosts that can accept
files in IBM Netdata format.
PUNCH: suitable for transfer to BITNET hosts that can accept
files but cannot decode the Netdata format. Files are sent as
80-byte card-images.
MAIL: suitable for transfer to hosts that can accept only mail
or are accessible to BITNET only through gateways. Large files
sent via mail are split into several smaller files that the
recipient must reassemble.
The encoding specifies any special translation for the file
data:
ASIS: suitable for hosts that can receive binary data. The
file is sent exactly as it is stored on the server: binary
images of the file data. ASIS may be used only with format
NETDATA.
UUENCODE: suitable for hosts that cannot receive binary data.
The file is sent uuencoded.
TRANSLATE: suitable for any host, but only when the file
actually represents readable text. The file is translated to
EBCDIC. (If you are on an ASCII machine, then your system
should automatically translate to ASCII when the file arrives.)
TRANSLATE applied to a binary file will yield trash.
If no encoding is specified, then ASIS is assumed for NETDATA,
and UUENCODE for the others.
Users on non-IBM hosts should remember that with the
NETDATA/ASIS server defaults, binary data is put on an EBCDIC
network (viz. BITNET). The normal action of most non-IBM
networking software is to do EBCDIC/ASCII translation on
1
Page 25
incoming data. This will render most files from the server
useless. Non-IBM users should either use one of the other
encoding options or receive the a file without translation.
(VMS/JNET has this capability.)
In each of the following examples the user wants the
UUDECODE.HEX and the UNARC16.ARK files to download to a CP/M
micro.
1. The user is on an IBM host directly connected to BITNET:
/PDGET NETDATA PD:UUDECODE.HEX (TRANSLATE
/PDGET NETDATA PD:UNARC16.ARK
The TRANSLATE option for UUDECODE.HEX is not necessary, but it
does simplify/speed-up the later down-loading of the file to
the microcomputer. It can be down-loaded as a text file rather
than as a binary file.
2. The user is on a non-IBM host directly connected to BITNET
and can receive Netdata files, but not binary:
/PDGET NETDATA PD:UUDECODE.HEX (TRANSLATE
/PDGET NETDATA PD:UNARC16.ARK (UUE
3. The user is on some host somewhere:
/PDGET MAIL PD:UUDECODE.HEX (TRANSLATE
/PDGET MAIL PD:UNARC16.ARK (UUE
Additional remarks:
1. If the server is unable to satisfy a request for a file from
Simtel20 in five days, the request is rejected.
2. The server limits /PDGET requests to one per day. There is
no limit on /PDDIR requests. The limits are subject to change.
3. The server refreshes its directory listings of files at
Simtel20 about every two days. Therefore, there is a window
during which requests for recently deleted files are accepted
by the server and requests for recently added files are
rejected.
4. Problems regarding the service should be sent directly to
FISHER@RPICICGE, and not to anyone at Simtel20 or its
associated interest groups.
1
Page 26
*********
* * The On-Line Journal of Distance Education
* *
* * by Jason B. Ohler and Paul J. Coffin
* *
* * JADIST@ALASKA
*********
The On-Line Journal of Distance Education and Communication
Special Interest Group has two primaray concerns:
FIRST, it is concerned with distance education as the
organized method of reaching geographically disadvantaged
learners, whether K-12, post secondary, general
enrichment students, or people in business. Areas of
interest include delivery technologies, pedagogy, cross
cultural concerns of wide area education delivery, and any
other matters regarding the theory and practice of distance
education.
We recognize that education encompasses a broad area of
experience and that distance education includes distance
communications that fall outside the domain of formal
learning. The Journal welcomes contributions that deal with
serving people at a distance who aren't necessarily associated
with a learning institution. We welcome information about,
for example, public radio and television efforts to promote
cultural awareness, governmental efforts to inform a
distant public about policy issues, or the many training
programs run by private business to upgrade employee skills.
Once the distance education infrastructure is solidly in
place, local learners will want to tap into it, because they
simply prefer learning in a decentralized setting or because
they want to expand their learning opportunities and
resources beyond those immediately available to them. This
phenomenon, which we call 'bringing distance education home,'
will grow in the coming years and we look forward to hearing
from people about it.
SECOND, the Journal is interested in projects concerned with
overcoming cultural barriers thorough the use of
electronic communication, particularly electronic mail.
The Journal particularly looks forward to contributions
concerning efforts to improve electronic communication between
the USSR and the US.
To subscribe, send the following command to LISTSERV@UWAVM via
mail or message: SUB DISTED your_full_name
1
Page 27
*********
* * Bioserve - the Bioscience File Server
* *
* * by Deba Patnaik
* *
* * DEBA@UMDC
*********
BIOSERVE is a network file server for BIOSCIence area.
Currently, previous BIOTECH bulletins, SEQNET bulletins and
information on plasmid sequences are stored on the disk.
Public domain data and software in biotechnology area will be
available in future. (To subscribe to BIOTECH bulletins,
please mail your requests to BIOTECH@UMDC )
The server accepts both interactive message requests and e-
mail requests. Currently the server accepts only one
command per message or per e-mail at a time. The E-mail
interface works for mail headers. In case it does not
respond to your mail request, please report to us. One
command is accepted after the Subject: header in the same
line. The server is going through changes everyday. New
functions and new resources will be announced whenever it is
available on BIOSERVE. The following four commands are
currently supported:
HELP
LIST
SENDme filename filetype
WHATIS NEW
The server address is BIOSERVE@UMDC.
*
**
***
**** *
* **** **
** **** ***
*** * **** *** *
**** ** **** *** * **
**** *** **** *** ** ***
**** **** ***** **** ** ****
**** * **** ************ *** **** *
****** ** ****** ***************** **** *
********* **** * *************************** ****** ****
************ **************************************************
***************************************************************
1
Page 28
*********
* * Headlines
* *
* * Smaller bits of news, but not unimportant
* *
* * BITLIB@YALEVM
*********
* In a close, but well differentiated, race, Glenn Ricart has
won a one year seat on the BITNET Board of Trustees. It is
interesting to note that there was one abstention!
The following BITNET Institutional Representatives are members
of the BITNET Board of Trustees:
Douglas Bigelow BIGELOW%WCC@WESLEYAN
Ira Fuchs FUCHS@PUCC
Butch Kemper X040BK@TAMVM1
Ben Klein BSKCU@CUNYVM
Les LLoyd LLLOYD@DREW
Phil Long LONG@YALEVM
Glenn Ricart RICART@UMDC
Marty Solomon TS2425@OHSTVMA
Douglas Van Houweling devh@UM.CC.UMICH.EDU
Leland Williams TUCLHW@TUCC
John Young CJY2@NERVM
* A new newsletter: John Muffo is Editor of the AIR
Newsletter. The topic of AIR is Institutional Research and
Planning Analysis. If you are interested in a subscription or
have AIR news send mail to John at IRMUFFO@VTVM1.
* /WHOIS News: The Listserv /WHOIS name server modification
(installed on some list servers) has been modified so that you
can now receive better information. For example, if you search
for JOHN DOE, you will now receive matches for John Q. Doe,
John Doe, Doe John Q., and so on. The /WHOIS mod has been
added to two more list servers: LISTSERV@UALTAVM and
LISTSERV@UKANVM. Thanks to Michael Gettes, Chris Thierman, and
Wes Hubert for the information.
* New Listserv filelists: LISTSERV@PUCC now has a FILELIST for
the COCO mailing list. The FILELIST also includes many files
of interest to Tandy Color Computer Users. LISTSERV@RICE holds
a Macintosh software library in it's MAC-ARCH FILELIST. For
users in the southern United States, this is much closer than
1
Page 29
MACSERVE@PUCC. For more information on these filelists, send
the INDEX command to each of these list servers via mail or
message. For example:
INDEX COCO (sent to LISTSERV@PUCC)
INDEX MAC-ARCH (sent to LISTSERV@RICE)
Thanks to Eric Tilenius and John Courcoul for this information.
*********
* * Helpdesk
* *
* * a Question and Answer Column
* *
* * Send your questions to BITLIB@YALEVM
*********
*Q* How does one go about find a particular list on a LISTSERV
without having to resort to sending a LIST command to every
one??
*A* The best place to look for a list (ANY list) is in Rich
Zellichs List-of-Lists. It is stored on most NETSERV file
servers. NICSERVE@BITNIC also has a file named LISTSERV GROUPS
which lists many of the popular Listserv lists.
*Q* How does one go about forming his or her own list?
*A* If you have a Listserv at your node, ask the Computer
Center staff at your site. If you don't have a listserv,
contact the Listserv administrator at a nearby Listserv. If
you send a Listserv the HELP command, at the end of the command
list you will be shown a list of Postmasters for that server
and their addresses. They should be able to help you set up a
list, or direct you to someone who can.
*Q* Is there any conventional way to ship binary files / object
code on BITNET?
*A* The only thing I know of are the UUDECODE and UUENCODE
programs available from the SIMTEL20 archives on
LISTSERV@RPICICGE. (See the article on that server in this
issue for more information). Thanks to Eric Thomas for his
help with this answer.
1
Page 30
*Q* A few months ago, if you wanted to send a file from TAUNIVM
(or any other place in Israel, actually) to CUNYVM (or any
other place in the U.S.) the file's way was quite short:
TAUNIVM-EARNET-CUNYVM. --but-- Today, when you want to send the
same file, it has to pass two nodes in Italy, one in France,
and CUNYVMV2, before it gets to CUNYVM. My question is short:
WHY? Is that a policy or something?
*A* As the network grows, nodes are being moved around and
reorganized. Some new nodes are physically between other
nodes, so by connecting through the new node, line lengths are
reduced and costs are cut. That, at least, is a good guess.
*Q* I read your article in Netmonth and I am looking for some
help in reaching England. His colleagues there have given him
three different usercodes to try. I have had several
unsuccessfull attempts at getting mail through.
These are the addresses he was given:
SUQVINES%UK.AC.AM.CMS@UKACRL
SUQVINES%UK.AC.RDG.AM.CMS@EARN
SUQVINES@UK.AC.RDG.AM.CMS
*A* As we said in our article on JANET last month, the
addresses in England are backward from the way we are used to
them (isn't everything over there?) ALWAYS make sure the UK is
at the end. The address you should use is:
SUQVINES@CMS.AM.RDG.AC.UK
*Q* Where can I get useful general purpose VMS tools written in
DCL to make my VMS/Jnet enviroment more pleasurable?
One server which has VMS software is UBSERVE@UBVMSC. For more
information, type the command SEND UBSERVE@UBVMSC HELP.
*
** *
* **** **
** **** ***
*** * * **** *** * *
**** ** *** *********** *** *** *
**** *** ******** ****************** ***** **
****** *************** ******************************
*********** *************************************************
***************************************************************
1
Page 31
*********
* * New Mailing Lists
* *
* * from List-of-Lists by Rich Zellich
* *
* * ZELLICH@SRI-NIC.ARPA
*********
ADA-SW
A mailing list for those who in accessing and contributing
software to the Ada Repository on SIMTEL20; it serves two
purposes: to provide an information exchange medium between
the repository users and to mail repository submissions to the
Coordinator for inclusion in the archives.
All requests to be added to or deleted from this list,
problems, questions, etc., should be sent to ADA-SW-
REQUEST@SIMTEL20.ARPA.
Coordinator: Rick Conn
ADVSYS
Mailing list for Advsys programmers.
All requests to be added to or deleted from this list,
problems, questions, etc., should be sent to ADVSYS-
REQUEST@EDDIE.MIT.EDU.
Moderator: Brian Preble
COCO
Discussions related to the Tandy Color Computer (any
model), OS-9 Operating System, and any other topics relating
to the "CoCo", as this computer is affectionately known.
To subscribe, send the following command to LISTSERV@PUCC
by mail or message:
SUB COCO your_full_name
Coordinator: Eric W. Tilenius
1
Page 32
DAVE-BARRY
Mailing list for Dave Barry discussions.
All requests to be added to or deleted from this list,
problems, questions, etc., should be sent to DAVE-BARRY-
REQUEST@EDDIE.MIT.EDU.
Moderator: Brian Preble
*********
* * Feedback
* *
* * How? Why?
* *
* * Send your letters to BITLIB@YALEVM
*********
From: David Klein
Subject: Uses for BITNET
I read your editorial in the most recent Netmonth issue and
was quite in agreement. I also was struck by the fact that
there seems to be little (that I have come across yet)
documentation on all the features that the BITNET has to offer,
both to faculty in most disciplines and students (graduates
and undergraduates). I for one would find it very useful if
there was a concise, well written file somewhere that
listed the available uses for this medium. This file should
also include how to use those services, or at least provide the
node and file which hold the more in-depth instructions for
that specific facility.
The reason I would like to know is that, as a relatively new
user, and at the same time an advisor at my college, I would
like to provide my boss with some hard information that would
influence him to upgrade the present low level of
support/general awareness for and about BITNET. If I could
present this info to him, it would be one step in
encouraging use of an excellent medium for information
exchange and research which, at present, is quite under-
utilized here.
Would you have any ideas whether or not some sort of
publication like this exists, or could it be set up?
1
Page 33
* While there is no publication for that kind of information, I
am hoping that NetMonth can fill that role with the new
"Applications" section, beginning next month. As for in-depth
instructions, we offer the BITLIB online help system to all VM
nodes who will have it. It has all the BITNET services listed
in a simple menu structure, with instructions for how to access
them. -- Chris
From: Michael J. Hammel
Subject: Getting involved.
Why is it, as I sit here in my lonely Texas plains office, that
it seems technology is developed on the West coast, used on the
East coast, and ignored here in the middle? We seem to pride
ourselves on being Bigger and Better in everything, but have
you ever tried to plug a keyboard into an 1800 pound steer?
Not to mention trying to get a printout.
I'm a communications nut. BITNET has taught me more about
computers and computing than ANY class I ever took, and in less
time. Chris, you put it well in your January Bitnotes article
when you said a textbook can't hold a candle to experience.
Amen. I too graduated last year, and I'm still here at school,
getting that important word amended to my resume thats required
by all grads with GPA's that look like Avagadro's number:
Experience. Note: capital 'E'.
But enough of this babbling. What I really wanted to talk
about was how, here at my school at least, all the comforts
afforded the modern student are being passed up. I realize
that Relay is not exactly, in its current form and use,
something to get professors and administrators hopping up and
down about as an educational tool, but it can be. A very good
example seems to be the LifeSci Monitor. I don't know much
about it, but just from your little blurb in January's
Headlines I think it could give some respect to our little
communications network here. The whole idea of being able to
talk to someone far away is to get some information (at least
from a business and educational point of view). Conferencing
over Relay makes sense to me. Reserve channels for meetings
and discussions. You could possibly imitate a non-visual form
of the TAGER system (if I spelled that correctly). One VERY
important use of something like this would be to train local
contacts, those responsible for knowing the "How's" and "Why's"
of BITNET (and Mailer for that matter) such as myself. I
inherited this job because I enjoy it. But no one knows much
about it here, and, unfortunately, aside from a few systems
programmers and student assistants, no one cares much about it.
1
Page 34
I have to find things out on my own by making myself somewhat
of a nuisance to others on the net (my thanks to Bill Rubin
and Jeff Kell for lots of help).
From: Dwight McCann
Subject: NetWeek & NetMonth
I really like the NetWeek idea. I will be posting each
successive issue to our NEWS system. The new look of NetMonth
is nice, but having quality editorials borders on miraculous.
For those of us who want to know what is going on, but are
devoted to other areas of computing, your efforts are a boon.
From: Peter Flynn
Subject: NetMonth and Desktop Publishing
I would prefer NetMonth to remain a printfile. I think the
standard of design you have achieved is remarkable considering
the limitations of 80-col screens and 66-line paper.
If you wanted to move it to DTP, then *surely* the sensible
solution is to use TeX. This way the source file (which is a
plain edit file) can be sent over the net, just as the present
version is, but sites can then push it thru TeX and laserprint
or whatever their local copies. As TeX is available for very
little capital outlay, and runs on a wide range of kit, there
is little excuse for sites not having it.
This sounds like an apologia for TeX, but what I'm really
saying is, follow the BITNET principle: Because It's There ---
TeX is cheap and already on probably a majority of academic
sites worldwide in one form or another. Why DTP the mag and
force people to buy expensive s/w they may not otherwise use?
I'd happily TeXify an issue to see what it would come out like.
*
** *
* **** **
** **** ***
*** * * **** *** * *
**** ** *** ****** **** *** *** *
**** *** ****** ***************** **** **
**** **** ******** ******************* ****** **
****** *************** ******************************
*********** *************************************************
***************************************************************
***************************************************************
1
Page 35
*********
* * NetMonth Polices
* *
* * Everything you ever wanted to know...
* *
* * 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
NICSERVE@BITNIC.
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 36
* 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."
***************************************************************
|
|
