|
|
NetMonth, February 1987
* * * * *
** * ** ** *
* * * * * * * * * * *
* * * ***** ******* * * * ***** ****** ******* ******
* * * * * * * * * * * * * * *
* * * ******* * * * * * * * * * *
* ** * * * * * * * * * * *
* * ****** * * * ***** * * * * *
* *
* The monthly guide to BITNET servers and services *
* *
* Volume 1 Number 8 February 1987 *
* *
*****************************************************************
* *
* Editor: Chris Condon CONDON@YALEVMX *
* Assistant Editor: Steve Sutter SUTTER@YALEVMX *
* NetMonth Staff Supervisor: Gary Moss MOSS@YALEVMX *
* *
*****************************************************************
* *
* *
RRRRRRRR EEEEEEEEE AAA DDDDDDD EEEEEEEEE RRRRRRRR
RRRRRRRRR EEEEEEEEE AA AA DDDDDDDD EEEEEEEEE RRRRRRRRR
RR RR EE AA AA DD DD EE RR RR
RR RR EE AA AA DD DD EE RR RR
RRRRRRRR EEEEEEE AA AA DD DD EEEEEEE RRRRRRRR
RRRRRR EE AAAAAAAAA DD DD EE RRRRRR
RR RR EE AA AA DD DD EE RR RR
RR RR EEEEEEEEE AA AA DDDDDDDD EEEEEEEEE RR RR
RR RR EEEEEEEEE AA AA DDDDDDD EEEEEEEEE RR RR
* *
SSSSSSS UU UU RRRRRRRR VV VV EEEEEEEEE YY YY
SSSSSSSSS UU UU RRRRRRRRR VV VV EEEEEEEEE YY YY
SS SS UU UU RR RR VV VV EE YY YY
SS UU UU RR RR VV VV EE YY YY*
SSSSSSS UU UU RRRRRRRR VV VV EEEEEEE YYY *
* SS UU UU RRRRRR VV VV EE YYY *
SS SS UU UU RR RR VV VV EE YYY *
SSSSSSSSS UUUUUUUUU RR RR VVV EEEEEEEEE YYY *
SSSSSSS UUUUUUU RR RR V EEEEEEEEE YYY *
* *
* IIIIIIIII SSSSSSS SSSSSSS UU UU EEEEEEEEE *
* IIIIIIIII SSSSSSSSS SSSSSSSSS UU UU EEEEEEEEE *
* III SS SS SS SS UU UU EE *
* III SS SS UU UU EE *
* III SSSSSSS SSSSSSS UU UU EEEEEEE *
* III SS SS UU UU EE *
* III SS SS SS SS UU UU EE *
* IIIIIIIII SSSSSSSSS SSSSSSSSS UUUUUUUUU EEEEEEEEE *
* IIIIIIIII SSSSSSS SSSSSSS UUUUUUU EEEEEEEEE *
* *
* *
*****************************************************************
1
************************************************************************
* Contents *
**************************************************************************
Bitnotes ............................................................... 1
The NetMonth Reader Survey ............................................. 2
The Simtel20 Archives .................................................. 6
Listserv's File Server Functions ...................................... 10
Odd Parity ............................................................ 15
The Ethics of Computer Conferencing ................................... 16
Electronic Chain Letters .............................................. 17
New Mailing Lists ..................................................... 18
The CSNET Information Server .......................................... 19
The United States Data Defense Network - Network Information Server ... 21
The Color and Vision Network .......................................... 22
Feedback .............................................................. 23
Policies .............................................................. 26
NetMonth is a network service publication distributed free of charge to
students and professionals in BITNET and other networks. This magazine and
it's companion file, BITNET SERVERS, are the work of the Yale Computer
Center BITNET Services Library (BITLIB) staff. The BITLIB is a local
online help facility designed to inform Yale network users about what
services are available to them through BITNET, and provide instructions
and utilities for their proper use. In publishing NetMonth the BITLIB
staff members hope to share the fruits of their labor with institutions
outside of Yale in order to promote a productive and enjoyable networking
environment for everyone.
BITNET SERVERS is BITNET's most complete and up-to-date list of servers
and services. It is sent to NetMonth subscribers at the same time as the
magazine. BITNET SERVERS is dependent on your support to remain accurate.
If you know of servers and services not listed in BITNET SERVERS, or of
those listed in the file that are no longer available, please contact the
NetMonth staff at BITLIB@YALEVMX.
Subscribing to NetMonth and BITNET SERVERS: Send a mail message with your
name and network address (userid@node) to BITLIB@YALEVMX (Arpanet users
send your mail to BITLIB%YALEVMX.BITNET@WISCVM.WISC.EDU). A subscription
to NetMonth is also brings you BITNET SERVERS. You do not need to request
both. In order that we may maintain the most efficient mailing list
possible we ask that you inform us prior to the expiration of your userid.
Article submissions and Letters to the Editor are both accepted and
encouraged. See the "NetMonth Policies" section at the end of this
magazine for more information.
Printing this file: VM users may print this file by first copying or
renaming the file to NETMONTH LISTING and then printing the resulting file
using your local file printing command. In this way page breaks and other
formatting will be recognized by your printer.
--------------------------------------------------------------------------
FuzzyBytes Electronic Publishing "Because We're Here."
1
Page 1
*************************************************************************
* Bitnotes Issue 7 *
***************************************************************************
Well, let me say this about that...
A small celebration is in order. The NetMonth/BITNET SERVERS mailing list
has reached (actually, exceeded) the 500-subscriber milestone. This is
a significant number, not only because it is so large, but because there
are now twice as many readers as there were when the first issue of
NetMonth hit the newstands only eight months ago. The reaction from the
staff ranged from astonishment to extreme glee.
The general consensus: "It looks like we're doing something right."
The letters and comments in the subscription requests seem to support this
opinion. I certainly have no objection to people saying nice things about
the staff, the magazine, or my taste in cover art. (On the contrary, I am
known to thrive on that sort of thing). Some of you will remember, however,
that I feel terribly cheated when I receive little creative input from the
readers. How could the magazine be better? What would you like to see?
Are we doing anything that annoys you? What should we emphasize? What
aren't we emphasizing enough?
Yes, it is time once again for a Reader Survey. Those of you who are on the
mailing list for NetMonth will be receiving the file NETMONTH SURVEY along
with BITNET SERVERS and this issue. This should make it terribly easy for
you to answer the questions by editing the file. The completed survey
should be sent to BITLIB@YALEVMX (by mail is possible). For those of you
who are not on the mailing list for NetMonth, the survey appears in this
issue.
The directions this magazine takes in the future are directly dependant
upon your answers. Most of the questions on the survey are multiple
choice, but the most important questions are those where you are asked to
give your opinion. There are also a number of questions about which BITNET
servers and services you use most often.
Blurring identities...
A file server is a file server, unless of course, it is also a name server.
Then it is niether, or both. Many of our file servers have taken on the
duties of name servers, notably NETSERV. The name "file server" doesn't
exactly do it justice, and "name server" doesn't even come close. Somehow
we get by and list it separately under both categories. This sort of thing
is so commonplace that we don't even notice anything odd about it.
1
Page 2
A list server is a list server, unless of course, it is also a file server.
Then it is... strange. Yes, LISTSERV now runs as a file server, with a
command set that you couldn't tell from NETSERV's unless you looked
closely. This added utility will allow members of mailing lists to easily
access list archives. List maintainers will be able to make various files
available to subscribers. Everybody will be happy. See the article on
Listserv's file server functions in this issue.
Thanks where thanks is due...
Thanks to those people who contributed articles for this month's issue:
John R. Cook sent in some suprising results from his Relay Ethics survey.
(Well, they suprised ME, anyway.) Eric Thomas contributed the information
on Listserv's file server functions, and Peter Kaiser wrote about the Color
and Vision Network. Finally, thanks to Steve Middlebrook for informing me
about the SIMTEL20 ARCHIVE-REQUEST and how I could get instructions on how
to use it.
Virtually,
Chris Condon@YaleVMX
*************************************************************************
* The NetMonth Reader Survey *
***************************************************************************
Please return your survey responses to BITLIB@YALEVMX via mail if possible.
All answers will be kept confidential. Thank you for your time...
*************************
* Part One - Who are you? *
***************************
Answer
column
+----+
] ] 1. How long have you been reading NetMonth?
+----+
a. 1-2 months
b. 3-4 months
d. 5-8 months
e. I was a Bitlist reader
1
Page 3
+----+
] ] 2. Are you a(n):
+----+
a. undergraduate student >>>Please specify major:
b. graduate student >>>Please specify degree:
c. computer center staff >>>Please specify:
d. educator (doctor, professor, teacher, etc.)
e. other >>>Please specify:
+----+
] ] 3. How old are you?
+----+
a. 18-25
b. 26-35
c. 36-50
d. 51+
e. none of your business!
+----+
] ] 4. Are you:
+----+
a. male
b. female
+----+
] ] 5. Do you read any electronic magazines other than NetMonth?
+----+
a. yes
b. no
If "yes", which ones:
+-------------------------------------------------------------+
] ]
] ]
] ]
+-------------------------------------------------------------+
+----+
] ] 6. Do you subscribe to any digests/mailing lists?
+----+
a. yes
b. no
If "yes", which ones:
+-------------------------------------------------------------+
] ]
] ]
] ]
] ]
+-------------------------------------------------------------+
1
Page 4
+----+
] ] 7. How often do you sign on to RELAY?
+----+
a. almost every day
b. a few times a week
c. a few times a month
d. not more than once a month
e. never
+----+
] ] 8. Have you ever used a file server before?
+----+
a. yes
b. no
If "yes", which three do you use most often?
+-------------------------------------------------------------+
] ]
] ]
] ]
] ]
+-------------------------------------------------------------+
+----+
] ] 9. Have you registered yourself on a name server (for example, the
+----+ NETSERV User Database or the CSNEWS Bitnauts List)?
a. yes
b. no
If "yes", which ones?
+-------------------------------------------------------------+
] ]
] ]
] ]
] ]
] ]
+-------------------------------------------------------------+
10. What operating system is your mainframe running?
+-------------------------------------------------------------+
] ]
+-------------------------------------------------------------+
1
Page 5
*********************
* Part two - NetMonth *
***********************
11. What do you feel are NetMonth's strong points? (Use more space if you
need it.)
+--------------------------------------------------------------------+
] ]
] ]
] ]
] ]
+--------------------------------------------------------------------+
12. What do you feel are NetMonth's weak points? (Use more space if you
need it.)
+--------------------------------------------------------------------+
] ]
] ]
] ]
] ]
+--------------------------------------------------------------------+
13. In what ways do you feel NetMonth could be improved? (Use more space
if you need it.)
+--------------------------------------------------------------------+
] ]
] ]
] ]
] ]
+--------------------------------------------------------------------+
14. What would you like to see in future issues? What kind of ideas do you
have? (Use more space if you need it.)
+--------------------------------------------------------------------+
] ]
] ]
] ]
] ]
] ]
] ]
] ]
+--------------------------------------------------------------------+
1
Page 6
+----+
] ] 15. The best issue of NetMonth so far was:
+----+
a. July 1986
b. August 1986
c. September 1986
d. October 1986
e. November 1986
f. December 1986 - January 1987
g. February 1987
h. No opinion
Why?
+-------------------------------------------------------------+
] ]
] ]
] ]
] ]
+-------------------------------------------------------------+
16. What stand out in your mind as the best and worst things you ever
read in NetMonth?
+--------------------------------------------------------------------+
] ]
] ]
] ]
] ]
+--------------------------------------------------------------------+
*************************************************************************
* The SIMTEL20 Archives *
***************************************************************************
There is a collossal amount of free public domain software for the CP/M,
PCDOS/MSDOS and UNIX operating systems, and for the DoD standard
programming language, Ada, in several archives on SIMTEL20.ARPA, a
DECsystem-20 running the TOPS-20 operating system at White Sands Missile
Range.
To obtain a directory listing of interest to you, send your request to
ARCHIVE-REQUEST@SIMTEL20.ARPA with up to five of the following commands
in the body of any one message:
SEND PD:CPM.CRCLST
SEND PD:CPMUG.CRCLST
1
Page 7
SEND PD:SIGM.CRCLST
SEND PD:PC-BLUE.CRCLST
SEND PD:MSDOS.CRCLST
SEND PD:UNIX.CRCLST
SEND PD:ADA.CRCLST
SEND PD:MISC.CRCLST
The PD: archive is the one to watch for the very latest CP/M
offerings, as it is updated frequently. The PD:, PD: and
PD: archives contain software distributed by the CP/M Users Group,
the SIG/M Users Group and the PC-Blue Users Group respectively. This
software is available on diskettes from the associated users groups, and
the archives are updated as new volumes are issued.
The PD: archive contains software for the IBM-PC and similar
machines. Some runs under CP/M, and some under PCDOS/MSDOS. The
PD: archive also contains software for the MSDOS and PCDOS operating
systems; but this archive is locally managed, and therefore is updated more
frequently than the PD: archive.
The PD: archive contains a variety of UNIX tools. Those which apply
specifically to CP/M are in the directory PD:.
The PD: archive is growing rapidly. Information about this archive is
in directory PD:.
In general, the archived software is very good, having been worked-over and
refined by many users. The documentation and comments tend to be complete
and informative. Files in all of these archives can be obtained using the
ARCHIVE-REQUEST procedures described in this article.
************
* Disclaimer *
**************
Please note that due to the large number of files available, the archive
maintainers cannot possibly attempt to validate the proper operation of the
various programs. When a program bug is reported, immediate action is taken
to either correct the error or remove the offending program from the
archives. Still, users must understand that all archive programs are
offered AS-IS, and the archive maintainers specifically disclaim any
liability should these programs malfunction or cause damage, incidental or
otherwise. When testing ANY new software, be certain that all information
stored on disk is backed-up before you start, so that you can recover if
files are damaged or erased. This is particularly true if you have a hard
disk, in which case malfunctions can be spectacularly disasterous.
1
Page 8
****************************
* How to use ARCHIVE-REQUEST *
******************************
To obtain up to five files in a single request message by netmail from the
public domain archives kept on SIMTEL20.ARPA, send a message to:
ARCHIVE-REQUEST@SIMTEL20.ARPA
The message body must contain lines beginning with the keyword SEND, one
SEND line for each file requested. Case is not significant. The general
syntax of a SEND line is:
SEND format filename
In general, a filename consists of the following components:
device:file.type.generation
"device:" is usually PD:, and the combination of PD: is expected
unless an alias has been advertised of the form "alias:", which takes the
place of both device and directory fields. The generation field should be
left off in order to default to the highest generation number so you can be
sure of getting the latest version of the file requested. "file.type"
follows the usual filenaming conventions.
In all formats listed below, if the file to be sent is larger than 55K, the
file is sent in numbered parts. The parts must be reassembled in order and
edited to remove any headers, preface, and trailers before the process can
be reversed to reconstruct the original file.
Allowable formats are:
SEND HELP
Much like what you are reading now.
SEND INFO
A detailed description of the SIMTEL20 Archives, which includes this
file, pointers to certain key files, and descriptions of various file
transfer programs and related utilities.
SEND BOOTSTRAP
A brief quick reference listing of filenames of the key utilities
used to reconstruct files sent by the compression and encoding
techniques listed below.
1
Page 9
SEND DIR filespec
This format returns a CRC list of the requested files, and is the
only format which allows wildcard filenames (but not wildcard
directory names). The list is sent as an ASCII text file. The
wildcard characters are "*" and "%". The asterisk means any number
of characters, while the percent sign means exactly one character.
Either or both may appear in any combination in either or both the
file or type fields, while only the asterisk may appear in the
generation field.
SEND RAW filename
If the file is ASCII, it is sent as-is, regardless of size. This
format is the least efficient over network and mail gateway
resources. Use this format only if you absolutely must.
With the four formats listed below, if the file is ASCII and under 25k
characters, it is sent as-is, as if RAW format was requested. Binary files
are always processed according to the requested format. However, a request
for ARC or SQ processing of files with type ".ARC", ".LBR", or ".%Q%" is
ignored and the original file is either uuencoded or hexified (if
possible), according to the requested format. If the file was not sent RAW,
a short preface is inserted at the front of the message describing the
process actually taken and a CRC entry describing the original file.
SEND ARE filename or SEND filename
The original file is made into a uuencoded ARC file.
SEND ARH filename
The original file is made into a hexified ARC file if the ARC file is
under 64K bytes long. Otherwise, an apology is returned instead of
the requested file.
SEND SQE filename
The original file is made into a uuencoded SQueezed file.
SEND SQH filename
The original file is made into a hexified SQueezed file if the
Squeezed file is under 64K bytes long. Otherwise, an apology is
returned instead of the requested file.
* * *
* * * * * *
* * *
1
Page 10
*************************************************************************
* LISTSERV's File Server Functions *
***************************************************************************
by Eric Thomas ERIC @ FRECP11
**************
* Introduction *
****************
Although the primary function of LISTSERV is to distribute mail and files
to pre-defined distribution lists, it may often be desired to provide
the subscribers of the list with a set or data or program files to be
periodically maintained by a particular person or set of persons. Apart
from the obvious example of list "notebooks" (archives), working groups
might want to provide minutes of internal meetings held by some of the
subscribers, technical groups might want to share application programs
and/or mods to a program they are all using, etc.
It was decided that the more convenient way of meeting these needs
was to provide basic, non-specialized file-server functions along with the
mail-processing functions of LISTSERV. Those functions would have to
provide powerful yet list-based file access control and remote file
updating facilities, under the control of both the list owner and the
LISTSERV management. Automatic distribution of updated material to
subscribers was another major goal since it makes this distribution
more efficient whenever several peers are created to support the list
and relieves the file maintainer of the burden of preparing the list of
subscribers -- it is the users that request such distribution from the
server without any intervention from the file maintainer.
It was decided that LISTSERV should conform to the well-implemented
and well-accepted standard command set of the Netserv file-server
developed by Berthold Pasch (PASCH@DHDIBM1) for EARN. Commands should be
similar enough not to confuse unexperienced users who switch from
one of the servers to the other, with additional commands or parameters
being provided if needed. All the commands would not be supported of
course. The LISTSERV commands should conform to the general LISTSERV
convention whenever there is a conflict between LISTSERV and NETSERV
conventions, the best solution being of course to support both conventions
to allow for application programs written for NETSERV to operate with
LISTSERV with a minimal amount of changes.
A presentation of the set of commands that were retained will follow.
You should note that a significant number of these commands have the
same syntax for LISTSERV and NETSERV and yet operate very differently
on the two servers (the best example being the PW command).
1
Page 11
***********
* FILELISTs *
*************
Several "file directories" (FILELISTs) were required to allow each list
to have its own set of files, independently from each other, and to make
it possible to hide the very existence of those files from those users
who are not supposed to retrieve them. LISTSERV maintains a number of
FILELISTs which can be nested in each other if needed. The "root" filelist
is called LISTSERV FILELIST and is always maintained by the LISTSERV
management. In UNIX terms, a FILELIST is a "directory" which can contain
sub-directories (any level of nesting is allowed) and is defined upwards
in the tree structure with the root being LISTSERV FILELIST.
To review the contents of a filelist, you can either request it to be sent
to you by means of the usual "GET" command (see below) or use the special
command "INDEX":
INDex
Sends you the specified filelist (defaults to LISTSERV FILELIST). This
command is strictly equivalent to "GET filelist_name FILELIST" and has
been made available for compatibility with other file servers on the
network.
LISTSERV filelists are nearly fully compatible with the ones you may
obtain from Netserv. The header of the filelist will give information
about the contents of the filelist and a list of File Access Codes
(FACs) which will be used later in the body of the filelist and identify
who will be able to retrieve or store the file in the server. This
FAC list is included between "banners" made of an asterisk, a blank and
a full line of colons, and will usually have been commented by the
maintainer of the filelist to help you understand to whom the FACs
refer.
The body of the filelist will contain file declaration, possibly
interspersed with comment lines. Comment lines start with an asterisk
in column one. The format of the other lines is as follows (column numbers
are given for easier reference by application programmers):
1 3 12 23 26 31 35 41 47 56 65
] ] ] ] ] ] ] ] ] ] ]
V V V V V V V V V V V
filename filetype get put rfm lrecl nrecs date time description
SAMPLE FILE ALL CTL VP 106 85 86/11/12 19:50:14 Dummy file
filename is the 'name' of the file to be used in the "GET" command.
filetype is the 'type' of the file to be used in the "GET" command.
1
Page 12
get is the FAC that controls read access to the file. That is,
people who do not "meet" that FAC will not be able to issue
GET commands for the file.
put if the FAC that controls write access to the file. Usually
points to the file maintainers.
rfm is the record-format of the file. The first letter is either
"V" for "Variable length" or "F" for "Fixed length records",
while the second letter will be set to "P" for "Packed
format files" or left blank for normal files. Note that
packed files will be automatically unpacked prior to being
sent to you as a result of a GET or Automatic File Distribu-
tion command; however if you obtain a direct link to the
disk on which they are stored, you will find them to be in
packed format.
nrecs is the number of records in the file. Files flagged with
nrecs = 0 and dots in the other fields are not yet available
but can be subscribed to or stored by their maintainer.
date/time is the date the file was last updated, in yy/mm/dd format
(this makes it easier to sort the filelist by date). Note
that the process of updating the "date" field in a filelist
causes this filelist to be flagged as changed and the corres
ponding date/time in its entry up the tree structure to be
modified accordingly.
********************
* Ordering the files *
**********************
GET fn ft
Sends you the requested file provided you are authorized to retrieve it.
Synonyms have been defined for the GETND, GETDD, GETPP and GET80 commands
of Netserv. "GETND xxxx" is translated to "GET xxxx F=Netdata", etc. Note
that in this implementation, GETPP and GET80 are strictly equivalents and
will cause the file to be sent in Listserv-Punch format if its logical
record length is greater than 80. Send an "Info LPUNch" command to LISTSERV
for more information about Listserv-Punch format.
You can use the GET command, or its synonym SENDME, to request a file to be
sent to you. You must specify the filename and filetype of the file as
their appear in the filelist, and you may optionally append a third
parameter to the command to indicate from which filelist you want the
search for the file to start. This parameter is normally not required
1
Page 13
unless there is more than one file available from LISTSERV with the
"filename filetype" you are requesting. Application programs who issue
GET commands to LISTSERV and know the filelist name should specify it
since it speeds up the filelist search. The default is to start at the
root filelist, of course.
The LISTSERV-standard "file-format" keyword ("F=fformat") is supported on
this command. Additionally, synonyms have been defined for the Netserv
GETxx commands. Note that the Netserv "GET80" format is not supported by
LISTSERV; LISTSERV-punch format is substituted.
The LISTSERV "GET" command is compatible with the NETSERV one, with
the exception of the GET80 format restriction and with the addition
of the optional file-format keyword and filelist_name parameters. The
"prologtext" feature of NETSERV is not implemented in the LISTSERV GET
command.
**********
* Packages *
************
The term "package" refers to a set of program or data files which are
supposed to be retrieved together under normal conditions. Provision has
been made to allow for users to retrieve those packages with a single
command, and to subscribe to it as a whole with updated versions of only
the individual changed files being sent out. The package exists
independently of its individual components which can still be referenced
separately.
With each package is associated a dummy file and a definition file. The
dummy file has a fileid of "packagename PACKAGE" and does not really exist.
However, ordering this dummy file will cause the whole set of files to be
sent to you. Similarly, subscribing to this single dummy file will result
in a global subscription for all the components of the package. The dummy
file should be used whenever reference is made to the package as a whole.
The definition file has a fileid of "packagename $PACKAGE" and lists
the set of files that are contained in the package. Unlike the dummy
file, it really exists and can be retrieved as any other normal file.
It will usually list itself as first file of the package so that you
can check you have received all the files in the package after ordering
it. It may reference another package which is required for the package
to be used (any level of nesting is allowed). If you subscribe to a
package via Automatic File Distribution (qqv), you will automatically
receive updated versions of all the corresponding sub-packages if they
are updated. Similarly, ordering the package will cause all subpackages
to be sent to you alike.
1
Page 14
***********
* Notebooks *
*************
LISTSERV is able to automatically keep notebooks for a list if desired by
the list owner. Those notebooks are listed in a special filelist called
"NOTEBOOK FILELIST", which is automatically maintained by the server
according to the parameters specified in the headers of the various
lists. The filelist can be subscribed to via FUI (see LISTAFD MEMO for more
information) but AFD distribution has been locked out to avoid generating
too much traffic as this filelist is very likely to be updated every day
and to be quite large. It can be obtained via the normal GET command.
The files listed in the NOTEBOOK filelist are just like normal files and
can be retrieved as indicated by the GET File Access Code. They can
be subscribed to as normal files, and can even be modified or deleted by
the list owners, as indicated by the PUT FAC. However, once the files
are deleted they will disappear permanently from the filelist (unlike
normal files which would be forced to nrecs = 0).
*********************
* Other documentation *
***********************
More information about the Automatic File Distribution feature can be
obtained from LISTAFD MEMO ("Info AFD"). File owners should retrieve
LISTFOWN MEMO ("Info FILEOwner") for more information on the PUT command
and internal filelist format. A complete description of the Listserv-PUNCH
format (with sample PASCAL conversion program) can be found in LISTLPUN
MEMO ("Info LPUNch").
Information about Netserv can be obtained by retrieving NETSERV HELPFILE
or NETSERV REFCARD from the nearest Netserv host.
. + .
* You aren't here . + .
. + ] *. * + .
* * . ] . + . * ..
. + V * . . .
. . . . + . +
. . * *
+ + *
. .
1
Page 15
*************************************************************************
* Odd Parity *
***************************************************************************
Here is the first of many monthly columns by our own Assistant Ediitor,
Steve Sutter. We are calling this Odd Parity because, well, it was the only
title we could think of at the time. Luckily the title works, since this
is rather odd (and you can figure out the Parity bit for yourself). We are
rather lucky to have Steve on our staff, partly because he is not yet what
you would call a network guru. He is, to put it bluntly, a typical BITNET
user. How long this will last, I don't know. One can't work on this
magazine and not learn something eventually. In the meantime, enjoy this
perspective while you can: - Chris
by Steve Sutter SUTTER@YALEVMX
Just recently I was looking over the list of nodes connected to Bitnet. I
hadn't looked at it in about a year, and was surprised to see how much it
has grown. The geographical implications of the list are impressive. I
have tried to come up with a few ideas on how this fact can be used.
My first idea would be some form of a file server for information
concerning travel. I imagine that many people end up traveling to other
universities quite frequently. I think it would be very helpful to have a
file for each site describing how to get there, where the train and bus
stations are, what roads to avoid, and possibly where to stay and eat. A
little more ambitious would be a description of the area. I find it
aggrevating to see a node name and not have any idea where it is, or what
it is like there. I think this would be especially interesting for more
distant nodes, and would help to "beautify" the net in general. Although
it would take some constant effort, a list of local events would be nice,
and while I'm at it how about car pooling information. Incidently, if
every site would clean out a basement somewhere and open it up as a youth
hostel sort of thing, reservations could be made over the net. Well, maybe
I am getting over-ambitious.
Another less practical idea would be a newspaper of sorts. This would
require a great deal of effort, but it would be sort of like a static
relay. It would be nice to see some articles about student life, research
accomplishments, and even local news of interest. If enough people
responded, it might be possible to come up with weather predictions! Well,
anyway I think it would make a good magazine, the Net Community Gazette.
Who knows, with enough local input it might even scoop some of the hardcopy
newspapers. Maybe it would make a good NetMonth spinoff...
Finally, I think the Net itself would be a good place to do research, a
virtual laboratory of sorts. I would suggest maybe a digest for the
posting of surveys. This would probably have to moderated, but hopefully
not too seriously. I think that if the results were also posted, people
1
Page 16
would actually bother to do some of the surveys, especially if they were
brief. The only problem is that the survey group wouldn't change much.
After all, even a great magazine like NetMonth has less than a thousand
subscribers.
Well, I will stop rambling now. If any of these ideas already exist, let
me know. If you find them offensive and/or stupid, I apologize.
Otherwise, think about it, and I will look for the results.
*************************************************************************
* The Ethics of Computer Conferencing *
***************************************************************************
By John R. Cook UD118169 @ NDSUVM1
The objectives of the present study were twofold. First, an attempt was
made to assess the extent to which some traditional moral principles
governing face-to-face communication have gained acceptance by the users of
computer conferences. This was done by assessing the prevailing community
standards for computer conferencing on Compuserve's CB and on BITNET's
Relay. The assessment was carried out using email and other message
facilities on both of these networks to distribute a 24-item questionnaire
entitled Questionnaire for Users of "CB's" and Other Computer "Chats". The
second objective of the study was to explore some approaches that might be
taken towards distributing questionnaires and collecting data over computer
networks.
The 25 CB and 112 Relay users participating in the study tended to be
male, undergraduate students in their mid-twenties and their average level
of education was that of a college sophomore. Six of the CB users also
turned out to be Relay users. In terms of their use of electronic journal
and mail services, the largest portion of Relay users (21%) were Psychnet
subscribers, followed by NetMonth (17%) and COMSERVE (16%).
CB users were found to be much more reluctant to participate in the
study than Relay users, as evidenced by their lower response rate. Also,
Relay users were found to be more accepting of a proposed rule requiring
users to register their true names and identities before signing onto the
system. Otherwise, there was a high degree of similarity in the responses
of CB and Relay users on this survey.
The moral or ethical standards for computer conferencing revealed by
the survey were found to be largely consistent with the moral principles
governing face-to-face communication. One difference between computer-
mediated and face-to-face communication was suggested by the conference
users' greater acceptance of practices such as adopting nicknames that are
considered sexually provocative or sharing details of one's intimate
personal relationships on a public channel. However, when CB and Relay
1
Page 17
users were asked to evaluate the potential benefits of computer
conferencing, they appeared to discount the importance of some of these
practices, in a way that brought them back in line with traditional moral
principles governing face-toface communication.
In conclusion, it seems we do tend to attach importance to the same
sorts of activities both on- and off-line. In this respect, several
traditional moral principles governing face-toface communication have been
found to be accepted by the users of computer conferences. One area where
discrepancies between our on-and off-line ethical standards do tend to
occur, is in the larger range of behaviors we are willing to consider as
morally acceptable in other conference users.
*************************************************************************
* Electronic Chain Letters *
***************************************************************************
(Extracted from CSNEWS@MAINE)
Recently, the problem of chain letters being distributed by electronic
mail facilities is increasing, and the number of complaints received
about them is mounting. These letters serve no useful or educational
purpose, and are a waste of computer and network resources.
For reference purposes, a "chain letter" is any mail message that
requests or implies that the receiver should re-broadcast the message
to several other users. The phrase "Send a copy of this letter to
20 other people you know" is an example of the type of wording you
will encounter in a chain letter. Quite often, you will receive the
letter from someone you do NOT know.
When you receive a chain letter: when you find that you have received
a chain letter, it is a good idea to forward it to the operations
manager at your computer center. He or she will be able to take
appropriate action, such as contacting the computer center of the
person who originally sent the file.
For those who might think of sending a chain letter: such abuse of
BITNET will not be tolerated by most users and most computer centers.
Chain letters are an annoyance to the user community at large, and
their broadcast and rebroadcast results only in wasted storage space.
If you receive a chain letter, purge it or forward it to your
operations manager -- do NOT rebroadcast it.
CSNEWS action: if it can be shown that a user or group of users has
been involved in the distribution of a chain letter, their access to
CSNEWS facilities will be revoked immediately for an indefinite
period. If one of the CSNEWS staff receives, directly or indirectly,
a copy of a chain letter, he or she may immediately notify the
operations staff at MAINE and at the computer center from which the
letter originated.
1
Page 18
*************************************************************************
* New Mailing Lists *
***************************************************************************
AAI@ALMSA-1.ARPA
Digest for discussion of the Automated AUTODIN Interface system. The AAI
system is a series of programs that interface a data processing
installation (DPI) with an AUTODIN switching center. This digest will
provide information to the user community and other personnel interested in
the developments/enhancements and implementation thereof.
All requests to be added to or deleted from this list, problems, questions,
etc., should be sent to AAIREQ@ALMSA-1.ARPA.
Coordinator: Jo Ann M. Bohnenstiehl
Bob Savacool
ISO@NRTC.NORTHROP.COM
Discussion group focusing on the ISO protocol stack. The list naturally
has some overlap with the ISODE list; contributors are urged to use the
appropriate list based on their topic of discussion.
All requests to be added to or deleted from this list, problems, questions,
etc., should be sent to ISO-Request@NRTC.NORTHROP.COM.
Coordinator: Marshall T. Rose
NeWS-makers@BRILLIG.UMD.EDU
Mailing list for the discussion of NeWS: the Network/extensible Window
System. NeWS, originally called SunDew, was written primarily by James
Gosling, at Sun Microsystems, who is well known for his Unix Emacs. NeWS
is an extensible multitasking window system environment, consisting of a
network based display server that is controlled and programmed in
PostScript, Adobe's page description language. NeWS was designed to be a
portable, device independent window system development platform that runs
on a wide range of hardware, in a distributed heterogeneous environment.
All requests to be added to or deleted from this list, problems, questions,
etc., should be sent to NeWS-makers-request@BRILLIG.UMD.EDU.
Coordinator: don@BRILLIG.UMD.EDU
1
Page 19
TRANSPUTER@TCGOULD.TN.CORNELL.EDU
The Transputer mailing list was created to enhance the communication among
those who are interested in the Transputer and Transputer based systems.
Submissions should be of non-proprietary nature and be concerned with, but
not limited to:
Algorithms
Current development efforts (hardware and software)
INMOS and third party systems (Meiko, FPS, etc.)
Interfaces
Dedicated computational resources
Occam and Non-Occam language development
All requests to be added to or deleted from this list, problems, questions,
etc., should be sent to transputer-request@TCGOULD.TN.CORNELL.EDU.
Coordinator: Andy Pfiffer
*************************************************************************
* The CSNET Information Server *
***************************************************************************
The CSNET Info-Server is an automatic program that delivers information by
electronic mail. To order a document from the Info-Server, send a message
to either 'INFO-SERVER@SH.CS.NET'or INFO-SERVER@CSNET-SH.ARPA. You do not
need a subject field. The text of your message must be in a special
format, such as:
REQUEST: INFO
TOPIC: HELP
TOPIC: ADR-3
REQUEST: END
This request asks for two documents "HELP" and "ADR-3" from the collection
"INFO". Your message must have a "REQUEST" line, and one or more "TOPIC:"
lines to specify one or more documents. The line "REQUEST: END" is
optional; it tells the Info-server to ignore the rest of the message.
To send documents to an address that is different from the address in your
From: field, please include a Reply-to: field in the header of your
message. Do NOT include a Reply-to: or Acknowledge-to: field in the body
of the message -- the Info-Server won't recognize them.
For each request message, the Info-Server generates a receipt message which
includes the list of documents sent, a report of errrors in the request,
and, if a Reply-to: field is used, the address in the From: field of the
request message.
1
Page 20
The document you are now reading can be requested by:
REQUEST: INFO
TOPIC: HELP
There are currently four REQUEST collections: INFO, RFC, SOURCES and
MOD.SOURCES.
REQUEST: INFO CSNET general information documents.
REQUEST: RFC Documents in the "Request for Comments" series
published by the DDN Network Information Center
(NIC).
REQUEST: SOURCES Files of program sources or information about
program sources from CSNET.
REQUEST: MOD.SOURCES An archive collection of public-domain programs from
the "mod.sources" mailing list, distributed by USENET
netnews. These Unix source file have been selected
and tested by the mod.sources moderator. The first
two volumes of the total of six volumes are now
available. Send for the topics HELP and INDEX.
You may specify a limit, in lines or bytes, to the maximum size of document
that you wish to have sent in a single message. For example:
LINE-LIMIT: 1000 or BYTE-LIMIT: 75K
The Info-Server will break the documents at exactly the specified number of
lines, or at the line preceeding the specified number of bytes. The
minimum limit is 250 lines or 19000 bytes. You may use the form "75000" or
"75K" in either limit, but NOT "75,000". The limit affects only lines up
to the next REQUEST: line.
You may combine different requests in the same message, and use any
combination of upper- and lower-case letters in your text. You may also
include or omit spaces and tabs, use any number of REQUEST and TOPIC lines,
and omit "REQUEST: END".
REQUEST : info
byte-limit: 22000
topic: tbl-4a (Byte-limit in effect)
TOPIC: ml-2
Request : rfc
TOPIC : rfc822 (Byte-limit not in effect)
1
Page 21
If you include "REQUEST: END", the Info-Server will ignore whatever follows
in your message. If you include "REQUEST: ATTENTION", the INFO SERVER will
ignore whatever follows and deliver your entire message to "CIC@CSNET-
SH.ARPA". (This conforms to MOSIS; we prefer that you send ordinary
questions directly to "CIC@CSNET-SH.ARPA.)
You are encouraged to suggest additional documents you would like to have
available from the CSNET Info-Server.
*************************************************************************
* The United States Data Defense Network - Network Information Center *
***************************************************************************
This is an automated service provided by the DDN Network Information
Center. It allows access to NIC documents and information via ordinary
electronic mail. This is especially useful for people who do not have
access to the NIC via a direct Internet link, such as BITNET, CSNET
and UUCP sites.
To use the mail service, send a mail message to SERVICE@SRI-NIC.ARPA.
In the SUBJECT field, request the type of service you wish followed by
any needed arguments. The message body is normally ignored. The
information you request will be sent back to you as soon as possible.
The following services are currently available:
HELP This message; a list of current services.
RFC nnn nnn is the RFC number or the word INDEX.
IEN nnn nnn is the IEN number or the word INDEX.
NETINFO xxx xxx is a file name or the word INDEX.
HOST xxx Returns information about host xxx.
WHOIS xxx Returns information about xxx from the WHOIS service.
Use "WHOIS HELP" for information on how to use WHOIS.
Example SUBJECT lines:
HELP
RFC 822
RFC INDEX
NETINFO DOMAIN-TEMPLATE.TXT
HOST SRI-NIC.ARPA
WHOIS MKL
Send comments or suggestions to SUGGESTIONS@SRI-NIC.ARPA.
Send questions and bug reports to NIC@SRI-NIC.ARPA.
BITNET/EARN/NETNORTH users should check to see if the information
is available from one of the NETSERV file servers (eg. NETSERV
at BITNIC) first before requesting information direct from the DDN NIC.
1
Page 22
CSNET users should check to see if the information is available from
the CSNET information server (INFO-SERVER@SH.CS.NET) first before
requesting information direct from the DDN NIC.
*************************************************************************
* The Color and Vision Network *
***************************************************************************
by Peter Kaiser PKAISER@YORKVM1
The Color and Vision Network is for scientists working in color and vision
research. At present the Network has three major activities.
1. Members' E-mail addresses are maintained and sent to all those in the
Network.
2. A key word list that associates scientists and their interests within
the areas of color and vision is maintained and distributed.
3. Any person in the Network can have a bulletin, announcement, atc, sent
all the other people in the Network.
Scientists working in color and/or vision who wish to join should contact
Peter Kaiser at:
CVNET@YORKVM1 or
CVNET%YORKVM1.BITNET@WISCVM.WISC.EDU
They will receive the list of E-mail addresses plus a request to provide
key words which represent their interests and experience in color and/or
vision research.
Scientists from Australia, Canada, Germany, Japan, Netherlands, Sweden
U.K., and the U.S. are in the Network. They come from universities,
research institutes, national laboratories and private industry. The list
is growing daily.
Peter K. Kaiser
York University
4700 Keele St.
North York, Ontario, M3J 1P3
Canada
* * * * * *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * *
1 Page 23
*************************************************************************
* Feedback *
***************************************************************************
Date: Wed, 21-JAN-1987 21:12 PST
From: Don Hosek
To: Christopher Condon
After seeing the recent flood of letters in the January NetMonth, I just
had to throw my hat in the ring. Relay is a valuable but precariously
balanced Bitnet resource. I would suggest that those people who dashed off
letters to NetMonth defending the relay "clone" read some of the back
issues of NetMonth and BitList and learn a little bit about the old style
chat machines and the history of Relay. In the days before Relay, chat
machines were one of the biggest drains on network resources (and mostly so
people could endlessly say "hi.") At an unnamed University I once worked
at, for a user services employee to be caught using a chat machine meant
termination. Period. Even now, relay use is not encouraged at this site (at
least not until they get a Relay of their own, I'm told).
The Relay clone while certainly an excellent exercise in Rexx programming,
was a danger to the status of Relay. In appearance it resembled Relay, and
it certainly was not good public relations for the supporters of Relay who,
I am certain, are often called upon to explain misuses of Relay and
exceptional "loads" on the network from relay use. I might suggest that any
users wishing to learn to use IUCVTRAP or WAKEUP or whatever their heart
desires stay away from writing a program that operates as a chat machine
unless it is *highly* restricted in the nodes that may use it, i.e., only
the host node and possibly those linked directly to the host node.
Certainly, don't endanger the status of legitamite network services with
"dangerous" programs.
-Don Hosek
***************************************************************************
Date: Fri, 23 Jan 1987 10:33 SET
From: Eric Thomas
Subject: Your relay clone
To: Niccolo Avico
cc: Jeffrey R. Kell ,
Christopher Condon
Nico,
I have seen the discussion about the RELAY clone you wrote in NetMonth
and would like comment on your sayings (Chris, you can include this mail
in the next issue of NetMonth if you want).
1
Page 24
First, we have never accused you nor ESC1040 of usurping the name of
RELAY or similar things (just because RELAY is a copyrighted program
does not mean that we're going to "scream like Khomeini" if someone re-
uses the name -- the main reason to use a different name is to make it
clear to users that this is NOT the same program and that complaints/bug
reports must be sent to another userid). Anyway you used a different
name, so there is NO problem about copyright red tape and suchlike.
The main reason why I would like you not to distribute your program
to students any more is a purely TECHNICAL reason: although it is probably
a very interesting REXX experience, and it can help a new REXX user
a lot, a centralized chat machine like your CHATTER is a DANGER to the
network. Please consider the following situation: 10 users from the USA
are signed up to your chat machine at ICNUCEVM. Every time one of the 10
users sends out a message, it gets redistributed to the 9 other people
on the channel. Each of them is, say, about 9 nodes distant from ICNUCEVM
on the average so you get a network load of about 80 messages.link (that
is, the same load as if 80 messages were being sent on a single link).
If the message rate is about 20 messages per minute (that's not
much, I've seen worse), you get a load of 1600 messages.link per
minute imposed on the network. This is with just 10 users, each sending
but TWO messages per minute. With 30 users sending 5 messages per minute,
you get a load of 40,500 messages.link!! This means complete
saturation of the network lines, ie spool files can no longer be
transferred. This does not happen with RELAY since any given message
will cross the lines only once and will get redistributed by the
receiving RELAY (hence the name).
You should know that RELAY has been tolerated by the BITNET
Executive Committee ONLY provided that Joe users be made unable to use
it during peak hours. If you start allowing US students to use a chat
machine during work hours, especially a centralized chat machine on the
other side of the ocean, then you are definitely going against the
Executive Committee's decision.
Now about ESC1040 and "Contact sysops if you see bogus relays!!": you
should know that the majority of bogus relays are run ILLEGALLY by
students who have somehow obtained the exec. A chat machine imposes a high
load on the system it is running on, but also on OTHER systems in the
network. The local system contact is responsible for this before the
BITNET/EARN community and must be able to justify the load. If a chat
machine is causing the network to stop transferring files, HE will get
the blame. I therefore find it perfectly normal that no chat machine
be allowed without the approval of the system operator at the site. If
the sysop has given permission to run the relay and receives a note from
someone saying "There is a bogus relay at your node", he will just reply
"No, it's an officially approved machine" and the problem will be settled.
1
Page 25
You should know that ESC1040 has done a lot more than just write a
chat program. From what I heard he has been abusing his operator
privileges to get accounts to run the chat machines on. From what I SAW,
he sent the authors of RELAY (including me) a note saying that he was
the official system contact person for his node and that his chat machine
was developed in collaboration with a the USSR as part of a secret
project, etc. This was an insult to the official representative of his
node and it is probably the reason why his account was removed,
assuming it was (didn't hear about it). His behaviour on his chat machine
was unacceptable, I heard him criticizing openly the RELAY system and
forcing RELAY users to be signed on his chat machine even though they
wanted to get off.
Last, but not least, let me tell you that it is VERY unpleasant to
receive angry complaints from network users/operators about a problem
that is not caused by YOUR program, but by someone else's. I have been
in this position several times and I can only agree with Jeff when he
says he would like it made clear and obvious that your chat machine is
not his. We have no objection to you chat program provided you respect
the network (ie limit it's service area to nodes which are very near to
your site, which was not the case with the machines ran by ESC1040), and
you make it clear that this is a different program (which is your
interest as an author anyway).
With kind regards,
Eric
***************************************************************************
Date: Fri, 23 Jan 87 08:46:51 EST
From: Jeffrey R Kell
Subject: Re: Your relay clone
To: Eric Thomas ,
Niccolo Avico
cc: Christopher Condon
In-Reply-To: Message of Fri, 23 Jan 1987 10:33 SET from
Just to summarize briefly a lengthy note I sent to Chris (I thought this
was all over, but didn't get a CC: of Niccolo's last letter)...
The primary concerns of mine were, as Eric mentioned, (1) confusion with
the real relay, leading to complaints to me and (2) misuse of the EXEC
which would lead to executive committee action and/or network trouble.
The bottom line of all of this is: the danger here is *who* has the EXEC,
not *what* the EXEC is. Even though Relay is somewhat accepted by the
network administration, a copy of Relay can be easily hacked to break the
rules it is designed to enforce (recall 'Psycho' at Waterloo). These
"dark-side hackers" would misuse anything. Perhaps they could, in time,
write their own code; but why give them a head start. And why provide
"would-be-dark-side-hackers" who can't write one of their own with working
code ready to misuse.
1
Page 26
Date: Tue, 27 Jan 87 16:58:27 SET
From: Hermann Schneider
Subject: ESC1040 (RELAY clone)
To: Niccolo Avico
cc: Christopher Condon
Hi, I read the article in NetMonth about our RELAY clone. I am the senior
system programer here responsible for data communication and our EARN
connection. To put things right:
-ESC1040 was never removed from Bitnet
-The RELAY clone was not the only reason to restrict him to use of the
network. The reasons are ipurely in the interest of the Agency.
Therefore I want to ask Nico not to start shouting against something he
doesn't know. Sentences like 'acting histerically like Komeini' are
misplaced here (it is you Nico who acts like this). There is also no reason
to make the Americans responsible for what has happened.
Stay cool and fair!
Hermann
*************************************************************************
* NetMonth Policies *
***************************************************************************
If you have questions or comments about BITNET or NetMonth that you would
like printed here, mail your letter to BITLIB@YALEVMX. Make sure that you
specify in the "Subject:" header or somewhere in the letter that it is for
the NetMonth letters column. This doesn't mean that your letter will be
printed, but it helps. Your opinion counts!
Article Submissions: The only requirements for NetMonth articles are that
they be informative, interesting, and deal with BITNET services (or any
other good BITNET related topics). The editor will inform you of any
changes to your writing and will submit them for your approval, deadlines
permitting. Send your articles to BITLIB@YALEVMX.
---------------------------------------------------------------------------
FuzzyBytes Electronic Publishing "Because We're Here."
|
|
