|

|

NetMonth, December 1986 - January 1987
* * * * *
** * ** ** *
* * * * * * * * * * *
* * * ***** ******* * * * ***** ****** ******* ******
* * * * * * * * * * * * * * *
* * * ******* * * * * * * * * * *
* ** * * * * * * * * * * *
* * ****** * * * ***** * * * * *
* *
* The monthly guide to BITNET servers and services *
* *
* Volume 1 Number 6 - 7 December 1986 - January 1987 *
* *
*****************************************************************
* *
* Editor: Chris Condon CONDON@YALEVMX *
* Assistant Editor: Steve Sutter SUTTER@YALEVMX *
* NetMonth Staff Supervisor: Gary Moss MOSS@YALEVMX *
* *
*****************************************************************
* *
* . + . .. . .* *
* . * + . . *
* "You Are Here" . + . . . . *
* ] . . . . *
* ] . . . +. + . *
* \]/ . . . *
* . . V . . . + . *
* + . . + *
* . * . * . + *
* . . + .+. . *
* . + . . . . . *
* . . . . . . *
* . + + *
* * . .. . . *
* . . . * . . . . *
* . + . . + . . . *
* + +.. . +. *
* . * . . . . *
* . * . + + . + . * . *
* . * * . . * + *
* . . * . + * *
* + * . . .. . . + .* . *
* . . . . * . *
* + + . . * . + . . *
* * + . .. . .. +. *
* + . . . *
* . . . * . + + . *
* *.+ . * . * *
* .. . + . * + . + *
* * . + * *
* *
*****************************************************************
1
************************************************************************
* Contents *
**************************************************************************
Bitnotes ............................................................... 1
Scuttlebut ............................................................. 3
New Mailing Lists ...................................................... 4
The Decentralization of INFO ........................................... 6
Two New UH-INFO Subservers ............................................. 8
The BITNET Executive Committee ......................................... 9
COMSERVE's Name Server Functions ...................................... 10
Plan for Implementation of BITNET Membership Fees ..................... 11
Spotilight Server: BITSERVE@CUNYVM .................................... 12
Feedback .............................................................. 16
NetMonth Policies ..................................................... 20
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 a subsciption to 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 if and when your userid@node will
expire.
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 6 *
***************************************************************************
To start the new year...
During my idle time in the NetMonth offices (yes, there is actually some
idle time) I have a tendency to fiddle with the cover design of the
magazine. The original NetMonth logo lasted through one issue, the new
one was widened, then cover art was added, and so on. All of this is
perfectly harmless and geared toward making you open up the magazine and
read what is inside.
This month however, while the cosmetic changes are more sweeping than
ever, the important change is just below the logo, and just below my
(the Editor's) name... Assistant Editor: Steve Sutter, SUTTER@YALEVMX.
Steve was chosen from a field of talented applicants in a rigorous search
for a BITLIB Assistant Manager. (Any gueses as to who the Manager is?)
Since one of the primary activities of the BITLIB staff is to publish
NetMonth, Steve also fills the position of Assistant Editor. He will
officially begin writing for the magazine next issue (although you will
find a few of his touches in this one.)
While I was adding Steve to the header I thought it would be appropriate
to give credit to Gary Moss, my immediate supervisor. In addition to
keeping an eye on me Gary is a Staff Resource Specialist and technical
writer for Yale Computer Center User Services. He was recently appointed
liason to BITNIC in the new, local support plan. Gary is the person I run
to when I have awful, nagging questions about where the magazine is going
and what should be done with the BITLIB. "Is this okay?", "Do you think I
should really do this?" and so on. The inevitable answer: "You decide.
I trust your judgement." Thanks, Gary.
Meanwhile I have noticed a problem in the last few issues with those
little news items that aren't large enough to justify devoting an article
them, but are important just the same. There is now a new column devoted
to this sort of news. It's name is... "Scuttlebut". Names such as
"Scuttlebits" and "NewsBits" were deemed a bit too tacky. Pun intended.
Network Gurus...
Every BITNET site should have someone who can answer questions about the
network. Every year a whole slew of bright, young, old, and inexperienced
(or simply uninformed) people arrive at universities everywhere with
questions to challenge the most informed networker. Unfortunately, not
every node has an informed networker, at least not in an official
capacity. Many a time the brunt of the question answering falls upon
INFO@BITNIC.
1
Page 2
This, at first, does not seem to be a bad state of affairs. After all,
when everyone asks Judy Molka and Company a question they are guaranteed
a consistent (and correct) answer. The problem arises when EVERYBODY
begins asking INFO a lot of questions, everybody also has to wait a long
time for the answers. Eventually the question-queue grows larger than
can be dealt with realisticly.
BITNIC has made the decision to decentralize information dispersal by
finding an informed networker for each site, and allowing only that
that person to request information from INFO. The average user will be
able to ask the local network guru questions and have them answered quickly
AND correctly. The guru will probobly have BITNIC-supplied standard answers
to common questions (or perhaps he should know the answers, anyway) while
he forwards the real tough ones to Judy. (Who will undoubtedlty have the
answer, or know who to ask).
There is more to this (see the article in this issue: The Decentalization
of INFO), but that is the basic premise. It strikes me as a perfectly
intelligent idea, the RIGHT idea for times. Hindsight tells us that this
should have been done a long time ago. My experience with managing a
local online BITNET help facility tells me that it will work.
A suggestion for those new network gurus: Put any and all useful
information on BITNET in a place on your mainframe where everybody can
read it. Online help files are the second place people will look to for
answers. If they don't find satisfaction there they will come to YOU.
In other words, answer their questions before they ask them.
On, yes. The FIRST place people look to for answers are friends and
experienced networkers. It is your job to make it possible to answer,
"The information you need is probobly on the INFO-BITNET disk," (or
whatever you decide to call it). I believe that BITNIC plans to provide
some automated online facilities to assist you, but I get the impression
that initially you will fend for yourselves somhow.
Before we go any further...
You should know that BITNET USERHELP is now avaialble from any NETSERV file
server. BITNET USERHELP is just what the title implies... help for for new
network users. It explains, briefly, what file servers, name servers,
relays, and other network services listed in BITNET SERVERS are, and how
you can use them. Thanks to Bert Pasch for letting me install that on
NETSERV. To get your copy, send the following command to your nearest
NETSERV, using your local messaging command, or as the first line of a mail
file: SENDME BITNET USERHELP.
1
Page 3
Let's hear it for Eric Thomas and friends...
LISTSERV@BITNIC is now running Eric's revised LISTSERV code. The program
has changed over the past few months, enough so that BITNIC has replaced
their own list server code locally with his (also known as the FRECP11
code). Eric has brough new meaning to the words "software support", and his
contact with the LISTSRV-L mailing list has brought about many improvements
to software that wasn't too shabby to begin with.
Work is also being done by Judy Molka and the LISTSERV people to reduce the
load on the internetwork links. The most popular mailing lists have their
origins in other networks. If, for example, there are 400 people in BITNET
who subscribe to the ARPANET list MICROBE-LOVERS, 400 copies of each letter
must pass through the WISCVM gateway. Using LISTSERV it will be possible
for the mailing list coordinator to send only ONE copy of a letter through
the gateway into BITNET, where it will arrive at a specific list server and
be forwarded to the BITNET list subscribers. Individul BITNET users will
not notice the change, except for a alteration of the mail header, and they
will still send mail to the list coordinator as before.
For example, my subscription the INFO-NETS mailing list now comes from
INFONETS@BITNIC. It was forwarded there from the oringinal ARPA address,
and I will send my messages to INFO-NETS-REQUEST%MIT-OZ@MC.LCS.MIT.EDU,
just like before. Now only one copy of INFO-NETS comes through the gateway,
rather than thousands.
Finally, please excuse the late arrival of this issue of NetMonth. I
decided not to publish in December (there was no news, no one was around
to read it, and I was busy taking finals and doing Christmas shopping).
On with the show!
Chris Condon@YaleVMX
*************************************************************************
* Scuttlebut *
***************************************************************************
* This news just came in from Kent Percival, the NetNorth Administration
Secretary: The file server CANSERVE@CANADA01 has been shut down. It has
been outdated since the implemetation of NETSERV@CANADA01. CANSERVE was
one one of the original early file servers, and as obsolete as it is, we
will be sorry to see it go. I might suggest, however, that the name be
applied to SERVER@UOGUELPH, if only becuase there is a file server at
TAMCBA by the same name. I don't recall which SERVER took the name first,
(and I am not inclined to check) but in my humble opinion CANSERVE sounds
better anyway.
1
Page 4
* Also from Canada: There is a list server, LISTSERV@CANADA01 that has
been around since the early days of LISTSERV@BITNIC. Apparently no
one (including yours truly) noticed until now that it was not included
in BITNET SERVERS. While we are on the subject, there is a new list server
at UTCVM. True to form, the name is LISTSERV.
* Also from up north (at least from the Editor's point of view): In our
last issue we informed you about the new file server UBSERVE@UBVMSA.
James R. Gerland, Postmaster for the State University of New York at
Buffalo, has moved the server from the VAX 11/785 to the 8650 at
UBVMSC. The new server has been modified to allow VMSDUMP transfers
between VMS machines, so binary files can be distributed. There are also
some new commands. For more information:
VMS: SEND UBSERVE@UBVMSC HELP
VM/CMS: TELL UBSERVE AT UBVMSC HELP
UBSERVE is adapted from KERMSRV written by Brian Nelson (BRIAN@UOFT02).
Submissions to UBSERVE are welcome and should be sent to GERLAND@UBVMSC.
* The latest Relay news: Jeff Kell has told us that there is a new Relay
at EB0UB011. According to Dan Littauer REALAY@ISREARN will cease to exist
soon (if it hasn't already). RELAY@TAUNIVM will take over ISREARN's
Relay duties.
* On Wednesday, January 14th, the BITNET Network Information Center
(BITNIC) will be placing all public lists on a FRECP11 style Revised
List Processor, Release 1.5f. The list server machine will be called
LISTSERV@BITNIC. Documentation for using the FRECP11 style list server
is available on NICSERVE@BITNIC under the file id LISTSERV MEMO. Peer
lists will not be in operation on BITNIC until further notice.
* Another new list server: NEWSERV@UNCVM1
*************************************************************************
* New Mailing Lists *
***************************************************************************
CAN-INET@ATHENA.MIT.EDU
Mailing list for anyone interested in the topic of a Canadian internet.
Issues to be addressed are:
o The organization of a domain name space and the delegation of authority
within it;
o The selection of available protocol suites;
1
Page 5
o The design of the subnet and available carriers;
o Internetworking with other countries and private networks;
o Anything else that might be considered relevant.
All requests to be added to or deleted from this list, questions, comments,
etc., should be sent to CAN-INET-REQUEST@ATHENA.MIT.EDU.
Coordinator: Philip Prindeville
COMM-L
Integration of voice, data, and video services on the same network is
creating a need for organizations that specialize in communications. This
BitNet LISTSERV group is for discussion of both technical and non-technical
aspects of providing those services. Topics could include management,
installation, acquisition, or monitoring of communications networks.
If you wish to join the list and you are on a BitNet host running CMS, just
enter the command:
TELL LISTSERV AT UGA SUBscribe COMM-L your_name
Users at VAX/VMS sites using jnet software can enter the command:
SEND LISTSERV@UGA SUBscribe COMM-L your_name
Where your_name is your real name. Non-BitNet/CMS users may subscribe by
sending mail to LISTSERV%UGA.BITNET@WISCVM.WISC.EDU with the subscribe
command as the first line.
Coordinators: Phil Benchoff
Harold Pritchett
DynSys-L@UNCVM1
The Dynamical System is a mailing list for the exchange of information
among people working in ergodic theory and dynamical systems. Almost all
kinds of contributions are welcome, especially:
Abstracts Illuminating comments
Open problems Historical remarks
News items Reviews
Announcements of meetings Conference reports
Address changes Bibliographies
Examples Work planned or in progress
Questions Anecdotes, jokes, puzzles.
1
Page 6
The list will be maintained by a list-server facility called NEWSERV, which
acts as a userid at the BitNet node UNCVM1. To be added to or deleted from
this list, see the following directions, or send a message to one of the
Coordinators.
BitNet users can use the ADD command to add their name to a list:
For users at remote IBM/VM sites the following format is used:
TELL NEWSERV AT UNCVM1 ADD DYNSYS-L userid@node
VAX/VMS sites running jnet version 2 use the ADD command like this:
SEND NEWSERV@UNCVM1 ADD DYNSYS-L userid@node
BitNet users with other environments can contact their local user services
group for assistance. Users without interactive messaging capability, or
non-BitNet users can send a request to ULTIMA@UNCVM1 or to one of the list
Coordinators to have their names added to the list.
Coordinators: Karl Petersen
Doug Lind
NEURON%TI-CSL.CSNET@CSNET-RELAY.ARPA
NEURON Digest; discussions of brain-like networks and computing.
All requests to be added to or deleted from this list, problems, questions,
etc., should be sent to NEURON-REQUEST%TI-CSL.CSNET@CSNET-RELAY.ARPA.
Moderator: Michael T. Gately
*************************************************************************
* The Decentralization of INFO by Daniel Oberst *
***************************************************************************
INFO@BITNIC is temporarily shut down.
The intent is not to discontinue information services, but to make services
available from the BITNET Network Information Center in a manner that will
best serve the network. The plan, as has been suggested, is to move to a
distributed information service, with BITNIC providing support and
assistance directly to information services personnel at member
insitutions, rather than attempting to directly provide these services to
end-users.
1
Page 7
INFO@BITNIC was developed in reponse to a strong need voiced during the
December, 1985 SHARE meeting of the BITNET Technical Sub-Committees. At a
period of rapid growth in the network, a central mailbox provided a point
of contact for suggestions and questions, and proved especially useful for
new sites. We developed a number of strategies for dealing with INFO,
initially passing questions out for response by staff, based on topic and
staff expertise. An automatic acknowledgment function was developed to
allow users submitting questions to know that their questions had been
received. Staff developed on-line standard answers to many of the most
common questions; site and personnel information on member sites were
converted into a SPIRES database which allowed network-wide search and
retrieve access to this information. We developed a central mailing-list
facility, LISTSERV. The INFO account also served as general coordinator of
the LISTSERV lists, and while we have developed self-subscription to these
lists, there remains considerable activity in adding, deleting and
maintaining these lists.
INFO's queue has been building. In spite of continued development of
information files, on-line access to information and facilities, and
publication of procedures, information, and services in Networking News and
the BITINFO database, the number of questions directed to INFO have
continued to mount. The combination of this growth, staff efforts
providing support for the BITNIC display at the EDUCOM Conference,
Thanksgiving holidays, a major effort at solving the ARPANET gateway
problems, and consolidating member information to begin the formal
membership process, have all resulted in the queue growing to its present
size.
The Tuesday before this past BITNET Executive Committee meeting, I met with
the staff to review the status of our activities. I judged work on the
gateway, membership procedures and invoice mailing to be highest priority.
In spite of additional staff efforts put into INFO, the queue was still
growing, and there were increasing complaints about questions not being
answered. I directed the staff to develop a plan to migrate INFO to a
service we could reasonably provide under the following guidelines:
o INFO would be set up to provide prompt response to an authorized set of
reprsentatives from each member (and not to virtually any end-user on the
network).
o General inquiries of the type currently being sent to INFO) would
be reviewed and issues, questions, etc. of a general nature would be
answered in a publically available forum (an "Ann Landers" model).
o Answers to authorized Liaisons would be kept in a publically searchable
database.
o Liaisons would be given information to be used in handling general
inquiries from their institutions.
1
Page 8
o On-line automated facilities to assist end users in identifying their
respective Liasions would be developed.
This conversion will require additional staff effort, and will likely
increase the queue of INFO queries. I thus directed the staff to put the
current questions "on hold" and inform the inquirers of our plans to
provide direct services to an authorized representative structure.
Questions currently in the queue are to be reviewed, urgent ones responded
to, and questions of a general nature are to be answered either in on-line
information or as part of the "Ann Landers" series of Q0 Subsequent
inquiries to INFO are to be informed of our plan and the plan will be
announced as appropriate to lists and on BITNEWS.
The Committee's insistence on efforts directed at the Presidential mailing,
coupled with the urgency of dealing with the impending restrictions on the
ARPANET gateway, along with the need to move ahead with the membership
structure, mailings, and invoicing, precluded any means of directly dealing
with the growing INFO queue and made dealing as quickly as possible with
the situation imperative.
Ira has proposed that the current backlog be processed as quickly as
possible, and that a date be announced for INFO only responding to
authorized representatives. This is consistent with our plan, and a memo
outlining this will be send out pending approval from the Executive
Committee.
Editor's note: This article was taken form a response written by Dan Oberst
to an objection raised by someone on BITNIC's LIAISON mailing list. It
has been reprinted here with no omissions.
*************************************************************************
* Two New UH-INFO Subservers *
***************************************************************************
There are two new subservers of University of Houston's UH-INFO file
server (UH-INFO@UHUPVM1). They are:
ATARINET - University Atari Computer Enthusiasts Subserver
BUGNET - BITNET User's Group Subserver
Valid ATARINET Server command messages are:
ATARINET SENDME filename filetype (to obtain a file)
ATARINET INDEX (to display list of available files)
ATARINET INDEXF (to obtain a list of available files)
ATARINET HELP (to display this message)
1
Page 9
Valid BUGNET Server command messages are:
BUGNET SENDME filename filetype (to obtain a file)
BUGNET INDEX (to display list of available files)
BUGNET INDEXF (to obtain a list of available files)
BUGNET HELP (to display this message)
For example:
TELL UH-INFO AT UHUPVM1 BUGNET INDEX
SEND UH-INFO@UHUPVM1 ASCNSET HELP
UH-INFO also has two other subservers:
ACSNET - Academic Computing Services
PSYCHNET - Psychology
Thanks to Mike Vederman for the information!
*************************************************************************
* The BITNET EXecutive Committee *
***************************************************************************
They've been answering your questions in the last few issues of NetMonth,
but who are they?
Ira Fuchs Princeton University
Ken King Cornell University
Ben Klein City University of New York
Don Laird Pennsylvania State University
Philip Long Yale University
John Porter Boston University
Marty Solomon Ohio State University
Leland Williams Triangle Universities Computation Center
George Yanos University of Illinois at Chicago
Joe Yeaton University of California, Berkeley
John Young Florida Northeast Regional Data Center
BITNIC Representative
Dan Oberst EDUCOM Networking Activities
EARN Representative
David Lord Centre Europeenne Recherche Nucleaire
NetNorth Representative
Kent Percival University of Guelph
1
Page 10
************************************************************************
* COMSERVE's Name Server Functions by Timothy Stephen *
**************************************************************************
As you know, COMSERVE caters to students and professionals interested
in human communication studies. Those who maintain such an interest can
use the commands "ADDME" and "DELETEME" (without the quotes) to add and
delete themselves from the directory. The directory can be searched with
the "Search" command. It can be searched using both simple and complex
logical specifications and searches can be directed to the entire file
or to any of three fields within the directory -- the ADRESSES field
(which lists the user's network address); the NAMES field (which lists
the user's real name); or the INTERESTS field (which lists miscellaneous
information user's wish to associate with their entries). The dollar sign
can be used as an arbitrary or "wild card" character in a search string.
In addition, users can specify that the search result be returned via
punch format as opposed to netdata format which is the default. A simple
search might be specified as follows:
Search /BITLIB/
A more complex variation would be:
Search (asis a /YaleVmX/]/BIT$lib/
The "(asis" specification in this example returns the file in punch
format. The "a" tag indicates that the search should operate on the
ADDRESSES field. The search will be for entries containing either
"yalevmx" or the strings "bit" and "lib" (case doesn't matter) with
anything in between.
All of the functions described above can be accomplished by sending
Comserve interactive messages or by sending the command in mail or in a
file. More information on these user directory functions is available in
the online help file COMSERVE USERGUID which can be retrieved by sending
the following command to COMSERVE@CPICICGE:
Send Comserve Userguid
*
*** *
** * * *
* * * **
* ***
*
1
Page 11
*************************************************************************
* Plan for Implementation of BITNET Membership Fees *
***************************************************************************
by The BITNET Executive Committee December 3, 1986
In order to provide a smooth transition between grant support and
membership fee support of the BITNET Network Information Center, the
following plan is adopted by the Committee:
1. Invoices for membership will be sent as soon as possible after Charter
ratification to existing members and will cover a 6-month membership period
beginning January 1, 1987.
2. Membership fees for current and new BITNET members as of January 1,
1987 will be pro-rated through June 30, 1987.
3. BITNET Members outside of the US (currently in Japan and in Mexico)
are waived through June 30, 1987. NetNorth and EARN will be considered
at the February 1987 meeting of the Executive Committee with regard to
exchange of services and membership arrangements.
4. Membership fee income is to be collected and held by EDUCOM in a
reserve fund on behalf of the BITNET Executive Committee. Funds will
be allocated to pay for activities and services agreed upon by the
Executive Committee, and disposition of any surplus generated will be
decided by the Executive Committee, subject to the terms of the Compact
between the Executive Committee and EDUCOM.
5. On February 1, any current BITNET member institution that has not
paid the membership invoice, will be given 3 months in which to pay or
demonstrate to the Executive Committee a good faith commitment to pay.
During that 3 month period, sites linked to any delinquent institution will
be encouraged to make plans to order any telecommunications lines needed to
compensate for the removal of that institution from the BITNET topology.
No services will be provided to a non-paying institution after the 3 month
period, and the institution's nodes will be removed from the routing table
as soon as practical.
In the case of universities with multiple campuses and university systems:
1. Each institution with a chief executive officer or chief operating
officer with the title of President or Chancellor will be considered as a
separate institution with respect to fee calculation.
2. Institutions with multiple campuses or parts which do not have chief
executive officers or chief operating officers with the title of President
or Chancellor may aggregate the budgets of their parts with respect to
determining BITNET fees.
1
Page 12
3. It is the intent of the Executive Committee that the fee structure not
be interpreted as encouraging aggregations of institutions for the purpose
of reducing the payment of fees.
*************************************************************************
* Spotlight Server: BITSERVE@CUNYVM *
***************************************************************************
Yes, friends, it's still there. NETSERV is running well, NICSERVE is
prospering, but the old girl keeps going anyway. BITSERVE is one of the
original file servers, dating back to pre-BITNIC times. Supposedly it was
going to be shut down once the BITNIC file servers were running at full
speed (almost a year ago). Before the server IS gone I thought we might
take a look at how things used to be:
BITSERVE Valid commands and functions:
* SEARCH *
Command syntax: SEARCH subfile keyword1
SEARCHF subfile keyword1
SEARCH and SEARCHF employ up to eighteen user-supplied keywords to
search files in a VSAM data base. They differ from each other both in
the number of responses they return and in the method which they use to
return responses: SEARCH returns a maximum of ten one-line entries via
network message. SEARCHF sends a file with a maximum of one hundred
entries to your reader. (The file is sent CLASS N and retrieved in the
manner described above for files sent by the SENDME command.) If the
SEARCH command is used and finds over ten matches, ten entries are
returned followed by a message advising you to use the SEARCHF command.
Each entry returned is a one line description of a file which has
keyword(s) matching those used in the search.
You must specify subfile identifier, keywords, and Boolean operators.
Subfile Identifier
Each subfile has a one-letter identifier:
Subfile Identifier
----------------------------- ----------
Index to BITSERVE's CMS Files I
User Directory U
All Subfiles A
1
Page 13
These identifiers can be used alone or, if preceded by an equals sign
(=), in combination. Alternatively, the identifier A can be used with
SEARCH and SEARCHF to indicate that all subfiles are to be searched. If
no identifier is given even when the exec prompts for one, the exec
directs the search to the User Directory.
Keywords
Keywords, at present, can be any two-to-eight alphanumeric characters.
Special characters are only allowed if they are of the following set and
occur after the first character:
/ $ - # & . *
Keywords may be entered in uppercase or lowercase. The period (.) and
the asterisk (*) can be used after the first character to form a
'generic' search. Example: OCCUR* (or OCCUR.) produces a search for the
keywords OCCUR OCCURS OCCURRENCE OCCURRENCES OCCURRED etc. If a keyword
not associated with any of the entries is used in the search, BITSERVE
will respond to that effect. Note: The keyword INDEX produces a list of
entries in the Index to BITSERVE's CMS files, i.e., SEARCH I INDEX.
Boolean Operators
The following characters represent the logical Boolean operators which
can be used with keywords:
] (OR), ^ (NOT), & (AND)
AND is the default. It may also be represented by a blank between
keywords.
Logical operators are evaluated as follows: on the first scan, all
keywords connected by OR operators are joined together; on the second
scan, a left to right pass is made resolving the AND operators; finally,
the NOT keywords are processed. In general, use of the AND operator will
reduce the number of matches, while the OR operator will increase the
number of matches found.
Each keyword and operator must be separated by at least one space.
Examples:
SEARCH =UI NODES ] CUNYVM
search both User Directory and the Index to BITSERVE's CMS files for
entries with the keywords NODES and/or CUNYVM
SEARCH I PEOPLE VM INFO
search the Index for entries which have all three keywords: People,
VM, and Info
1
Page 14
SEARCH A UNIX ^ UTS
search all files for entries with the keyword UNIX but not the
keyword UTS
SEARCH U VM ] CMS ^ TSO
search the User Directory for entries with the keywords VM and/or CMS
but not TSO
SEARCH U VM CMS ^ TSO
same as above except that both VM and CMS must be keywords for the
file
Note, the command: SEARCHF I INDEX
sends a file containing a list of all BITSERVE CMS files to your
reader
* THE BITSERVE USER DIRECTORY *
The User Directory is made up of entries giving brief descriptions of
VM users at each node. At some nodes, such as CUNYVM, each user is
responsible for creating his or her own entry; other nodes create all
entries centrally. The BITSERVE command ADD, documented below, is used
to create an entry. A user may ADD only one entry to this directory. If
a change has to be made to an entry, the BITSERVE command REMOVE must be
used to erase the first version, then the ADD command can be used to
create a replacement.
The entry created consists of a header record (labeled H), one or more
trailer records (labeled T), and a list of keywords (labeled K). The
keywords are taken from specific fields within the trailer records. The
following is an example of an entry in the User Directory:
H U010123 Entry for SMILEY @ CIRCUS added by CONTROL on 07/19/72
T George Smiley (SMILEY @ CIRCUS) 01-000-0007
T Cambridge Circus
T London, England
K GEORGE SMILEY CIRCUS SPY ENGLISH MI5 KGB KARLA SANDMAN CONTROL
K
$EOM
You can search the user directory, for example, SEARCH U keyword(s),
using as keyword(s) the first name, last name, userid, nodename, and/or
entry creation date. If the user has one or two alias userids, these
can also be used for searching.
1
Page 15
* ADD *
The ADD command is used from within a specially formatted file which
will become an entry in the BITSERVE User Directory. The file must have
the following format: the first line is ADD; the second line is H U;
the third line starts with T and is followed by your first name, last
name, VM userid and nodename, and telephone number; the fourth and fifth
lines start with T and contain your mailing address; the sixth line
starts with K and contains keywords (such as your name and userid) by
which others may search for your entry; the seventh line is blank; the
last line is $EOM .
ADD
H
T SHERLOCK HOLMES (SLEUTH @ BSKRVILL) 800 999-999
T 13 BAKER STREET
T LONDON W9
K SHERLOCK HOLMES SLEUTH BSKRVILL BASKERVILLE
$EOM
When you have created the file you can PUNCH it to BITSERVE to be added
to the User Directory. Use the following commands to submit your entry
from a VM/CMS node:
SPool PUNch TO rscsid CLass B
TAg DEV PUNch CUNYVM BITSERVE
PUNch filename filetype filemode
When BITSERVE has updated the User Directory you will receive the
following message:
Entry: Unnnnnn added to User Directory
where Unnnnnn is the permanent data base entry number for the entry you
have just added. Note: If an entry has already been made for your
userid, BITSERVE will reject subsequent submissions and message:
Entry: Unnnnnn already assigned to userid, request aborted
* REMOVE *
Command syntax: REMOVE entry_number
You can use the REMOVE command to delete a VSAM file entry which had
been added by the VM userid to which you are now signed on. You must
specify an entry number on the command. Note that you must enter the
full form of the entry number: Unnnnnn.
1
Page 16
If the entry number was valid, BITSERVE will then message you that your
entry has been successfully deleted from the VSAM data base.
* GET *
Command syntax: GET Unnn
The GET command retrieves a User Directory entry. Unnn identifies the
entry requested. (To find the entry number (nnn) type: SEARCH U keywd.
You must specify an entry identification number. The identification
number of the entry in the data base is always preceded by the one-
letter subfile identifier. If you wish the sent as a file (to your
reader) specify the FILE option. The default is that the information
will be displayed at your terminal. This reader file will be sent
CLASS=N (a class designated for the transmission of files by BITSERVE).
* SENDME *
Command syntax: SENDME fn ft
The SENDME command sends a CMS file from node CUNYVM to your virtual
reader. You must specify the filename and filetype of the file you are
requesting. If you are requesting a file from a CUNYVM user's minidisk,
specify the options (the vmuserid owning the file, the
minidisk address of the file, and the minidisks read password. The
requested file is sent to your reader using CLASS=N (a class designated
for the transmission of files by BITSERVE).
*************************************************************************
* Feedback *
***************************************************************************
Date: Sun, 23 Nov 86 09:32:26 SET
From: Niccolo' Avico
Subject: RELAY clone
To: Chris Condon
Hi. This is a (partial) disclaimer about RELAY program, and some more.
I wrote a Chatter EXEC before this summer. This is because my node doesn't
have any RELAY system, and probably won't for the next time. So, for the
people of Italy who are disconnected from the world during the often EARNET
blackouts I wrote a total new chatter program. In the RELAY header you can
find that reference. Nothing more.
1
Page 17
And now I'd like to set up a discussion with the RELAY mantainers. Who
decided that *no more* chatter programs other than RELAY can be written and
distributed? I can agree with your attack only if you limit that to the
clone's name (but what IBM should do with its Personal Computer?), but
absolutely disagree when you say: "contact systems operators when a clone
RELAY appears". That's a new product, it's author agree that it's a totally
different code, so what's the problem? I don't think that the official
RELAY system network can be "damaged" by a clone software. I think instead
that those kind of programs are *very* useful (when coded in REXX) to teach
people how some tasks are performed in that language. Soon I'll write some
articles on VMCOM about Rexx (I fell in love with it...) and their purpose
will be to enlarge the Rexx community. CHATTER has been for me an exercise
for Rexx: my mind is that the result of exercises like that should be
always exposed to everyone is interested in. The clone RELAY has to be
intended in this way.
That's *just* why both the exec are available from my server. Nothing more.
Regards, Nico.
*Editor's Note* Your reasons are admirable, but the concept is a bit off.
I have NOTHING against a Relay clone... provided it is a clone and works as
a DISTIBUTED CHAT MACHINE. I don't even care if you use the Relay name.
That is for the Relay operators to worry about. But I still stand by the
idea that NON-DISTRIBUTED CHAT MACHINES should be shut down unless their
service areas are restricted. Your Relay clone is not a clone at all,
except for the part that the user sees. Jeff Kell has a bit more lucid
response:
Date: Mon, 24 Nov 86 11:39:34 EST
From: Jeffrey R Kell
Subject: Re: RELAY clones
To: Christpher M. Condon
>And now I'd like to set up a discussion with the RELAY mantainers. Who
>decided that *no more* chatter programs other than RELAY can be written
>and distributed?
That's not the point, and precisely why I said what I did. I am not trying
run the whole show, not after any special recognition, or otherwise. But
the server "looked like Relay" enough for early complaints about its usage
by some people that obtained it to be sent to ME. Some people that have
the exec are summoning (or downright adding on) unsuspecting people and
being bothersome. These people compained to ME, not the proper source.
>I don't think that the official RELAY system network can be "damaged" by
>a clone software.
1
Page 18
If people in the US can use these Relays in Europe at any time, at any
place, without regard to routing, time of day, link loading, or any other
factor, *some* administrator *somewhere* will lower the axe. Bill Rubin of
CUNY was one of the first to inform me of the new Relay execs thinking that
*I* had supplied them wanting to know why it was allowing US users on them.
This is only the beginning of the problems that can happen.
Date: Tue, 25 Nov 86 09:32:26 PST
To: Chris Condon
From: June Genis
Chris,
Reading your comments about "nothing happening" in the latest Net Month
reminds me that perhaps you should do an "In Depth" on the great LISTSERV
controversy some time. Why won't BITNIC use Eric's Server? Are loops a
design or implementation problem in FRECP11 servers? To DISTRIBUTE or not
to DISTRIBUTE. There's been a lot on this last item on LSTSRV-L lately but
I came in on the middle of it so suggest you get the archives (from
ERIC@FRECP11 if they're not all directly available via request, haven't
tried that yet myself). Related to this also is the issue of ARPA digest
distribution in BITNET which in turn brings up the sad state of affairs at
the WISCVM gateway. That, in turn, brings me to ARPA problems which may or
may not be relevant grist for this mill. In the last week an awful lot of
the mail I have sent out via ARPA (we're on both ARPA and BITNET here) has
been bouncing with "HOST UNKNOWN" messages. Interestingly though, mail
sent to the same nodes via the WISCVM gate is getting thru. My best guess
on this at the moment is that WISCVM is still using tables and/or a
different server machine(s) than we are. Will let you know if I make any
reliable discoveries.
/June
(now all you need is a fleet of investigative reporters, right?)
*Editor's Note* Well, it would help. Luckily, by the time this issue goes
to press, some of those issues will be resolved. I didn't print anything
at the time because I didn't feel I had a real grasp of what was going on
(I only skim my LSTSRV-L mail). By the time I did, some of the issues had
been resolved.
*
* * * *
* * * * * * * * * *
* * * * * *
1
Page 19
Date: Sun, 7 Dec 86 13:21 SET
From: Nico - Niccolo' Avico
Subject: ESC1040 (The author of RELAY clone)
To: Chris Condon
Hi. Someone informed me that the account of the author of the Relay clone
has been erased. I already notified you of my mind about this fact. Now you
see he has been removed from Bitnet. I'm really surprised: Americans are
used to say everytime they live in a free country. I see this is not always
true.
A person writes a program that "imitates" a wider used, official Bitnet
product. The code is from his own mind, not copied. What happens? Several
other people, acting isterically like Komeini when we laugh about him,
begins to yell againt that horrible person: it seems to me that RELAY gets
a fanatical fever that closes the mind of people.
Personally I didn't see any problem for a clone program walking on the
links. I already explained this to you. But I'm really afraid by this
policy: we are not allowed of writing our own code: some Big-Brother of
Orwellean memory controls that nothing disturb him. Is this the Soviet
Network? I won't believe it !!
From this affair I see an attack against free software production. Since
now any programmer has to pay attention to the BigBrother susceptibility
and is no more propretary of his programming art. Very good !
I'm a programmer. My first program on Bitnet was a Filter clone. Filter was
written by Andy of CSNEWS, I picked up the idea and wrote a clone that has
some more features. This happened 2 years ago. What has happened to the
Bitnet community since then?
I'd like to see ESC1040@DDAESA10 again on the network. Until now I'll
consider myself in the same condition as him: in fact I don't see any
difference between us. If you believe that we're both in error, I'm
supposed to be closed to Bitnet, too. Otherwise please notify to the
responsable of his erasing that his fault was just to write a clone
software. Nowhere I've heard about such a fault, among the various Bitnet
rules, so his expected to be resumed to us.
/Nico
*Editor's Note* First of all, I have no proof that the account was erased
because of the pseudo-RELAY affair. It is possible, maybe even proboble,
but I don't know that. If, indeed, the account was erase because of this
mess, I would say it was because the author's program is harmful to the
network, NOT because it imitates RELAY (because, for one thing, it
DOESN'T).
1
Page 20
I have nothing against free, user-supported, or public-domain software, and
I doubt that anybody does (except maybe software companies). I download
much of my PC software from public bulletin-board systems. I would not,
however, download a file archiver that actually increases the size of my
files. I would probobly warn people not to use it. In the same way, the
pseudo-RELAY caused more harm than good, and I warned people against it.
*************************************************************************
* 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."
|
|