|
|
NetMonth, July 1988
******** **************************************************
* * *
* * The independent guide to BITNET *
* * *
* * July, 1988 *
* * *
* * Volume 3, Number 1 *
******** * *
* *
*** * *
* * * * *
* * * * *
* * * * *
* ** * ********
* ***************
* * *************** *
* * ************** *
****** * ************* *
* * ************ *
* * ************ *
* ********** *********
******** * ********* ***************
* * ******** ************** *
* * ******* ************* *
* * ****** ************ *
* ****** *********** ********
* ***** ********** **************
******** **** ********* ************* *
*** ******** ************ *
*** ** ******* *********** *
* * * ****** ********** *
* * * ***** ********* *********
* * ***** ******** ************* *
*** **** ******* ************ *
*** ****** *********** *
****** ** ***** ********** *
* * **** ********* *****
* * *** ******** *************
* **** ******* ************ *
**** *** ****** *********** *
** ***** ********** *
* * **** ********* ******
* * *** ******** ***************
****** *** ******* ***********************
* ** ****** ******************************
* * ***** ************************************
* **** *****************************************
******** *** *********************************************
* ** ************************************************
* * **************************************************
* ****************************************************
**** **************************************************
1
* * * * *
** * * ** ** * * *
* * * *** ***** * * * * *** **** ***** ****
* * * * * * * * * * * * * * * *
* * * ***** * * * * * * * * * *
* ** * * * * * * * * * * *
* * **** * * * *** * * * * *
***** ******
Christopher Condon Editor CONDON @ YALEVM
Timothy Stephen Associate Editor STEPHEN @ RPICICGE
Craig White Associate Editor CWHITE @ UA1VM
Wendel Bordelon Contributing Editor TACVRWB @ TCSVM
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 Pillar of Virtue MOSS @ YALEVM
******************** Contents - Issue 23 ********************
EDITORIAL PAGE_________________________________________________
Bitnotes .................................................... 1
Flames To: .................................................. 7
Bringing BITNET to the Eastern Bloc ......................... 3
FEATURES_______________________________________________________
The NeWS Archive SErver ..................................... 9
The UTC Name Server ........................................ 10
DEPARTMENTS____________________________________________________
Headlines .................................................. 13
New Mailing Lists .......................................... 12
Feedback ................................................... 17
Policies ................................................... 20
* 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: 3030 >--------------------
1
Page 1
*********
* * Bitnotes
* *
* * by Christopher Condon
* *
* * Yale University
* *
* * CONDON@YALEVM
*********
"Your kindness will never be obliterated by your good looks."
FSFnet
12/84 - 08/88
When I was first learning about BITNET, Dave Liscomb was
distributing an announcement of his electronic magazine, the
Fantasy and Science Fiction Network (FSFnet). These were the
days when the network was small (a few hundred nodes) and there
were no list servers or Relays. Come to think of it, there was
no NetMonth, or Bitlist, or BITLIB. There was only VM/COM, a
computer science interest magazine distributed by the people
who ran CSNEWS. If I remember correctly, Dave was a staff
member of that publication.
Here was Dave, starting out a magazine of his own. I found out
about in the typical way that people found out about those
things in BITNET-1984. When I was learning about the CSNEWS
file server, I added myself to the legendary Bitnauts List.
Dave sent out his announcement to everybody in Bitnauts who
said they had an interest in Fantasy or Science Fiction. It
seems that I was one of those people.
About this time, many of you are thinking, "Big deal. I have
not the slightest interest in Science Fiction or Fantasy." You
might not realize the important role that FSFnet has played in
the development of the network. FSFnet was the first BITNET
electronic magazine with a subject matter having absolutely
NOTHING to do with computers. While you may or may not care
for the topic, Dave Liscomb showed that the network could be an
effective form of communication for people interested in non-
computer topics.
This served as the inspiration for the early BITNET magazines,
many of which are still in production today. There was
NutWorks (humor), CRTNET (communications), Bitlist...
1
Page 2
Bitlist, the weekly predecessor to NetMonth, was, of course,
based on a computer-related topic. Early on, however, FSFnet
served as the inspiration for producing an electronic magazine.
Later, when Bitlist became NetMonth, FSFnet was the model of
consistency and quality I hoped to achieve.
Dave is leading the network now, and FSFnet will cease
publication. He has made arrangements for the startup of a new
magazine to carry on FSFnet projects (see Headlines). I cannot
help but feel, however, that these are, in network terms,
deaths (hence the eulogy tone of this editorial). When Dave
leaves BITNET that will most likely be the last contact I have
with him. He has been a pioneering networker and a good
friend.
Still, we must not think of this as an end, but as a beginning.
He is going on to a far better life...
The network will go on without Dave Liscomb and FSFnet, a
little less whole because of their absence, better because of
thier presence.
***************************************************************
I have some good news and some bad news. The good news is the
staff listing you see on the second page of this issue. The
people there have generously offered their time and talents to
keeping NetMonth going. I, of course, am going to take full
advantage of them.... er... this. In the coming months you
will see that the various features and news items will be carry
their bylines. Their contributions will increase the quality
and timeliness of the magazine.
The bad news is that there will be no NetWeek this summer.
There just hasn't been enough news to justify sending one out
every week. Rather than cancel the whole thing, we will simply
start it up again when the fall semester begins. Call it a
summer vacation. Since this lack of news happens every summer,
we will no doubt go on vacation again next year.
Virtually,
Chris Condon@YALEVM
1
Page 3
*********
* * Flames To:
* *
* * by Craig White
* *
* * University of Alabama
* *
* * CWHITE@UA1VM
*********
Hello once again,
I have had a very nice month, hope you did too. A couple of
times during the month, parts of the net that were important to
me were down for long periods of time, but, overall it was a
good month for my networking activity. I am really having
problems with mail as there are more lists that I feel I need
to read to keep up with the technical aspects of my life. This
just means that my allotted time for mail is pressed to it's
limit. Unfortunately, I've had to unsubscribe to some of the
more esoteric digests that often make my day a little brighter.
It seems I am becoming a solely technical person. Maybe I'll
just resubscribe and allot a little bit more time for mail so
that I can have time to relax with some non-computer type
mailing lists.
I've been meaning to address this for some time now but I just
keep forgetting to put it in the article: I appreciate all the
mail I get from people who read the column and I do read every
one. Normally, I do not respond to those of you who write but
this by no means indicates that I'm not interested in what you
think. I think many people have noticed that I've used gripes
of theirs in my columns and when I feel that it's absolutely
necessary that you get a response I do send one off. I'm sorry
that I'm not able to answer every letter that I get but I
promise I take what you say seriously and I do read and use
ideas that are sent to me.
This months flame is about the flood of mailings that often
occur following a large posting, a multiple list posting and
often flames. What I'm talking about is the many follow-up
posting to the effect of; "I had to discard that note from XX
number of lists that I'm on and I'm sick of seeing that piece
of mail"; Or, "I wish so and so would take their gripes off
the list and discuss them privately." I hate to discard
multiple posting and I also get tired of discarding personal
flames.
1
Page 4
This particular topic is a very hard one for me because, on the
one hand I think that the way changes in net behavior occur is
for fellow networkers to write and gently chastise each other
for behaviors that they think are inappropriate or that violate
the official rules of conduct. On the other hand, sending
these to the list costs a lot in terms of traffic, especially
when it is made public via a list. It seems that somehow these
proddings need to be private. Unfortunately, by doing this we
are not allowing newcomers to the net world an opportunity to
find out what the unspoken rules of the game are. At the
moment with our current network saturation level, we cannot
afford to allow a few to learn at the expense of others.
Therefore, I am recommending that if a person makes an
inappropriate posting and you feel the need to flame them,
please make it private. If 10 people feel the need to make the
same flame then fine. If it's private, there are a lot less
copies of that flame moving around. This could really add up
on some of the more popular lists.
Finishing up, I think that when someone posts something that is
inappropriate we should GENTLY (that means without insulting
someone's intelligence, family, family to be) chastise that
person PRIVATELY about their behavior. You will want to be
sure to include logical arguments and possible alternative
actions rather than blast them for their error.
It was brought to my attention this month that LDBASE COM (the
LDBASE program for the VAX) is not yet available. I do not
know the current status of this project but maybe there will be
more news about this next month. As always questions,
comments, and Flames should be sent to CWHITE@UA1VM.
1
Page 5
*********
* * Bringing BITNET to the Eastern Bloc
* *
* * by David J. Hibler
* *
* * University of Nebraska-Lincoln
* *
* * ENGL0333@UNLVM
*********
Jason Ohler's provocative article ("Let's Bring BITNET to the
Soviet Union") in the May issue of NETMONTH has already
elicited comment, but much more still needs to be said.
Personally, I think the proposal is a very sound one, and I had
toyed with suggesting the same a few months back but never got
around to writing up the ideas. I'd like to thank Ohler for
bringing the issue into public view so it can be discussed more
widely.
The fundamental assumptions behind Ohler's proposal are
certainly quite valid. It is in the best interests of everyone
if we can find ways for direct and peaceful interchanges with
the Soviets rather than military ones. And he is quite correct
in asserting that advances in modern technology have bridged
previously insurmountable barriers of physical distance. Yet
let us not be naive about what may be one of the most profound
obstacles to be overcome before such an exchange becomes
possible: the seemingly insurmountable barriers of political
paranoia, hostility and intransigence on BOTH sides of the
ocean.
Ohler asserts that "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," thus implying that the Soviet
government would be the one which felt most threatened by any
such exchange. In his June commentary on the article, Dave
Phillips picks up this theme and develops it even further by
asserting, "this would be a great idea if and only if access to
the links at the Soviet side were not rigidly controlled and
rationed to 'reliable' people." Both are generally correct in
acknowledging the existence of previous Soviet restraints on
the flow of information, though there is certainly no better
time than the present to test whether or not glasnost and
perestroika have truly altered the Soviet landscape. But both
are incorrect if they mean to imply that the Soviet government
is the only government which might have reservations about a
computerized linking of our cultures.
1
Page 6
For just as crucial as the question of Soviet resistance is the
question of U.S. roadblocks to such a venture. Recent years
have seen direct Presidential interdictions on the exchange of
high-tech with the Soviets. Our government seems acutely
sensitive to the transfer of computer-based technologies, for
it is particularly in this area that we enjoy a commanding lead
on the Soviets. Put in simple terms, it is quite possible that
some people in our government might see a BITNET link with the
Soviets more as a threat to our national security than as a
means of advancing intercultural dialogue between our
respective peoples.
And if we are to be perfectly honest, such fears are not
entirely groundless. As we all are quite aware, even the
people who invent systems do not always know how they will be
applied or what capabilities they might eventually assume. For
proof, simply look at the way in which BITNET or e-mail in
general have evolved in only a few short years. And once the
technology is in place, who is really in a position to control
what is sent out over it? Such an information transfer would no
doubt be a two-way street. Just as the Russian bureaucracy
might tremble at the implications of its citizens in direct
link with the West because of the social implications, so the
American bureaucracy will no doubt tremble at the ease with
which sensitive databases might end up in Soviet hands.
In my mind, the opportunities are well worth the risks, for
personally I feel we will be in a much better position to
impress their citizens with our friendliness, our openness, our
excitement, and our eagerness to learn--and to be similarly
impressed in turn by their own citizens--than the Soviets will
be to steal secrets which they'd otherwise probably pilfer
eventually anyway.
But more is needed now than merely raising the idea. Someone
must take up the standard and advance the issue, keeping in
mind that there will undoubtedly be resistance from both
governments. As the issue is advanced, there must be a
comprehensive strategy which will allow both sides to explore
the implications of such an exchange without suffering any loss
of face. Such a strategy might contain at least some elements
of the following proposal.
First, General Secretary Gorbachev should be approached,
probably through the cultural liaison at the Soviet Embassy,
and asked directly whether or not his view of glasnost would
permit communication via computer by students and professors at
Soviet universities with their counterparts at American
universities. If he responds negatively, there is really
1
Page 6
little point in pursuing the matter any further at this time.
For if the principal architect of perestroika is not in favor
of the idea, don't expect any of his subordinates to advocate
it. But if he responds positively and indicates at least a
willingness to discuss the matter further, then the monkey will
be on our back and we will need to confront those who are about
to be in power as to their intentions in this regard.
Notice the careful phrasing of that last sentence, for there is
little point in initiating discussions with an American
administration which has less than a half-year left. But there
might be much point in presenting such an issue to the two
Presidential contenders and seeing if substantive differences
in this regard exist between the major parties. Indeed, such
an inquiry might even make an interesting addition to a
Presidential debate--for we've listened to the candidates
belabor the other issues for months now, but we've heard
precious little about how either party might go about improving
the cultural and educational climate between our respective
peoples.
Some closing notes. Ohler cites an American professor who has
managed to establish e-mail links with his Soviet counterparts,
but does anyone know of any other instances? In particular,
does USENET have any such links? Finally, why should we limit
ourselves only to Soviet links as Ohler suggests or to Polish
links as Phillips counterproposes? Why not simply advance the
concept of opening the entire Eastern bloc to BITNET access?
And why stop there? How about the mainland Chinese? Are they to
be ignored? We fashion ourselves a "world-wide" network, but
isn't it time we took steps to live up to that billing?
1
Page 7
*********
* * The NeWS Archive Server
* *
* * by the NeWS Archive Manager
* *
* * Sun Microsystems
* *
* * MANAGER-NEWS-ARCHIVE@SUN.COM
*********
The NeWS Archive Server at Sun Microsystems (NEWS-
ARCHIVE@SUN.COM) is a mail-response program. That means that
when you mail a request to the server, it will mail back a
response.
The file server does not perform extensive error checking. If
you do not send the server commands that it understands, the
response will be: "I don't understand you."
The file server has several commands. Each command must be the
first word on a line. The file server reads your entire
message before it does anything, so you can have several
different commands in a single message. The file server treats
the "Subject:" header line just like any other line of the
message. You can use any combination of upper and lower case
letters in the commands.
The archives are organized into a series of directories and
subdirectories. Each directory has an index, as does each
subdirectory. The top-level index gives you an overview of
what is in each of the subdirectories, and the index for each
subdirectory tells you what it contains.
If you are bored with reading documentation and want to try
something, send the server a message containing the line:
SEND INDEX APPLICATIONS
When you get the index back, it will give you the names of all
of the application program files in the archive. Next, send
the server another message asking it to send you the files that
you want:
SEND APPLICATIONS SUNCLOCK
You should send the commands to NEWS-ARCHIVE@SUN.COM.
1
Page 8
Commands:
The four server commands:
HELP command: The command HELP (or SEND HELP) causes the
server to send you the help file. No other commands are
honored in a message that asks for help (the server figures
that you had better read the help message before you do
anything else).
INDEX command: If your message contains a line where the first
word is INDEX, the server will send you the top-level index of
the archive contents. If there are other words on the line
beginning with INDEX that match the name of subdirectories,
then the indices for those subdirectories are sent instead of
the top-level index. For example, you can say:
INDEX
or
INDEX APPLICATIONS
or
INDEX DEMOS
You can then send another message to the file server, using a
SEND command (see below) to request the file(s) that you
learned from the response to the INDEX command. INDEX
APPLICATIONS and SEND INDEX APPLICSTIONS mean the same thing.
That is, you can use the SEND command instead of the INDEX
command, if you want, for getting an index.
If your message has an INDEX or a SEND INDEX command, then all
other SEND commands will be ignored. This means that you
cannot get an index and files in the same request. (This is so
index requests can be given high priority.)
SEND command: If your message contains a line where the first
word is SEND, the server will send you the item(s) named on the
rest of the line. To name an item, you must specify its
directory (category) and its name. For example:
SEND DEMOS COLORTABLE
or
SEND APPLICATIONS SUNCLOCK
Once you have named a subdirectory (or category), you can
specify more than one item on the rest of the line. They will
all be retrieved from that category. For example:
SEND DEMOS COLORTABLE SLIDER CLIENT
1
Page 9
Each SEND command can reference only one subdirectory. For
example, if you would like to be sent one demo and one
application, you must use two SEND commands: one beginning SEND
DEMO and the other beginning SEND APPLICATION.
You may put multiple SEND commands in one message to the
server, but the more items you request, the longer it will take
to receive. (See "FAIRNESS" below, for an explanation.) The
number of send commands is limited. If the server must use
uucp mail to send your files, then it cannot send more than
100K bytes in one message. If you ask for more than it can
send, the server will send as much as it can and ignore the
rest.
Notes:
Don't send mail with long lines. If you want to ask for 20
files in one request, you don't need to put all 20 of them in
one "send" command. The file server is quite able to handle
long lines, but before your mail message is received by the
file server it might pass through relay computers that will
choke on long lines.
Fairness:
The file server contains many safeguards to ensure that it is
not monopolized by people asking for large amounts of data.
The mailer is set up so that it will send no more than a fixed
amount of data each day. If the work queue contains more
requests than the day's quota, then the unsent files will not
be processed until the next day. Whenever the mailer is run to
send its day's quota, it sends the shortest requests first.
If you have a request waiting in the work queue and you send in
another request, the new request is added to the old one
(thereby increasing its size) rather than being filed anew.
This prevents you from being able to send in a large number of
small requests as a way of beating the system.
The reason for all of these quotas and limitations is that the
delivery resources are finite, and there are many people who
may like to make use of the archive.
1
Page 10
*********
* * The UTC Name Server
* *
* * by the UTC Name Server Manager
* *
* * University of Tennessee
* *
* * UTSERVER@UTKVM1
*********
UTSERVER@UTKVM1 is a service machine written by the University
of Tennessee Computing Center to provide additional PROFS
services. The main function of UTSERVER is to update an on-
line electronic mail directory, and to perform housekeeping and
cleanup functions associated with this electronic mail
directory.
The University of Tennessee Computing Center electronic mail
directory contains user name, userid, and BITNET node
information for non-student UTCC timesharing accounts. It may
contain additional information, including the user's department
abbreviation and office telephone number.
Users on one of the University of Tennessee Computing Center
BITNET nodes can issue commands (via BITNET) to delete their
entry from the electronic mail directory. All BITNET users can
issue commands to search for entries in the electronic mail
directory.
All BITNET users can search the directory for string arguments
by issuing one of the following commands. From a VM/CMS host,
the command is:
TELL UTSERVER AT UTKVM1 FIND string
From a VMS host, the command is:
SEND UTSERVER@UTKVM1 FIND string
In both of these examples, "string" is the search argument. It
may contain an asterisk as a "wildcard", and is not case
sensitive. The result from the search will be a file which
contains all entries in the directory which contain the search
string. A message which tells the number of matching entries
will be sent to your timesharing userid. If matching entries
are found, the file containing the matching entries will be
returned to your CMS reader or to your JNET receive area.
1
Page 11
If an initial search of the directory does not return the
information you are searching for, enlarging the scope of the
search or changing the search arguments sometimes will return
the results you are searching for. For example, if you search
for "Smith, John", and cannot find John Smith's entry, then
performing two searches, one for "Smith" and one for "John" may
provide the results you are searching for.
*********
* * Headlines
* *
* * Smaller bytes of news, but not unimportant...
* *
* * by Christopher Condon
* *
* * send them to BITLIB@YALEVM
*********
* PolymerP FILELIST: The PolymerP filelist on LISTSERV@HEARN
and LISTSERV@RUTVM1 stores a new Polymer Physics Database. The
Database is intended for information which is of interest for
the polymer physics community, such as email addresses,
projects, software, physical data, meetings, vacancies, etc.
The database is related to the Polymer Physics Discussion list,
an open discussion group dealing with all relevant topics in
polymer physics. You can receive the PolymerP filelist by
sending the following command to LISTSERV@HEARN or
LISTSERV@RUTVM1 via mail or message: INDEX POLYMERP.
* FSFnet: With the distribution of issue 11-3 in mid-August,
the FSFnet electronic fantasy and science fiction magazine will
cease publication due to the graduation of its editor, David A.
Liscomb (CSDAVE@MAINE). FSFnet began publication in December
of 1984 and has produced nearly 50 issues. The magazine
initiated a shared-world writing group called 'the Dargon
Project', and this group will continue to produce Dargon
stories. These stories will be printed in a new magazine,
edited by John White (WHITE@DUVM), which will replace FSFnet.
All readers who are subscribed to FSFnet at the time of 11-3's
distribution will automatically be subscribed to the new
magazine, or subscriptions may be obtained from Mr. White.
Back issues of FSFnet are currently available from
LISTSERV@TCSVM.
1
Page 12
*********
* * New Mailing Lists
* *
* * by Rich Zellich
* *
* * from List-of-Lists
* *
* * ZELLICH@SRI-NIC.ARPA
*********
DISARM-L
DISARM-L provides off-line and on-line discussion (with monthly
logs) on ways to accelerate disarmament. Topics cover
political, peace movement strategy, and military strategy (for
technological discussions try ARMS-D@XX.LCS.MIT.EDU) for
reducing nuclear, conventional, chemical, and biological
weapons and forces. Also reducing destabilizing intervention
in the Third World by the Superpowers. We want a broad
membership (especially Europeans, Asians, Latin Americans) and
lively debate; non expert grass-roots opinions are welcomed.
To subscribe, send the following command to LISTSERV@ALBNYVM1
via mail or message: SUB DISARM-L your_full_name.
Coordinator: Donald Parsons
DFP10@ALBNYVM1
EPID-L
Mailing list for the discussion of current topics in
Epidemiology and Biostatistics.
To subscribe, send the following command to LISTSERV@AQUCDN via
mail or message: SUB EPID-L your_full_name.
Coordinator: Robert C. James
JAMESRC@QUCDN
FWAKE-L
A forum for a broad discussion about James Joyce's FINNEGANS
WAKE. The James Joyce Institute of Ireland's Finnegans Wake
Study Group has been doing their best to get the jokes in
Finnegans Wake for the past decade or so. The Study Group
thinks it is time for such groups to pool their findings.
1
Page 13
There are plans to start a second associated service to share
page-by-page, line-by-line notes to the text of FINNEGANS WAKE
in a fixed format analogous to that of Roland McHugh's
ANNOTATIONS. The Coordinator is working on a program to vet
the mail from such a service.
All requests to be added to or deleted from the mailing list,
or to have files distributed, should be sent to the
Coordinator.
Coordinator: Michael O'Kelly
MOKELLY@IRLEARN
HOMEBREW
The Homebrew Mailing List is primarily for the discussion of
the making and tasting of beer, ale, and mead. Related issues,
such as breweries, books, judging, commercial beers, beer
festivals, etc, are also discussed. Wine-making talk is also
welcome, but non-homeade-wine talk is not.
All requests to be added to or deleted from this list,
problems, questions, etc., should be sent to HOMEBREW-
REQUEST%HPFCMR@HPLABS.HP.COM.
Coordinator: Rob Gardner
RDG%HPFCMR@HPLABS.HP.COM
INFO-CAMAC
Topics relevant to any Computer Automated Measurement And
Control (CAMAC) hardware or software issue are appropriate.
All requests to be added to or deleted from this list,
problems, questions, etc., should be sent to INFO-CAMAC-
REQUEST@KL.SRI.COM.
Coordinator: Richard Steinberger
STEINBERGER@KL.SRI.COM
INFO-PDP11
INFO-PDP11 is an unmoderated mailing list for discussion of any
and all issues relating to Digital's PDP-11 series
minicomputers and their operating systems.
1
Page 14
All requests to be added to or deleted from this list,
problems, questions, etc., should be sent to INFO-
PDP11-REQUEST@SEI.CMU.EDU.
Coordinator: Pat Barron
PDB@SEI.CMU.EDU
iPSC
Mailing list to allow iPSC/1 and iPSC/2 users and systems
administrators from different installations to communicate
easily and directly.
Local aliases for this mailing list are to be handled by the
local systems administrators, since most sites already have
local user mailing lists. What is desired to accomplish is to
link all these iPSC user lists together. The first thing
needed is an administrator list and the user list will
hopefully follow. If you are a system administrator for Intel
Hypercube(s) you are invited to send the following information
to IPSCLIST@TCGOULD.TN.CORNELL.EDU:
- systems, iPSC/1's or iPSC/2's
- administrator's e-mail address OR alias
- institution
- user alias list
- suggestions, opinions, ideas....
PLEASE! Systems Administrators Only.
Coordinator: Dave Fielding
FIELDING@TCGOULD.TN.CORNELL.EDU
MVSTCPIP
A mailing list for discussion of MVS TCP/IP implementations.
To subscribe, send the following command to LISTSERV@USCVM via
mail or message: SUB MVSTCPIP your_full_name.
Coordinator: Deba Patnaik
DEBA@UMDC
NEWSB-L
This list is a forum for discussion of issues related to
college News Bureaus. Expected topics include: common
1
Page 15
controversial campus issues, press releases, general
information exchange, and building a network of contacts among
staff in this field.
To subscribe, send the following command to LISTSERV@BUACCA via
mail or message: SUB NEWSB-L your_full_name.
Coordinator: Kim Billings
K_BILLINGS@UNHH
OZONE
This list is run by a group of researchers of the Italian
National Council (C.N.R.), working at the CNUCE Institute, to
awaken sensitivity of people working in the scientific
institutions about the extremely serious problem of the
pollution in the world. We believe the hole in the ozone, the
"hot-house effect", acid rains, and toxic waste are disasters
provoked by man by using Nature as a "never-ending" resource.
Everybody can verify other effects of the pollution, in the
cities, in the seas, in the rivers, etc. We think that the
scientific community must create an opinion movement able to
force some decisions at political level.
To subscribe, send the following command to LISTSERV@ICNUCEVM
via mail or message: SUB OZONE your_full_name.
Coordinator: Erina Ferro
ERINA@ICNUCEVM
PCSUPT-L
A users' group for the discussion of issues that address end-
user support for IBM PC's and similar microcomputers. By
providing a central forum for users worldwide, the group will
foster the timely communication of solutions to problems with
hardware, operating systems, and applications. The group is to
include technical support professionals as well as those who
find themselves in the role of ad hoc "PC expert".
Participants in the group will determine what specific issues
are discussed.
To subscribe, send the following command to LISTSERV@YALEVM via
mail or message: SUB PCSUPT-L your_full_name.
Coordinator: Bob Boyd
RWBOYD@YALEVM
1
Page 16
PSTAT-L
A forum for the exchange of information about the P-STAT data
management and statistics package; code, macros, applications,
user news, user group reports etc.
All requests to be added to or deleted from the mailing list,
or to have files distributed, should be sent to the
Coordinator.
Coordinator: Peter Flynn
CBTS8001%IRUCCVAX
SIMULATOR-USERS
SIMULATOR-BUGS
Mailing list to allow users of the Rochester Connectionist
Simulator to talk to one another.
Please send BUG REPORTS to SIMULATOR-BUGS@CS.ROCHESTER.EDU. We
are interested in fixing bugs, but can't make any promises!
Please make your bug reports as specific as possible.
All requests to be added to or deleted from this list,
problems, questions, etc., should be sent to SIMULATOR-
REQUEST@CS.ROCHESTER.EDU.
Coordinator: Liudvikas Bukys
BUKYS@CS.ROCHESTER.EDU
1
Page 17
*********
* * Feedback
* *
* * a letters column
* *
* * "You PRO, we PRO, we don't go for REPRO!"
* *
* * send your letters to BITLIB@YALEVM
*********
From: Jim Cerny
Subject: David Benson's comment in "Feedback"
I just finished reading the June issue of NETMONTH and, as
usual, found a number of interesting tips and items.
This is a further thought/comment on David Benson's wish (in
the June "Feedback" section) for institution names.
Early-on in our use of BITNET (way back, about a year ago!), we
realized that many node addresses are pretty cryptic. As a
very simple, but very useful, tool for my own use as Inforep
and for our users, we created a VAX/VMS command ("symbol") that
uses the VMS SEARCH utility to find matches to a specified
string in one of the files that lists BITNET nodes. We use
BITNET.LINKS. This saves us having to tell people that there
even *is* a VMS SEARCH facility, since the average user is
probably unaware of it. When they give our local command that
enables BITNET use, it automatically defines the symbol
BITSITES for them as
$ BITSITES == "SEARCH our_library:BITNET.LINKS"
So, to follow Benson's example, they could just say
$ BITSITES UA1VM
to see where it is. Or, what we find is more common, people
want to know if a given school has a BITNET node, so then they
might say
$ BITSITES EMORY
to check out Emory University.
A final way that it is useful is in the process of reading
mail. Suppose you read a message and want to reply, but for
some reason it is not clear from the message, where the site
1
Page 18
is. Without leaving VMS mail, they can give the command
Mail> SPAWN BITSITES EMORY
How straightforward it is to find direct equivalents to this on
various IBM and other operating systems, I have no idea, but as
I say, on a VAX/VMS system it is both simple and very useful.
* Editors note: Some IBM nodes have an EXEC known as NODE
which will list information such as an institution's name,
inforep, computer type, and so on. We distribute this with the
BITLIB help system.
c
From: Eric Thomas
Subject: REPRO feature
1. I am not at all sure that the majority of users agree with
Tony d'Angelo. I personally find it a bit irritating to get
interrupted by new mail which is in fact a copy of what I just
sent. I know what I have said, and just have to discard it and
get back to what I was doing. Most people seem to be satisfied
with the present setup.
2. You DO get an acknowledgement that your mailing was
successfully processed, unless you turn the option off of
course. After 2-3 postings, users come to rely on the fact that
LISTSERV works and that, when it says your mail has been
distributed, it has indeed been.
3. Sending you back a copy increases network load, especially
for "digest" type lists.
From: Rodney Elin
Subject: REPRO feature
This is in response to the letter published in Netmonth Volume
2 Number 12, by Tony D'Angelo. In his letter, he discusses the
LISTSERV REPRODUCE option, which is a flag allowing the sender
of a message to a list to receive a copy of his/her submission.
Currently, the overwhelming majority of lists on LISTSERV have
the REPRO option set to "NO", so that the originator does not
receive a copy of the message from the LISTSERV. Mr. D'Angelo
calls for all lists and for future revisions of LISTSERV to
have the default REPRO option be "YES", so that each sender
would receive a copy of his/her posting unless each individual
changed the option, for each list to which he is subscribed.
1
Page 19
I am opposed to his suggestion, and would like to voice my
support of the "status quo". Mr. D'Angelo gives two explicit
reasons for receiving a copy of his postings, the first being
simply "just to see how it looks...Õto seeå if there are any
gross errors in the message." This is unnecessary, as a
writer, using ANY medium and not just electronic mail, should
thoroughly proofread all that he writes before he sends it to
be read, published, or critiqued. Mr. D'Angelo is proposing
that, with the use of the REPRO=YES option, a writer proof his
material AFTER it is published, which is unheard of from any
writer's point of view. As for seeing how something looks, as
long as the LOG option is in effect, which is the default for
almost all mailers, a copy of each mail file sent is saved on
the sender's disk, and immediately, without waiting for the
LISTSERV, can the sender see how his mail looks (though he
should know this before it is sent.)
Mr. D'Angelo also states that the REPRO=YES option is needed to
find out "if and when Õthe postingå got distributed." This
is also not necessary, as LISTSERV additionally supports
several levels of acknowledgement for each user and each list,
including no acknowledgement (SET NOACK),
acknowledgement by interactive messages (SET
MSGACK), and mail acknowledgement (SET ACK), from
each peer of a particular list. Using message or mail
acknowledgment is preferable to a copy of the posting, as it is
a small, concise message, with statistics involving the
distribution volume and time. Message acknowledgement is
faster than a copy, and tells the sender exactly when (and if)
a posting was re-distributed to all subscribers of a list.
What Mr. D'Angelo fails to mention is the impact a global
default of REPRO=YES would have on network load. During the
summer months, the network is relatively fast, due to the fewer
number of users. But beginning in September, more and more
people will use BITNET, meaning a heavier and heavier load,
especially on major links. The fewer files and mail that are
sent through the network, the less load that will be on the
network, and the faster other information can be sent.
In his letter, Mr. D'Angelo explains exactly how an
individual, for whatever reason, can set his individual entry
in a list to REPRO=YES when the default is NO. This is one of
the main reasons for keeping things the way they are. The
default for all lists SHOULD be NO, in the interests of keeping
down network load, but anyone can change this for his own
entry just as simply as he subscribed to the list.
* Editors note: Enough said on this subject. I probably
should have made similar comments when I printed the letter,
1
Page 20
but hindsight is 20/20, no? Also, many of you will be happy to
see that I have given in and will now print the network
addresses of people who send letters to Feedback.
*********
* * NetMonth Policies
* *
* * Everything you ever wanted to know...
* *
* * ...but were afraid to ask.
* *
* * BITLIB@YALEVM
*********
NetMonth is a network service publication distributed free of
charge to students and professionals in Bitnet and other
networks. This magazine and its companion file, BITNET SERVERS,
are the work of the Bitnet Services Library (BSL) staff and
contributors from around the network.
BITNET SERVERS is BITNETs list of servers and services. If you
know of servers not listed in BITNET SERVERS, or if some listed
are no longer available, please contact the NetMonth Editor.
* Subscribing to NetMonth and BITNET SERVERS:
Send the following command to LISTSERV@MARIST by mail or
messgage:
SUBSCRIBE NETMONTH Your_full_name
Internet users may use this method, but must address the mail
to LISTSERV%MARIST.BITNET
* Back issues:
BITNET users may get NetMonth back issues from the file server
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.
1
Page 21
* 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.
* Printing this file: VM users can print this file by using
the "( CC" option of the PRINT command. VAX/VMS users should
RECEIVE NetMonth with a format of FORTRAN. This will allow
page-breaks to be accepted by your printer.
_
__-
__--- The
__----- Bitnet
__------- Services
___________ Library "Because We're Here."
***************************************************************
|
|
