* * * * * ** * ** ** * * * * * * * * * * * * * * * ***** ******* * * * ***** ****** ******* ****** * * * * * * * * * * * * * * * * * * ******* * * * * * * * * * * * ** * * * * * * * * * * * * * ****** * * * ***** * * * * * * * * 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."