* * * * * ** * ** ** * * * * * * * * * * * * * * * ***** ******* * * * ***** ****** ******* ****** * * * * * * * * * * * * * * * * * * ******* * * * * * * * * * * * ** * * * * * * * * * * * * * ****** * * * ***** * * * * * * * * The guide to BITNET servers and services * * * * Volume 1 Number 10 April 1987 * * * ***************************************************************** * * * Editor: Chris Condon CONDON@YALEVMX * * Assistant Editor: Steve Sutter SUTTER@YALEVMX * * NetMonth Staff Supervisor: Gary Moss MOSS@YALEVMX * * * ***************************************************************** * * * * * * * Leaders are people who do the right things. * * Managers are people who do things right. * * There has been too much attention to doing * * things right, and not enough emphasis on * * doing the right thing. * * * * -- Warren Bennis * * * * * * * * * * * * * * * * elephant is like a wall ke a * * An i p * * l i l * * a o e i * * r f c k ake * * o c e e n * * p loth a s * * e * * * * * * An ele phant * * is is lik e a t * * mushy ree t runk * ***************************************************************** 1 ************************************************************************* * Contents * *************************************************************************** Bitnotes ................................................................ 1 TAKE NOTE__________________________________________________________________ Scuttlebut .............................................................. 2 The PSUVM/OHSTVMA Link .................................................. 4 Global Students Network ................................................. 5 FEATURES___________________________________________________________________ Mail Manners ............................................................ 7 The BITNET Domains Task Force Report .................................... 8 SERVERS AND SERVICES_______________________________________________________ Spotlight Server: DATABASE@BITNIC ..................................... 13 New Mailing Lists ...................................................... 15 DEPARTMENTS________________________________________________________________ Feedback ............................................................... 16 Policies ............................................................... 17 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. For information on subscribing to NetMonth and BITNET SERVERS, see the "Policies" section on the last pages of this issue. Within "Policies" there are also instructions for submitting articles, sending Letters to the Editor, and printing this file. ------------------------------------------------------ A publication of the Bitnet Services Library "Because We're Here." 1 Page 1 ************************************************************************* * Bitnotes Issue 9 * *************************************************************************** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * The Bitnet Services Library (BITLIB) is an online help facility providing Yale VM users with information on file servers, name servers, electronic magazines, and other services. It includes specific usage information for each server, explanations of basic concepts (such as "What is a file server?") and a set of useful EXECs to make life with BITNET easier. All documentation has been tailored to the VM environment. BITLIB is currently undergoing conversion from YHELP to the new SP4 HELP facility. After the changes have been made, we would like to make BITLIB available for installation at other nodes. Distribution and monthly updates would be handled in the same way as Listserv and Relay. BITLIB has been serving users at Yale since May of 1985. At this time the we would like to monitor interest in the service. If you are interested in installing BITLIB at your node, or would like more information, please send mail to BITLIB@YALEVMX. --------------------------------------------------------------------------- This announcement was posted on the LIAISON list in mid-April. Response has been much greater than expected. Conversion to SP4 HELP has been completed, and a beta-test site will be implemented soon. --------------------------------------------------------------------------- There are new instructions for subscribing to NetMonth! We have finally given in to technology and will now let LISTSERV handle subscription requests. If you are already on the mailing list you do NOT need to request a subscription from LISTSERV. Many thanks to A. Harry Williams for setting up the list at MARIST. 1 Page 2 * Subscribing to NetMonth and BITNET SERVERS: VM users can be added to the mailing list by issuing the following command: TELL LISTSERV AT MARIST SUBSCRIBE NETMONTH Your_full_name VAX/VMS users can subscribe in a similar way: SEND LISTSERV@MARIST SUBSCRIBE NETMONTH Your_full_name If you cannot send messages in this way, you can send the following command as the first line of a mail file to LISTSERV@MARIST: SUBSCRIBE NETMONTH Your_full_name Arpanet users may use this method, but must address the mail to: LISTSERV%MARIST.BITNET@WISCVM.WISC.EDU --------------------------------------------------------------------------- They said it couldn't be done: Pending successful completion of all my classes, I will graduate on May 16th. After that I will be going to NetCon Spring 1987 (New Orleans) to speak on the Past and Future of BITNET. I will still be working on BITLIB and NetMonth after these momentous events (just in case you thought that my graduation meant that I wouldn't keep doing this. I'm having too much fun). Chris Condon@YALEVMX ************************************************************************* * Scuttlebut * *************************************************************************** The Lives and Deaths Relays: * Thanks to Jeff Kell and Jose Flores for the notice that there is now a Relay at UCSVM. * This news from Jeff Kell: Due to the withdrawal of the Relay server at NCSUVM, coupled with heavy network traffic which prohibits reassigning the affected sites to another server, the following nodes are being excluded from Relay service pending establishment of another server with better placement: APLVM ARSBARC AUVM BAGAMCOK BKNLVMS BRCVAX BUCKNELL CEBAFVAX CUA DICKINSN DUKE* ECSVAX ECUVM1 GALLU* GMUVAX GUNBRF 1 Page 3 GUVAX GUVM GWUVAX GWUVM HUMAIN IUP JHU* JMUVAX1 JPSPHVAX LOYVAX MUSCVM NBS NCSU* NIH* NRAO NSF ODUVM PSU* SCF* SEASVM TUCC* UC780 UDCVM UMAB UMBC* UMCINCOM UMD* UME* UMUC UNC* UNIVSCVM USGSRESV USUHS VCU* VIRGINIA VP* VT* WMHEG WMMVS I am providing this information in advance in anticipation of inquiries and/or flames from users at these sites. There is simply no way to continue service to these sites without undue load being placed on one or more critical hub links (CUNY-PSU, PSU-CORNELL, PSU-OHSTVMA). The server at UWF will continue to service sites south of TUCC; the affected region is from TUCC to PSUVM, including the area around PSUVM not on the CUNY, Cornell, or OHSTVMA paths. To avoid a lengthy discourse that won't change anything, accept it. Due to network loading and the sites served by NCSUVM, it is necessary to exclude (yes; exclude, omit, delete, no-speakie) their prior service area until some other suitable server can be found or established. This too is a fact which cannot be changed. PLEASE don't post 20-30 entries of how terrible this is, how somebody should do something, how node XYZZY should get a Relay, why can't Y2's Relay serve them for now, etc., etc. There is nothing more to be done. Cornell can't pick them up since it would load PSU-Cornell, Bitnic can't pick them up since it would load PSU-CUNY, and Pittsburgh can't pick them up since it would load PSU-OHSTVMA. And UWF can't serve the universe from the bottom of the southeast branch of the network (nothing critical intended -- wish I was in Florida). We have avoided denial of service for nearly two years now, that's good enough, but it can't last. Those of us who actually host a Relay and donate the time (personal as well as CPU) and resources, usually going against all odds to justify in the first place, have done quite well. NCSU did an outstanding job... they were one of the first, Relay has a lot of Alan's code in it, and when Cornell and Bitnic had to close the doors to the PSU area due to CPU and/or link loading, it was NCSU that let them back in. That very well may have contributed to their downfall in the end. And I don't want to see any other Relays face similar cases simply because we are *still* trying to provide service to *everyone*. I'm sure some of you out there know what I mean (UWAVM serving half the west coast by themselves, among others). Well, enough of this discourse, I should hush. On with the actual mail postings related to the event... I have to find my asbestos underwear as I'm sure my personals are going to be flamed in the near future... * Thanks to Tony Dahbura for the news that SERVER@SUZEUS (just announced last month) will no longer be avaialble due to system performance problems. 1 Page 4 ************************************************************************* * The PSUVM/OHSTVMA Link * *************************************************************************** Summary by Ross Patterson, Rutgers University Bill Rubin, City University of New York RSCS Incompatibilities Cause Link Backlog We recently experienced a heavy backlog on the PSUVM/OHSTVMA link, apparently caused when OHSTVMA installed RSCS Version 2 to replace RSCS Version 1.3. As a result, PSUVM had to run the DMTNJI line driver on the link, rather than on DMTVMB. Since the DMTVMB line driver is unavailable for RSCS V2, OHSTVMA could no longer use it. Previously, this driver, used for RSCS V1-to-RSCS V1 connections, provided performance benefits when both ends of the link ran RSCS V1. When IBM built RSCS V2, they selected the DMTNJI line driver as the network standard since it could communicate with any IBM networking system as well as a number of non-IBM systems. RSCS V1's DMTNJI line driver has weak points. For example, messages from one user to another and commands from a user to a remote system were not blocked. RSCS V1 sends each message or command (over a DMTNJI link) in a separate buffer, regardless of length. Since the usual buffer size for a DMTNJI link is 400 bytes and the maximum message/command size is 256 bytes, resources were being wasted. Consequently, RSCS V2 programmers implemented message blocking procedures, so that several messages could share a buffer. Since all systems, including RSCS V1, can receive such buffers, it seemed pointless to retro-fit this feature into RSCS V1. A second weakness involved RSCS's preference to send messages and commands before it sends data blocks or files. Because BITNET uses messaging extensively, a problem began to develop when the PSUVM/OHSTVMA link was apparently sending messages almost to the exclusion of files. Fixes OHSTVMA ran another RSCS V1 (called OHSTMPA) to communicate with PSUVM, so they could both use the DMTVMB line driver. The OHSTMPA/OHSTVMA link, a DMTNJI line, runs over a virtual Channel-To-Channel adapter, a fast networking connection. Consequently, the problem is avoided on the slow (PSUVM/OHSTMPA) connection, and the with the speed of the fast connection (OHSTMPA/OHSTVMA) the problem never existed. IBM has accepted an APAR (Authorized Problem Analysis Report) against RSCS V1, and will modify the Version 1 DMTNJI line driver to send multiple messages in a single buffer. When this fix is installed at PSUVM, the PSUVM/OHSTVMA connection will be operational, and OHSTMPA will be eliminated. 1 Page 5 Who might have this problem? Most VM-to-VM sites, currently running the DMTVMB line driver between them, could have this problem when only one site converts to RSCS V2. No problem exists if both sides convert to RSCS V2. If one site converts to RSCS V2, the RSCS V1 site should apply the APAR fix. How can the problem be avoided? Once the APAR fix VM27826 is tested and becomes available through IBM Support Centers, all RSCS V1 sites should install the APAR fix. ************************************************************************* * Global Students Network * *************************************************************************** By Toshi Tsubo Tokyo The Global Students Network is a student organization interested in building a global community of students using computer networks. We feel that such a network will help develop necessary human resources such as a global perspective and communication skills for conflict resolution. We plan to organize our group through a multi-media communication system including: o BITNET : e-mail, mailing lists gatewaying with ARPA Internet (USA), CSNET (USA), JANET (UK), EANnet (Europe), CDNnet (Canada), COSAC (France), DFN (Germany), ASCNET (Australia), UUCP/USENET (USA), EUnet (Europe), SDN (Korea), JUNET (Japan). o DASNET : e-mail, parallel conferences linking ARPANET, BITNET, BIX, CompuServe, CSNET, EasyLink, EIES, ENET, GEnie, MCI Mail, NWI, Santa Clara Univ, The Source, Stanford Univ, TWICS, Unison, UUCP. o Other media : Telephone, Telex, Fax, Video and Paper. Our group will concentrate on several projects. They will be : o General Administration and Finance. o Creating, maintaining and distribution a network map and a members directory. o Inter-networking and networking technologies. 1 Page 6 o Establishing and organizing a mailing list or other communication system where students can interact in other language environments. This will be called the "Multi-Language Learning Environment". o A service to assist students in their travels and facilitate face to face meetings. o An electronic pen pal system for younger children using the network established by the Global Students Network. This will be called the "Global Kids Link". If you are anyone you know is interesting in participating or knowing more about this project, please write to one or more of the following addresses: Toshi Tsubo Central Meguro 102 2-7-10 Mita, Megruo-ku Tokyo 153 Joichi Ito 4800 South Lake Shore Drive Apartment 1910-S Chicago, IL 60615 Kevin Barron, Vancouver, Canada Bitnet: USERZABL@SFU.BITNET PeaceNet: jito Telemail: ÕJ.ITO/BUSCOMMå TELEMAIL/USA The Source: BBJ294 NWI/PARTI: JOICHI ITO Unison: JOICHI (partiname: JOICHI ITO) CompuServe: 70116,502 TWICS: TSUBO (partiname: TOSHI TSUBO) GreenNet: TOSHI MCI mail: Toshihiro Tsubo elephant is like a wall ke a An i p l i l a o e i r f c k ake o c e e n p loth a s e An ele phant is is lik e a t mushy ree t runk 1 Page 7 ************************************************************************* * Mail Manners * *************************************************************************** From the file MAIL MANNERS, available from NICSERVE@BITNIC. The Phenomenon of FLAMING The following was from: Toward an Ethics and Etiquette for Electronic Mail written by Norman Z. Shapiro and Robert H. Anderson prepared for the National Science Foundation and published by The Rand Corporation. Perhaps the attribute of electronic mail systems that most distinguishes them from other forms of communication is their propensity to evoke emotion in the recipient--very likely because of misinterpretation of some portion of the form or content of the message--and the likelihood that the recipient will then fire off a response that aggravates the situation. Possible causes for this phenomenon include: - Difficulty in determining the formality of a message from its appearance. - Attempts at humor, irony, sarcasm, and wit are often misinterpreted. - Cues such as body langauge are lacking in electronic mail. - The ease of an immediate "reply" encourages "off the top of the head" responses. - Electronic messages containing hasty or ill-chosen words can stay in electronic inboxes or can be printed in a way (injet, etc.) that gives them an importance never intended. - Although anonymity is often mentioned as a factor, we have observed no significant difference in "flaming" between remote correspondents who don't know each other personally, compared with communication among people who know each other. What can be done to minimize the problems of escalating emotions that arise? - Carefully label messages that have a deliberate emotional content. Sometimes just the annotation "Flame! Flame!" alerts the reader to the fact that the writer knows he or she is being emotional. - Resist the temptation to fire off a response. Write the response, file it away, and wait 24 hours. Reconsider the response later, in the light of a new day (and perhaps a rereading and reinterpretation of the original message). 1 Page 8 - Use alternative media to break the cycle of message-and-response. A telephone call or personal conversation can do wonders, when we can use body language, eye contact, and the other cues we've developed. Much of the problem seems to stem from the lack of cues that electronic mail affords its readers. Perhaps the technology that spawned electronic mail can help reduce the misunderstandings it creates. One can imagine message systems in which the boldness of the characters displayed is a function of the force with which the keys are hit. More certainly (because the systems are in prototype form already) there will be systems in which the characters will be accompanied by voice annotations, so that the humanity and state of the sender will be retained and "read" by the recipient. Toward an Ethics and Etiquette for Electronic Mail, published by the Rand Corporation with support from the National Science Foundation, discusses issues related to the use of electronic mail and the effect of these systems on the quality and appropriateness of communication. More importantly, it presents a set of guidelines that should help lead to effective electronic mail use. Readers should be familiar with electronic mail systems or considering adopting them for individual or institutional use. Copies are available for $4 from The Rand Corporation, Publications Department, 1700 Main Street, P.O. Box 2138, Santa Monica, CA 90406-2138. Ask for publication R-3283-NSF/RC. ************************************************************************* * BITNET Domains Task Force Report * *************************************************************************** This article was condensed from the original report. You can get the complete report (the file DOMTASK LISTING) from NICSERVE@BITNIC. BITNET DOMAINS TASK FORCE Report and Recommendations to the BITNET Executive Committee The BITNET executive committee directed Joe Yeaton of UCB and Leland Williams of TUCC to form a Domains Task Force. The stated mission of the task force is to identify BITNET's requirements for domains and domain servers and then to propose technical solutions to those requirements. The task force recently met during the SHARE 66 conference in Anaheim, discussed the issues, and developed a set of recommendations which follow. The meeting was led by Jim Walker of TUCC and David Wasley of UCB, each appointed to the task by their respective directors. 1 Page 9 The Domains Task Force recommends that the following actions be taken by the BITNET Executive Committee, the Domains Task Force, and the BITNET Network Information Center, respectively: 1. The Executive Committee should officially acknowledge that BITNET will adopt the DARPA Internet domain hierarchy and top-level domain names. 2. The Executive Committee should contact the appropriate Defense Communications Agency (DCA) representative to obtain formal cooperation and coordination of use of top level domain names. The flat name space has become difficult to manage and is too restrictive. Therefore, a hierarchical name space should be adopted. For essentially the same reasons that the ARPANET community decided to move from a flat to a hierarchical name space, we also feel that it is time to begin the move in that direction: 1. Maintaining unique and still meaningful node names within the 8 character limit is difficult. This limit has led to the problem that the user of BITNET has trouble determining what site a given node name represents. 2. Maintaining and distributing a database containing the name of every machine on the network is awkward and will continue to impose delays in making new nodes accessible. Adopting a hierarchical naming strategy built on top of the underlying link-level RSCS node names addresses both the naming and management problems: 1. Domain names are not artificially limited to some small number of characters. With domain names, the common misconception that "CUVMA" and "CUNYVM" are both nodes at Columbia University or City University of New York (or Cornell University) can be eliminated; a domain name of "CUVMA.COLUMBIA.EDU" clearly identifies the site as an educational institution named Columbia. 2. Hierarchichal naming gives the organization control over its own namespace and only requires agreement on a single name in the containing namespace used to identify that organization. Two sites can even have a machine with the same name ("VMA" for example) and not have a conflict since their containing domain name will be unique ("VMA.COLUMBIA.EDU" and "VMA.CORNELL.EDU" for example). 1 Page 10 Within the constraints of the RSCS network, unique node names are still required to maintain full connectivity. However, node names, although unique, need not be meaningful to the user since he or she will be dealing with a higher-level domain name. The fundamental concept here is to consider the RSCS node name as a low-level "network address." The user sees a domain name which higher-level software will map to the network address "under the covers." This is analagous to the mapping done on the ARPANET between domain names and IP host numbers (which are 32-bit integers). These network addresses (RSCS nodes, IP host numbers) still need to be unique, but the problem of making them meaningful to the user goes away; the user gets the meaning from the domain name. The use of domain naming may eventually allow a reduction in the number of BITNET nodes that require full RSCS-level connectivity. Only the node at a site physically connecting that site to the RSCS network need be in all other sites' RSCS route tables. That connected node serves as the routing gateway between the long-haul RSCS network and the rest of the site's nodes. A complete domain-level software layer that minimally provides the same functionality currently provided at the RSCS level must exist in order for this to work. An example where this domain-level software capability currently exists is with mail: If all other BITNET sites that wanted to communicate with Columbia users also ran a mail transport agent like UCLA/Mail (MVS) or the Columbia Mailer (VM), then only RSCS node CUVMA would need to be in other site's route tables; their mailers would know that all mail for the COLUMBIA.EDU domain should be routed to the mailer on CUVMA which would take care of local redistribution within the university's local area network. Of course, other network functions such as interactive messaging (TELL) or file transfer (SENDFILE) would need to be modified to incorporate similar routing algorithms. Assuming that a hierarchical name space is adopted, it is recommended that this name space be based upon the DARPA Internet model and use the same top-level domain names. The DARPA domain model is geography and network independent; it reflects the natural admininistrative hierarchy of organizations and their peer-to-peer relationship -- not location or how they are connected. Domain names that reflect the method of interconnection such as .ARPA or .BITNET are to be avoided. The .ARPA domain was used in the transitionary period between the flat and hierarchical name spaces in the ARPANET. The implementors have since stated that it was a mistake to ever get people accustomed to this naming hierarchy. The task force feels that there is no point in reinventing the wheel. We would rather adopt the DARPA model (as has been done before for mail) than come up with our own model. This has 1 Page 11 special importance to the large number of BITNET sites that are also on the other DARPA Internet-compatible networks (ARPANET, MILNET, CSNET). Use of the same top-level Defense Data Network (DDN) domain names (.EDU,.COM, etc.) will require the cooperation of the DDN Program Management Office (PMO) of the U.S. Defense Communications Agency (DCA) and coordination with the DDN Network Information Center and with the DDN PMO contracting department(s) on those campuses that are on both networks. At a meeting at SRI attended by Candy Willut of EDUCOM and representatives of ARPANET, CSNET, and UUCP it was agreed that these networks joining the Internet would be beneficial to all concerned. However, SRI is not the official policy-setting representative of the DCA. We recommend that formal cooperation be agreed upon by the executive committee and the appropriate DCA representative. Furthermore, for sites on both networks, administrative cooperation is necessary between the BITNET site administration (typically the computer center) and the DDN site administration (typically the computer science department). The current unoffical (from the standpoint of DARPA) use of DARPA domain naming within BITNET has led to problems when mail crosses the boundary from BITNET to ARPANET; when the user on the ARPANET tries to reply to the mail, it is found that the BITNET site's top-level domain or some sub-domain is not registered in the appropriate domain names database. For example, mail sent from CUVMA.COLUMBIA.EDU (RSCS node CUVMA on BITNET) to someone on ARPANET results in something similar to the following scenario: The replying mail server will query the SRC-NIC name server (since it is the authorized server for the EDU domain) for the name server for the COLUMBIA.EDU domain. SRI-NIC will respond with the address of COLUMBIA.EDU, a VAX 11/750 administered by the Columbia Computer Science department. Upon asking this name server for the address of CUVMA.COLUMBIA.EDU, the mail server will be informed that CUVMA.COLUMBIA.EDU does not exist since it is not registered. Although the CS department could register the BITNET hosts at Columbia in their name server, they might be reluctant to carry mail traffic from DDN to BITNET and especially vice-versa unless the DDN PMO acknowledges that this is a valid use of DDN resources. This is why explicit cooperation between the BITNET Executive and DDN is a requirement. Some organization is required to administer the name space for sites that have only a BITNET connection, from the DDN point of view. BITNIC, as an agent of the executive committee, is the place for such an administrative function. Since SRI-NIC is the official registrar for subdomains within the top-level EDU domain, a means of registering these BITNET-only EDU 1 Page 12 BITNET can not count on IBM to provide software to support the above. Therefore, we are explicitly acknowledging that non-IBM software will be required. Unmodified, vendor-supported network transport mechanisms (e.g. RSCS, JES, jnet, etc.) should be used; hierarchical name support will be layered on top with additional software developed by BITNET members. This is not an endorsement of the vendor software as being the best way to interconnect BITNET. It is recognition of the fact that this is the way the network is currently connected. We do not wish to recommend that sites must modify their vendor-supplied software to participate in the network (at the transport layer). We do wish to drive home the point that although vendor software for the network transport functions can be vanilla, sites will have to run modified, complete replacement, and/or additional applications software in order to participate effectively in the Internet. It should be made clear to existing and potential BITNET members that they can not expect to have the same functionality as other members unless they use this additional or changed software. The use of hierarchical names rather than RSCS node names as the fundamental user-visible method of addressing another user implies that this hierarchical support should encompass all or many of the functions currently provided by the base RSCS network: - mail - file transfer - interactive messaging - RJE/RJO - remote commands - remote login (not really feasible using current low-speed links) - etc. We recognize that some or all of these recommendations may not apply to the environments of our peer RSCS networks, EARN and NETNORTH. The use of DARPA domain names is not meant to address their environment but that of United States BITNET sites and should not be construed as the only solution or one that we expect non-US sites to adopt. Specifically, EARN/NETNORTH sites may prefer to implement some other naming scheme more compatible to their environments (e.g. CCITT X.400). We of course intend to maintain and enhance the interconnectivity of our networks. Nothing recommended here should be construed as impeding cooperation with EARN/NETNORTH. We believe these recommendations to be the current best solution and realize that there will be and fully expect future changes that will augment or supersede the recommended solutions presented here. 1 Page 13 ************************************************************************* * Spotlight Server: DATABASE@BITNIC * *************************************************************************** DATABASE is a sophisticated database server developed for BITDOC by Henry Nussbacher, consultant, City University of New York. DATABASE provides user specified keyword access to subsets of larger databases. Retrieval capabilities are based on SPIRES, the Stanford Public Information Retrieval System. A Subfile is the largest structure in which information is stored within SPIRES on DATABASE. Three types of subfiles include Demonstration Files such as MOVIES or RECIPES used to gain experiance with DATABASE, Network Digests such as AI-LISTS an archive of a discussion forum maintained within ARPANET, and General Information Files such BITINFO the BITNET node identification subfile. DATABASE is available to BITNET, EARN, and NetNorth users via interactive messages, mail, and files in CMS PRINT or PUNCH format, and responds based upon a node's preferred file format. DATABASE will also respond to Internet requests from other networks using mail which conforms to ARPANET standard RFC822. Issue the following interactive message from an IBM/VM environment, to get the initial DATABASE HELP file. TELL DATABASE AT BITNIC HELP From a VAX/jnet environment, issue the command SEND DATABASE@BITNIC HELP Create mail, or an appropriate file or send an interactive message to DATABASE@BITNIC with the commands HELP, HELP ARPANET, and HELP DESIGN for a complete set of help files. Below are examples using the DATABASE server. While commands can be sent by any of the methods previously mentioned, these examples are based on the IBM/VM TELL command. TELL DATABASE AT BITNIC LIST This command returns a list of retreivable subfiles as follows. DRINKS Demonstration subfile MOVIES Demonstration subfile . . BITINFO Database System subfile AI-LIST ARPANET discussion forum (digest) 1 Page 14 TELL DATABASE AT BITNIC FIND TEXT BITNET (IN INFO-NETS TABLE This command tells DATABASE to use the FIND command to search the TEXT of all the entries in the subfile INFO-NETS for all instances of the word BITNET and reports the results as a table rather than full text since the file would most likely be too large. (Any result larger than 1000 lines of text will be returned in a TABLE format or will respond as if the HOWMANY option had been specified.) A table returned may look like: GRANDS SUBJECT ----------------------------------------------- 498 Subject: PHYSnet 499 Subject: Sitelists and General Info . . . . 583 Subject: gateway to NJIT TELL DATABASE AT BITNIC FIND GS 583 (IN INFO-NETS DATABASE will return the contents of the entry whose subject is "gateway to NJIT". GS 583 specifies the GRANDS SUBJECT number 583 from the ARPANET digest INFO-NETS. Unlike the ARPANET digest subfiles some subfiles are not searchable by by the index TEXT. For example, BITINFO is the BITNET database subfile. It is a compiled version of the bulk of information contained in BITONLY NAMES, EARN NAMES, and NETNORTH NAMES and identifies and characterizes nodes and contacts on the network. An example of some search commands are: FIND SITEDESC CUNY (IN BITINFO FIND NODE CUNYVM (IN BITINFO FORMAT LONG FIND STATE NY (IN BITINFO FORMAT SHORT The indices being searched on are SITEDESC, NODE, and STATE. To find out what indices are valid to seach on within any subfile, issue the command: TELL DATABASE AT BITNIC SHOW INDEX (IN subfile The values chosen here to search on are CUNY, CUNYVM, and NY. To get an idea of what values can be searched upon within an index, issue the command: TELL DATABASE AT BITNIC BROWSE indexname (IN subfile The format in which the results are returned in the examples above are standard SPIRES format (if no other is specified), SHORT, and LONG. To find out what formats are valid for a particular subfile issue the command: TELL DATABASE AT BITNIC SHOW FORMATS (IN subfile where BITINFO can be substituted for the word "subfile". 1 Page 15 Users who wish to use DATABASE via RFC822 mail, must first signon and receive a user number (UN) and supply a password. To signon, send the following command to DATABASE: SIGNIN mypassword where mypassword can be any string of contiguous characters that is more than or equal to 8 and less than or equal to 20. You will receive a mail file in return like this: Your signup has been processed and you have been assigned a user number (UN) of 00012. You are from that point onward, registered in DATABASE and can use any of the commands listed above. If you no longer wish to be registered by DATABASE, execute the command: SIGNOUT 00012 mypassword You will no longer be known to DATABASE and will have to SIGNIN again if you wish to use DATABASE by sending RFC822 mail. ************************************************************************* * New Mailing Lists * *************************************************************************** ICECNET#@ANDREW.CMU.EDU ICEC, the InterUniversity Consortium for Educational Computing, is a consortium of universities and colleges committed to developing high- quality educational applications for advanced computing environments. ICECNET has been the newsletter of ICEC for several years. Paper publication continues, but a copy of each issue of the newsletter will also be released about once a month via this mailing list. ICEC has supported software development at member schools and conducted activities for faculty from member schools (e.g. developers' conference, training programs in courseware development for advanced workstations). Other mechanisms are evolving to promote development of good educational programs for advanced, graphics-intensive workstations and to aid in sharing these developments among interested parties. ICEC is therefore initiating an internet mailing list (1) for publication of information about ICEC, (2) communication among member schools related to internal business, and (3) as a forum for discussing issues related to the general objectives of ICEC. Examples of the third category might be "what constitutes high-quality courseware?", "what Unix workstations are best suited to general educational use?", "what mechanisms are best for sharing educational developments using advanced technologies?", etc., etc., 1 Page 16 etc. Individuals, both from member schools and from non-member organizations, are invited to contribute in this third area. All submissions for the monthly (paper) newsletter should be sent to: Patricia Clark,ICECNET editor or Robert Cavalier, assistant director of ICEC All requests to be added to or deleted from this list, problems, questions, etc., should be sent to ICECNET-REQUEST#@ANDREW.CMU.EDU. List maintainers: Robert Cavalier Kenneth Friend ************************************************************************* * Feedback * *************************************************************************** Date: Wed, 1 Apr 87 19:19 EST From: Thomas Kunselman Subject: The troubles at Ohstvma with the queue jams To: Chris Condon I don't read any of those groups where you summarized the problems of the queue jams, but there might be a way one might take care of this without changing anything but some of the routing tables. I don't know how the standard for this is or anything, but it seems to me from looking at the BITNET Topology file that there are two ways to send files to the nodes off of OHSTVMA. Almost all of the nodes that can be reached off of OHSTVMA can also be reached by going through WISCVM and then through Nebraska. I don't remember what the node name for that university is right now, as I don't have an updated routing table. Anyway, if one sends a file from WISCVM to say UKCC or any of a couple of hundred nodes, it goes through the OSHTVMA node. Why can't these be sent the alternative and less used route through Nebraska and then to us? Even tho this route is much longer to reach CCOL it would still be faster, I believe. When I tried reaching Nebraska two weeks ago the links were down on either side so I don't know if it has been hooked up yet. I have since misplaced my notes. If you could tell me who to get in touch with about this, I would be happy to do so. Although it may take me forever to get another BITNET Toplogy map with the way OHSTVMA is:-) * * * *** ******** * * **** * * ** **** ** * * * * ******* * * * **** * * * *** * * * ****** ***** ***** *** * 1 Page 17 ************************************************************************* * NetMonth Policies * *************************************************************************** * Subscribing to NetMonth and BITNET SERVERS: VM users can be added to the mailing list by issuing the following command: TELL LISTSERV AT MARIST SUBSCRIBE NETMONTH Your_full_name VAX/VMS users can subscribe in a similar way: SEND LISTSERV@MARIST SUBSCRIBE NETMONTH Your_full_name If you cannot send messages in this way, you can send the following command as the first line of a mail file to LISTSERV@MARIST: SUBSCRIBE NETMONTH Your_full_name Arpanet users may use this method, but must address the mail to: LISTSERV%MARIST.BITNET@WISCVM.WISC.EDU A subscriber can delete him/herself from the mailing list by sending LISTSERV@MARIST the UNSUBSCRIBE NETMONTH command. * Letters to the Editor: If you have questions or comments about BITNET or NetMonth that you would like printed here, mail your l etter 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. * 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. * Printing this file: VM users can print this file by first copying it to NETMONTH LISTING and then printing the new file. This will allow page- breaks and other formatting to be understood by your printer. --------------------------------------------------------------------------- A publication of the Bitnet Services Library "Because We're Here."