******** ************************************************** * * * * * * The independent guide to BITNET * * ******* * * ******* June, 1988 * * * * * * * * Volume 2, Number 12 * ******** *************** * *************** * *** * * * * * * * * * * * * **** * * * * **** * * ** * * * * * * * ************************************* * * ************************************* * ****** * * * * * * * * ************************** * ************************** * ******** * * * * * * * * ********** * * ********** * * * * * * * * * ******** ***************** * ***************** * *** * * * * * * * * * * ******************************************** * * * ******************************************** * *** * * * * * * ****** ******************************** * * ******************************** * * * * * * * * * **** *************************************** * *************************************** * * * * * * * * * ****** ********************** * * ********************** * * * * * * * * ******** ************* * * ************* * * * * * * * * **** ************************************************** 1 * * * * * ** * * ** ** * * * * * * *** ***** * * * * *** **** ***** **** * * * * * * * * * * * * * * * * * * * ***** * * * * * * * * * * * ** * * * * * * * * * * * * * **** * * * *** * * * * * ***** ****** Christopher Condon Editor CONDON @ YALEVM Timothy Stephen Contributing Editor STEPHEN @ RPICICGE Craig White Contributing Editor CWHITE @ UA1VM Glen Overby Technical Assistant NU070156 @ NDSUVM1 Gary Moss Staff Supervisor MOSS @ YALEVM ******************** Contents - Issue 22 ******************** EDITORIAL PAGE_________________________________________________ Bitnotes .................................................... 1 The Human Factor ............................................ 3 Flames To: .................................................. 7 FEATURES_______________________________________________________ CCNEWS - For Newsletter Editors ............................. 9 LYRICS - The Song Lyrics Server ............................ 10 PHSERVE - The UIUCVMD Phone Book ........................... 12 DEPARTMENTS____________________________________________________ Headlines .................................................. 13 Helpdesk ................................................... 15 New Mailing Lists .......................................... 16 Feedback ................................................... 20 Policies ................................................... 25 * For information on subscribing to NetMonth, submitting * * articles, sending letters, and printing this file, see * * the "Policies" section on the last pages of this issue. * ----------------------------------------- A publication of the BITNET Services Library "Because We're Here." 1 Page 1 ********* * * Bitnotes * * * * by Christopher Condon * * * * Yale University * * * * CONDON@YALEVM ********* "A rose by any other name..." Suddenly, the air feels very warm. Your palms are sweaty, your breathing labored. A nervous twitch is working its way up your arm. You bite your lip. A chill runs down your spine. You are trying to describe BITNET. "It's a... well, sort of a... that is..." You want to convey a feeling, a utility, a sense of community, but you find yourself not quite eloquent enough. Words fail you, and a thesaurus is nowhere in sight. "It's a... kind of... network, see? With computers..." The computer-guru will demand a technical explanation. Hardware, link speeds, software. VM/CMS? RSCS? JNET? NRJE? TCP/IP? Let's wallow in acronyms, shall we? The whole is greater than the sum of it's parts, however: "It's a... well, more than hardware! It's people, and..." Try to explain Listserv and mailing lists to a "non-computer" person in a minute or less. So they TRULY understand? What is there to compare it to in real (i.e. non-virtual) life? "It's a... there are these servers with information..." True, BITNET is an information service, of a sort. Some might liken file servers and name servers to similar services on CompuServe, GEnie, or The Source. That is only small piece of picture, however. "It's a... Let's see... we send mail and talk to each other..." Yes, it is a tool for communications. That is certainly the largest part of it. However, the same could be said for a said for a telephone, a television, or a ham radio set. There must 1 Page 2 be something about it that makes it different from these other devices. "It's a... we use computers." You said that before. "It's a... it's people, dammit!" People are everywhere. The NRA is people. Scientologists are people. Even Republicans are people, allegedly. Perhaps there is something about your people in particular that makes BITNET different. "It's a... education and research network." Oh. Eggheads. "It's a... No!" Let's take a different approach. Perhaps you can explain what BITNET stands for. "Got you! Because It's There, Because It's Time." That says a lot. "" Let's get this straight. BITNET is an information service. It is a tool for communications. It is a community of people involved in education and research. "Yes, yes, yes!" Oh. Why didn't you just say so? Virtually, Chris Condon@YALEVM * ******************************************* ******************************************* * * ******************************* ******************************* * 1 Page 3 ********* * * The Human Factor * * * * by T. D. Stephen * * * * Rensselaer Polytechnic Institute * * * * STEPHEN@RPICICGE ********* There is an old bromide, perpetually re-hashed in freshman communication courses throughout America each Fall semester, that says, "you cannot not communicate". Usually presented as an hypothesis, students are challenged to agree or disagree with it. After sufficient deliberation and debate, the instructor reveals that "you cannot not communicate" is an accepted minor tenet of modern communication theory. Everyone knows that you cannot not communicate because the absence of communication itself conveys meaning; e.g., if a friend won't speak to you, you suspect that she's probably trying to tell you that you've done something wrong. Suddenly BITNET calls this into question. I can't think of another communication system that better demonstrates so many ways in which you *can* effectively not communicate and that shows so clearly how it is sometimes virtually impossible to make any sense from communication's absence. A good example occurs when a new node has been connected to BITNET before routing tables at existing sites have been updated. As I understand it, the routing tables allow computers to know which path to take in sending messages to each other. People from the new node can send messages throughout the network because systems personnel there received a copy of the latest routing table upon joining the net. But recipients cannot communicate back and, generally, neither sender nor receiver understands what the devil is going on. I've seen this periodically when someone from a new node attempts to contact Comserve@Rpicicge, the communication studies information system. Jones@Newnode sends the following message on day 1: "Help". Comserve responds but the network software rejects the message before it gets very far, often before it leaves RPI. The new user repeats the "Help" message on day 2. On day 3 the following: "Hello?". Then on day 4, "Why don't you respond to me? Please let me know what I'm doing wrong." That's the end of it; Comserve usually never receives a message from Jones@Newnode again. Too bad the network can't 1 Page 4 provide Jones with feedback that his/her message traversed beyond a point of no return. If information makes the world go around, then it is feedback that keeps it in its orbit. Feedback corrects, aligns, adjusts, modulates, attunes; it is the system's defense against entropy. No system, mechanical or human, can perform effectively or for long unless its designers have built in methods for it to monitor and correct its own behavior. It must have dedicated sub-systems that exist to provide a means for testing the continued validity of the original assumptions upon which the system was built and for relaying this information appropriately. With provision for such feedback, it is possible for systems to adapt themselves to changing circumstances. Without it, the system is an inflexible dinosaur and will begin to break down as its environment changes. While there are many points at which mechanical feedback systems have been built into BITNET and its various services, there are several critical points at which they are missing and their absence can be inconvenient and frustrating. Craig White anticipated this issue in his "Flames-To" column last month when he identified one of BITNET's principle problems: its lack of an effective feedback mechanism assuring minimum time to recovery when a link goes down. Craig noted, as have others no doubt, that there is a great deal of variance in the degree of vigilance and responsibility that site personnel display in monitoring the status of their BITNET connections. Unfortunately, the network software that allows us to communicate doesn't do a good job of notifying anybody when it loses a connection to another computer. A good version of this software would fix itself, an adequate version would trigger a flashing light or an audible alarm. Based on what I've seen, the version we need on BITNET is one that starts deducting from the salary of the person responsible for maintaining the link until it is restored. One feedback system -- the Linkfail mailing list -- was established to help head off a portion of the confusion generated by this type of situation. The idea behind Linkfail is that when a site knows in advance that it will not be able to provide service for a period of time (due to a scheduled campus power outage, for example) someone is supposed to send a note to Linkfail to let the rest of us know about it. Good idea. In practice, however, this system doesn't work as well as it should. One problem is that not all sites bother to inform Linkfail, not even all of the central ones that virtually everyone depends on (Yale, CUNY, Ohio State, Penn State, etc.). Another problem is that announcements posted to 1 Page 5 Linkfail are often not channeled to users. It really doesn't do users any good if, after the systems programmers find out from Linkfail that the network will be unavailable for three days next week, they don't tell users at their site about it. Obviously, it would be better if users could be provided with more feedback about the status of the network. But in many cases feedback loops need to be bi-directional, connecting those who provide BITNET services (file servers, name servers, mailers, gateways, list servers, etc.) and the people who use them. Both could profit from each other's feedback. Those who access services could find out how to use them more productively and efficiently; those who provide services could find out how to improve them. Unfortunately, many BITNET services have not been provided with an adequate system for human feedback. Take as an example the common Listserv occurrence of people sending subscription requests to the address of the mailing list instead of to Listserv itself. Sometimes hundreds of copies of the request are delivered to other subscribers, the subscription request does not itself get processed, and no feedback is provided to the would-be subscriber (making it a little difficult to learn from the mistake). Since there appear to be difficulties in programming Listserv to detect and respond to these errant requests, there should be, but most often is not, a human monitor -- someone who can supply the feedback that the user needs in order to use the system productively. In addition, there should be an avenue for *users* to supply feedback to those who provide and maintain the Listserv software system. There is a "list" named LSTSRV-L and it provides this function for Listserv operators; they use LSTSRV-L to communicate among themselves and with Eric Thomas, the Wunderkind behind Listserv. However, what's lacking is a similar feedback loop connecting Listserv's users and local Listserv operators. As far as I can tell, there has been no formal effort to assess users' experiences with Listserv, to find out what they like about it and what they find annoying. Don't misunderstand, I don't mean to single out Listserv for special criticism; Listserv merely offers a convenient example, one with which most of us are familiar. Services on BITNET that provide a point of human contact or have attempted to gather user feedback through some other mechanism are a tiny minority. This phenomenon seems especially dangerous given the computer industry's well known history of hardware and software ventures that flop after having been designed without adequate input from potential users or having gained a reputation for poor consumer relations. 1 Page 6 One reason that people developing or operating BITNET and its services may be reluctant to provide mechanisms for gathering user feedback is that managers may not always place a sufficient premium on this sort of effort. The word may come down to "provide users with e-mail access", rather than to "provide users with an e-mail system that *users* will find accessible." Basically, the problem is one of leadership. Certainly most schools that belong to BITNET have the technical and human resources to provide a higher grade of user-oriented service; however, without leadership from site managers and ultimately from BITNET's main administrative body -- the BITNET Board of Trustees -- these resources may never be brought into play. Modeling is one of the most effective forms of leadership and this is where the Board of Trustees could perform an important service. They should provide a visible example of responsive and open communication with the BITNET user community by sustaining an active effort to solicit feedback about BITNET and recommendations for its improvement. However, the present system used by the Board for gathering feedback has no realistic provision for obtaining input from BITNET's general user population. If a user has a question, a suggestion, or a complaint or wishes to have a voice in policy matters, he/she is expected to channel this through the local BIR (BITNET Institutional Representative). This individual is supposed to pass it along to the Board. Whoever thought this system up was either naive about day to day business on BITNET, conceived of BITNET as the exclusive province of computer center personnel, or wanted to create an appearance of openness while guaranteeing that policy making would proceed in an environment effectively closed to outside input. Take a guess: How many of BITNET's users do you think know who their local BIR is (or their Information Services Representative or their Technical Representative, for that matter)? How many sites routinely let new users know who these people are and that they are responsible for conveying feedback to the Board? How many BIRs really want to act in this capacity and have demonstrated so by canvassing users for input? I once had a professor who nurtured his reputation as a phrase- maker and one of his favorites quips was "the facts are friendly." What he meant by this was that those who actively solicit feedback will always do better than those who don't, even if the feedback is negative. Only systems that become aware of their problems will be able to correct them. So let's see what we can do to open dialog between BITNET's services, users, and agencies. Let's come out from behind the automated 1 Page 7 servers and isolated decision-making structures and engage in a little perception testing. Moreover, let's call on the Board of Trustees to provide a positive model for effective communication, one that enfranchises all of BITNET's diverse groups of users. *************************************************************** I received a large amount of mail in reaction to last month's column on making BITNET addresses easier for humans. Much of this mail was from computer center staff who are sympathetic to the problem and would like to find solutions and some was from people who have solutions to offer. Suggestion: write to the listserv operator at Bitnic, and ask for a new "list" to be established for discussion of approaches for resolving this problem. Send me a note when that's accomplished and I'll ask Editor Condon to announce the list address in next month's issue. ********* * * Flames To: * * * * by Craig White * * * * University of Alabama * * * * CWHITE@UA1VM ********* Hello again, This month the mail has really poured in. My in-box was so full at times that it just had to sit. I thought about different ways to deal with this dilemma but really just couldn't come up with a very good way to do that. I did get most of the reading done except for some of the digests. This month has been a very reliable one in terms of connectivity in my limited area; I appreciate all the hard work that goes into that, folks. This month's flame is about, of all things FLAMES. As I read mail from the various lists, I often see flames that are not clearly marked as such. Because we sometimes misinterpret what we read, I would say that only half of what I consider to be flames actually are. Most of us are well acquainted with the phenomena of misinterpretation. Take computer manuals for instance; I know that many times I have had problems getting programs to run or commands to work simply because I misinterpreted what I read in a manual. 1 Page 8 With electronic mail, this misinterpretation seems to be even more prevalent, and many times with terrible consequences. For instance, if someone misinterprets one of your postings, you might get flamed for it. Often, we feel personally attacked when this happens, and there is a tendency to overreact and send an inappropriate mailing to the sender of the offending posting. Or even worse, to the whole list if we feel that we have been sufficiently slighted. I suppose that what we really need to keep in mind is that for most people, mailing to a list is something they didn't put much thought into. Often, it is a description of a problem quickly typed and then sent on it's way. Sometimes in the description of the problem the sender neglects to mention the pertinent facts and in response someone mails a really condescending letter back to the group, maybe to make the person feel that their problem is somehow too trivial for the group. Many times this is repeated for 10 - 20 times before everyone feels that they have thoroughly humiliated the foolish person. The result is usually that even though the problem was easy to solve, no one remembered to put the answer to it in their response. I think that in the above case, the responder who rags the poor guy for being an idiot, should ALWAYS make sure that their response is preceded by some kind of FLAME marker. It could be as cute as "get out your asbestos underwear", or as terse as ***FLAME ON***. The author of such flames should always make it perfectly clear to whom they are about to flame, and also to the whole list if it just has to be made public, that they are about to engage in a display of emotions so that everyone can get the right perspective about the whole event. If you happen to be on the receiving end of a flame, try to remember that you somehow managed to trigger an emotional response on the part of the flamer and you should keep that in mind as you read their response. You as the recipient of the flame should avoid sending a flame back to your flamer for at least one night of sleep. It seems that many times flames just keeps getting bounced back and forth until it's an inferno with neither party able to do anything but fume and send out more fuel for the other to use. By giving yourself a little time between flames you give yourself and the sender time to mull over what has been said, develop a new attitude, or you might even decide that it's not even worth the trouble to compose a response and send it off. Cooling off, I have an LDBASE update. It seems that LDBASE's ability to search notebooks is totally up to the list owner. So if you're trying to use LDBASE to help out your in-box as I am, contact list owners about changing their lists so that you 1 Page 9 don't have to be signed up to peruse their notebooks. Thanks to Eric Thomas for this LDBASE clarification. As always, flames, questions, comments to CWHITE@UA1VM. ********* * * CCNEWS - For Newsletter Editors * * * * by Christopher Condon * * * * Yale University * * * * CONDON@YALEVM ********* CCNEWS is a weekly electronic magazine for campus computing center newsletter editors. In it they discuss common interests and concerns about delivery of news and information. These include desktop publishing, printing, operational aspects of developing newsletters, writing, and computing-related issues relevant to campus computing center information dissemination. Even if you are not a newsletter editor, but are interested in desktop or electronic publishing, CCNEWS holds a wealth of information. A typical piece of information: "Over the years I have discovered that the programmers and consultants here generally think they already know how to write. However, often what I get from them is not necessarily what I want nor in the form/ style I use in Õmy newsletterå. Also, many of them take issue when their contributions are edited into completeness and conformity. I think the programmers and consultants here do not view writing for Acronyms as one of their job requirements and would rather stick to what they like doing -- programming and front-line consulting. Before developing a seminar to teach these folks a new skill, I would make sure they wanted to learn!" Listserv has also enabled the CCNEWS staff to develop an "Articles Archive" of material submitted by subcribers and available for downloading for research or reprint (with proper attribution, of course). The Archive currently contains items on topics such as piracy, viruses, electronic networking, stylesheets, microcomputer maintenance, etc. You can receive a list of thes articles by sending the following command to LISTSERV@BITNIC via mail or message: INDEX CCNEWS. 1 Page 10 Likewise, you can subscribe to CCNEWS by sending the command: SUB CCNEWS Your_Full_Name - Institution. For example: SUB CCNEWS Henry Chmielewski - Yale University ********* * * LYRICS - The Song Lyrics Server * * * * by the Lyrics Manager * * * * University of Massachusetts * * * * LYRMAN@UMASS ********* LYRICS@UMASS is a file server storing song lyrics. It accepts commands by mail only. The format for a request from the lyrics server is as follows: Command/param1=option/param2=option/param3=option There are 3 commands available for requests. Lyrics - prints lyrics Albums - prints album titles and authors Songs - prints album titles, authors, and songs on albums These commands will accept 3 parameters. /Author=xx restricts search to work of author xx /Album=xx restricts search to album xx /Song=xx restricts search to song titled xx Examples: Albums/Author=Peter Gabriel lists album titles of Peter Gabriel Lyrics/Album=So prints lyrics of any album entitled So Songs/Album=So lists all songs on any album entitled So Lyrics/Song=Red Rain lists lyrics of any song entitled Red Rain 1 Page 11 Multiple parameters are also valid. For example: Lyrics/Album=So/Song=Red Rain lists lyrics of a song Red Rain that is on album So Albums/Author=Peter Gabriel/Song=Red Rain lists album by Peter Gabriel that contains song Red Rain Requesting Lyrics: To make a request to the server, simply type the appropriate command line in the body of a message to LYRICS@UMASS. If you would like to make a request from the server, a good place to start would be sending just Albums (The Albums command with no parameters) which will list all album entries. Multiple requests can be made in one letter by typing each command set on a separate line. The subject line is ignored by the server. The server checks for mail every ten minutes, so a response shouldn't take any longer than that under most circumstances. Network replies obviously depend on other factors as well. Some requests may entail lengthy responses. Users with minimal file space should be aware of this. Note: a * next to a song title indicates that it is an instrumental, or no lyrics are available for it. Advanced help is available by typing HELP/option where option is one of the following available topics: FORMAT - instructions for contributing lyrics SEARCH - describes the wildcard string search capability Contributions are always encouraged and appreciated. Please send all questions, comments, corrections, additions, and whatnot to: Lyrics Manager, LYRMAN@UMASS. * ******************************************* ******************************************* * * ******************************* ******************************* * 1 Page 12 ********* * * PHSERVE - The UIUCVMD Phone Book * * * * by Charley Kline * * * * University of Illinois * * * * KLINE@UIUCVMD ********* PHSERVE@UIUCVMD is a database of faculty, students, and staff at the University of Illinois at Urbana-Champaign. The server accepts interactive BITNET message (not files or mail) and looks up names in an online copy of the phone book at the University of Illinois at Urbana-Champaign. Specifying a single name will look up entries with a first last, or email name. Specifying multiple names will force returned entries to match each name given. By default, queries are assumed to refer to the name field of the entry. Therefore, a query of "john doe" looks for entries whose name contains "john" and "doe." Fields other than the name field must be specified. For example, "dorner address=DCL" would return entries which contained "dorner" in the name and whose address contained "DCL." Matching is done on a word-by-word basis. That is, both the query and the entry are broken up into words, and the individual words are compared. Although the nameserver is insensitive to case, it otherwise requires words to match exactly; "john" does *NOT* match "johnson," for example. Only entries that match *ALL* of the specifications in the query are returned. For example, "charles kline" will return all entries with *BOTH* "charles" and "kline" in the name field. Note in particular that this query is identical to "kline charles." A certain set of fields are returned by default. It is possible to ask for different fields in a query. This is done by specifying the "return" keyword, and listing the fields of interest. For example, a query of "steven dorner return email" would return only the electronic mail address of Steve Dorner. Results are returned by BITNET interactive messages if the reply is sufficiently short; otherwise they are sent in a file called "PHSERVE REPLY." Queries may contain any combination of the so-called metacharacters, *, ?, and Õå. Metacharacters can be used to 1 Page 13 specify wildcards or alternates within a query. People familiar with UNIX will recognize these metacharacters as identical to those recognized by the UNIX shell. The metacharacter "?" represents exactly one unknown character. Thus, "johns?n" matches "johnson" and "johnsen" but not "johnsenn." The metacharacter "*" can be used in a request to indicate zero or more unspecified characters. For example, "kl*e" will match "kline", "klemme", and "kluge". Be warned, however, that queries resulting in too many matches will be refused. Square brackets represent a match of one of the characters inside the brackets. For example, "johnsÕoiån" will match "johnsin" and "johnson" but not "johnsen" or "johnsoin." For examples and more detailed information, send PHSERVE@UIUCVMD the command "?". ********* * * Headlines * * * * Smaller specks of news... * * * * ...but not unimportant! * * * * Send them to BITLIB@YALEVM ********* * Hey!: Please remember that the file server NYSHARE@WEIZMANN will only accept commands sent by interactive message, not mail. Too many mail messages will result in a server shutdown. * Listserv news: Goz Lyv tells us of yet another FILELIST. The HELPCONV filelist on LISTSERV@BYUADMIN stores (what else?) the HELPCONV software package. * Mike Roberts, Vice President, Networking, EDUCOM: "I am very sorry to announce that Judy Molka will be leaving the BITNIC staff in August so that she can pursue a Master's degree in the Univ of Pittsburgh Telecommunications program. Her talented and dedicated contributions to BITNET are known far and wide. I am sure you will join me in wishing her well as she takes this important career step. We are mailing a position announcement for a Network Services Consultant to replace Judy to all BITNET Institutions Representatives. We solicit applications from all qualified individuals. If you are not an 1 Page 14 IR and would like a copy of the position announcement, please contact Elizabeth Kilcoyne of the BITNIC staff (KILCOYNE@BITNIC)." * TRICKLE: A copy of the TRICKLE file server has been installed in Denmark. This server is the same as the one described in the May issue of NETMONTH by Turgut Kalfaoglu (TURGUT@TREARN). Our TRICKLE can be contacted on (TRICKLE@DKTC11). TRICKLE provides you with directory listings and file from the SIMTEL20 personal computer software archives. To get in touch with TRICKLE you can send it the command /HELP. Thanks to Alan Jacobsen for this update. * NICSERVE@BITNIC is being replaced: All files in this directory are now available through LISTSERV@BITNICs NETINFO FILELIST. Please use LISTSERV@BITNIC in the future to obtain these files. On September 1st 1988, NICSERVE will no longer have access to these files, instead a note recommending the use of LISTSERV@BITNIC will be the only response to commands. Since the BITNIC Staff cannot change the format of the NETINFO FILELIST (because certain operations of the server are tied into the format of the index), the following procedures have been initiated to support both old and and new index formats. They will presently maintain the hand-edited NICSERVE INDEX and a newly created NETINFO INDEX (an exact copy of the NICSERVE INDEX), along with the NETINFO FILELIST. After the September 1st replacement of NICSERVE by LISTSERV, the files NETINFO INDEX and NETINFO FILELIST will be maintained. To get the "old" format index, you can do one of 3 things: Send the command INDEX to NICSERVE@BITNIC. Send the command GET NICSERVE INDEX to NICSERVE@BITNIC. Send the command GET NETINFO INDEX to LISTSERV@BITNIC. To get the "new" format index, you can do this: Send the command INDEX NETINFO to LISTSERV@BITNIC. Send the command GET NETINFO FILELIST to LISTSERV@BITNIC. Again, after September 1st, commands sent to NICSERVE@BITNIC will not work. * ******************************************* ******************************************* * 1 Page 15 ********* * * Helpdesk - a Question and Answer column * * * * by Marc Shannon * * * * Carnegie Mellon University * * * * Send your questions to HELPDESK@DRYCAS ********* Well, here I am! All ready for my first column! (I've always wanted to be in "print", but I had figured that it would be on a National Security Administration print-out.) I guess I'll just jump right in... *Q* How does interactive messaging affect file transfers on BITNET? *A* Messages, either as a "message" between two users (with or without Relay) or as a "command" from a user to another node on BITNET, can be considered as small, urgent files. As a file is being transmitted on a BITNET link, it is broken up into packets. These packets are used to fill up a "block" on one computer and are then transmitted to the other computer. When a message is to be transmitted across that link, it is inserted into that block (taking up the space that a file packet might have used). More messages, less file packets. This is why, generally, large files may take overnight to be transmitted across heavy-traffic links (such as PSUVM-CUNYVM). During the day, many small files (such as mail files) are enqueued and get sent before the larger files. Then, in the evening and early night, people get on Relay and send messages (quite a few) across these links. Some large files may not get a chance to begin transmission until two or three o'clock in the morning. *Q* Besides RELAY, what other services does BITNET provide? *A* BITNET provides one of the best services just in its existence: the ability to communicate (either online with messages or offline with mail) to friends and colleagues across the WORLD. (Mithrandir and I spend time occasionally just marvelling at the power we have at our fingertips.) (Ed. note: BITNET is really just the United States. The larger-scale NJE network includes BITNET, EARN (Europe), NetNorth (Canada), and AsiaNet.) The file BITNET SERVERS (sent along with NetMonth and available in the archive locations listed at the end of this magazine) 1 Page 16 lists many, if not all, of the servers running on BITNET. Through the file servers and mailing lists available, you'll find many things to do. *A* (additional) to last month's question "Can all nodes on BITNET send and receive interactive messages?" It has come to our attention that there are non-IBM programs available that can be installed which allow TSO users to send and receive interactive messages. If you would like to receive more information about this, send mail to HELPDESK@DRYCAS and we'll pass the information on to you. ********* * * New Mailing Lists * * * * from List-of-Lists * * * * by Rich Zellich * * * * ZELLICH@SRI-NIC.ARPA ********* AIX-L This list is intended for the discussion of the AIX operating system, IBM's Unix solution for small and large computer systems. Initially, this list will be used for dissemination of information and technical details of AIX on all levels. It may be necessary to break this list down into machine types that AIX will run on. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to the Moderator. Moderator: Michael R. Gettes ANDREW-DEMOS A mailing list to be used simply for demonstrations of the Andrew system software. You should not subscribe to it unless you expect to be reading it with the Andrew Message System, as messages will come to the list in full multi-media format. Indeed, we encourage people to post lots of neat animations, music, raster images, and the like to this list. To be added to the list, send mail to ANDREW-DEMOS- 1 Page 17 REQUEST@ANDREW.CMU.EDU. To submit new items to the list, just send them to ANDREW-DEMOS@ANDREW.CMU.EDU. Coordinator: Nathaniel Borenstein ANTHRO-L This list deals with discussions of various techniques and fields of research in Anthropology. Some suggested topics of discussion are: - Computation in anthropology - Graphics in archaeology - What programs anthropologists are using at various places - Where centers of computer interests are in anthropology - Anglo-Saxon cemeteries - Palaeodemography - Some spirited words on political economy - The development of Anglo-Saxon cemeteries - The Northumberland landscape - The population of Anglo-Saxon England To add yourself to the list, send the following command to LISTSERV@UBVM via mail or message: SUBSCRIBE ANTHRO-L Your_Full_Name Coordinator: Patrick G. Salsbury BMDP-L Discussion group for users of BMDP software. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to one of the Coordinators. Coordinators: Michael Walsh Sander Wasser CONS-L This group provides a forum for university computing centre consultants to discuss such issues as problem tracking, resource management, training, and consulting strategies. 1 Page 18 All requests to be added to or deleted from this list, problems, questions, etc., should be sent to one of the Coordinators. Coordinators: Michael Walsh Sander Wasser ENVBEH-L Mailing list on Environmental Behavior: Environment, Design, and Human Behavior. ENVBEH-L is a discussion on a variety of topics concerning the relations of people and their physical environments, including architectural and interior design and human behavior, environmental stress (pollution, catastrophe) and behavior, human response to built and natural settings, etc. To subscribe, send the following command to LISTSERV@POLYGRAF via mail or message: SUB ENVBEH-L Your_Full_Name. Coordinator: Tony Monteiro IFPHEN-L Discussion group on Interfacial Phenomena (Group 1c, American Institute of Chemical Engineers). Meetings, articles, software, theories, materials, methods, tools, etc., are discussed. To subscribe, send the following command to LISTSERV@WSUVM1 via mail or message: SUB IBMTCP-L Your_Full_Name. Coordinator: Richard L. Zollars MBA-L The MBA-L student curriculum discussion mailing list is for any information or news about MBA programs, their administration, problems, issues, questions, etc.; it is intended for administrators, faculty, and MBA students. To subscribe, send the following command to LISTSERV@MARIST via mail or message: SUB MBA-L Your_Full_Name. Coordinator: Bob Comerford 1 Page 19 STAT-L An open discussion group dealing with statistical consulting at university computing centres. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to one of the Coordinators. Coordinators: Michael Walsh Sander Wasser VIRUS-L Mailing list for the discussion of computer viruses. The discussion originally focused on IBM PC viruses but Mac, and other types of, viruses are sometimes discussed as well. Archives are available, as is a file called DIRTY DOZEN which lists a number of viruses, trojan horses, and pirated programs for the IBM PC. To subscribe, send the following command to LISTSERV@LEHIIBM1 via mail or message: SUB VIRUS-L Your_Full_Name. Coordinator: Jig Shaffer, Jr. * ******************************************* ******************************************* * * ******************************* ******************************* * * ********************************************************** ********************************************************** * * ****************************************** ****************************************** * 1 Page 20 ********* * * Feedback * * * * a Letters column * * * * "Back in the USSR?" * * * * Send your letters to BITLIB@YALEVM ********* From: Ted Herman Subject: Suggestions I'd like to offer some ideas for NetMonth: 1. I've seen several recommendations of "Toward an Ethics and Etiquette for Electronic Mail" in issues of NetMonth. Yes, a PREscriptive work on the manners of electronic mail is a worthy effort and I can well understand why you recommend it. But I'd also like to see, on a continuing basis, DEscriptive work on the manners of electronic mail. I'm no anthropologist, but I'm entertained by comments like: > I'd be interested to know the mix of people who squaked > on USENET. What kind of users are they on USENET? ... USENET, on the other hand, was always the "wild and wooly" bunch. Much less quick to "authoritarian" standards -- much more libertarian in the belief that not only does EVERYBODY have an opinion, but that it is one's DUTY to express that opinion. ... If one goes to "usenix" one sees "typical" college students in the majority -- sandles, shorts and t-shirts. If one goe to "/usr/group" one finds the "typical" business type -- shoes, long slacks and Grateful Dead T-shirts. ( the above excerpted from a recent letter in UG-L ) 2. On much the same theme, I would REQUIRE that announcements and reviews of mailing lists contain edited portions of typical letters. Have you noticed how samples included in reviews of Whole Earth Review enhance the reviews? I find that a "Time- Life" keyword abstract of a mailing list's masthead doesn't show me the personality of the list. Wouldn't it be nice to 1 Page 21 see some typical samples, synopsis of recent topics and controversies, rather than go to the trouble of subscribing and finding out for yourself? Usual disclaimer/apology: please accept these comments as constructive criticism, I do not mean to deprecate your effort, keep up the good work, rah rah rah, etc. *Editor's Note* Unfortunately there are several obstacles in providing such a service (although it would be nice). First, the lists we announce are new, so there would be often little, if anything, to review. The big problem however, would be that the length of these reviews would add to an already too-large NetMonth. Keep the ideas coming! From: David Benson Subject: Addresses I find most of NetMonth very interesting and I appreciate that the articles are signed with names. But I find it frustrating that only BITNET addresses are used. UA1VM doesn't tell me much. Maybe I should know where Craig White comes from, but I'm a relative newcomer to BITNET and don't. Maybe I'm not supposed to know where Craig White comes from, but why? Tim Stephen's article on the problem of user ids makes a good point, and I THINK his address means he is from Rensselaer Poly, but I'm not sure. Would it take too much space to include "real" addresses or at least identifiers for NETMONTH contributors? *Editor's Note* See changes this issue. From: Dave Phillips Subject: Bring BITNET to the USSR? A recent article in Netmonth suggested that efforts be made to bring BITNET to the USSR. This would be a great idea if and only if access to the links at the Soviet side were not rigidly controlled and rationed to "reliable" people. A more workable trial might be Poland, which has a much freer society (despite the authorities) than the USSR's, a *very* Western popular outlook, a large number of young people eager to work with computers, and (like the USSR) a good percentage of students know English and/or other European languages. 1 Page 22 Since Poland has entered the International Monetary Fund, and since the PPR has (like the USSR) participated nominally in signing and reiterating the Helsinki accords when convenient, it would be of great interest to see if the PPR regime would accept an uncensored linkage to BITNET, e.g., via neighboring Sweden. From the PPR government's viewpoint, they would have to weigh the consequences of further 2-way flow of information with the computer know-how to be gained from Western scientists, technologists, and students. The decision made would most likely be a technocratic one, unless the Soviets make the decision (veto) for Warsaw. From: Gabriel Basco Subject: Bring BITNET to the USSR? About getting the USSR into BITNET. Great Idea!!!! But one little, if they don't let Western News go in, how are they going to allow a whole bunch of wild people like the ones that use BITNET, talk with their students. NO WAY!!!!! From: Dave Gomberg Subject: Communicating Steve McClusky (sp?) writes recently about those who have little or no reason to use a BITNET connected machine frequently, and thus do not receive mail promptly. This is indeed a problem. It is analogous to a situation where I might rarely (or never) check my US mailbox. The solution for this case is not to hire someone to check my mailbox, but to advise correspondents that they should not expect to reach me by US mail. If you are at a BITNET institution, but do not access your mailbox regularly, do not advertise a BITNET address as effective for reaching you. Advertise those techniques that are effective for your behavior patterns (US mail, phone, or whatever). If you elect not to use your BITNET address, that is your prerogative, just as it is your choice to have or not have a fax or a phone. It is not the responsibility of the telephone office to take messages for you and send them to you by courier if you elect not to have a phone. It is not the responsibility of your BITNET site to pass material on to you should you elect not to be a BITNET participant. Please do not expect the computer folk to be your messengers. 1 Page 23 From: Terence Sommerville Subject: Answering unread mail In last month's issue of Netmonth Stephen McClusky takes up the issue of people not answering their VM mail. He suggested that perhaps the local computer centers might generate a daily paper postal listing of who has mail so as to save the time of logging on for those that rarely have time to check their mail. I wish to suggest a slightly different possible solution for the same problem. What if someone wrote a program to scan all the mail as already suggested last month, but then to display this information all day on one or two dedicated terminals at the main doorways to the campus and perhaps in the library. In addition it might be better if people were also allowed decide whether they wish to be included or excluded from the daily scans of all the mail. In addition a dedicated server on each node could also hold this data, so that if you were to see a friend of yours logged on they could query the system for you thus saving oneself the hassle of getting them to logoff while you "quickly" logon to check. However for some places that could afford it the one or two terminals could be expanded to cover either every major entrance and or regular meeting places such as main notice- boards, the canteen/restaurant or perhaps even the college bar! If one or two sites implemented such as system as above or the system using the paper listing for a trial period then it might give an indication as to whether it would be worth the effort. For the long term I feel that it is essential to get the "non- computer" people to use BITNET and to prove they can benefit from it. In this way whenever the issue of funds or money came up with respect to the site contribution to the network, then we would not have competing groups for a given amount of money, but rather the whole community would be unanimous on this particular issue. In the past it has been seen on BITNET as new programs and facilities are added new possibilities for network use are opened up, which increasingly bring in new users that would not otherwise dream of going near a terminal. At the end of the day this question of answering unread mail can only be answered if the whole task of inter-facing to the "non-computer" type can be made steadily easier to the point that these people will then want to regularly check their Readerlist. In effect the job of the normal postal system has to be emulated in that the mail has more or less to be handed to them on a plate. To do this by computer printouts would in the long term only generate masses of paper most of which just makes the whole thing more confusing, thus defeating the purpose of stream-lining and simplifying communications. 1 Page 24 From: Tony D'Angelo Subject: Listserv REPRO (self copy) Option A while back I started inquiring why the sender of a posting to a list maintained by LISTSERV did not receive a copy of his/her message posting, even though every other member of the list did. Thanks to Jim Gerland (who contacted Eric Thomas) we found out that there is a LISTSERV distribution option called "REPRODUCE = YES" which will implement this self copy feature. The owner of the list cannot make a current list REPRO but he can make it REPRO for anyone who signs up after he changes the LISTSERV header for a given list. Also, the owner as the capability to change each current member's distribution option to REPRO = yes. I would like to suggest that future LISTSERV software revisions have "REPRODUCE = YES" as the default condition when creating a list (if this hasn't already been done). I think everyone would always want to receive a copy of his/her posting to a list, just to see how it looks, if and when it got distributed, if there are any gross errors in the message, etc. Also, as time permits, I would like to suggest that all list owners at the various locations where LISTSERV is being run change the distribution option of each member of their existing lists to make them REPRO capable and change the list headers to "REPRODUCE = YES" for all future subscribers. In the meantime, individual users can send the SET REPRO command to any LISTSERV@ of which they are a member to activate the self copy feature for themselves. To remove this feature the syntax is SET NOREPRO. Reminder: the SET command is sent to the *LISTSERV* @ and *not* the . * ******************************************* ******************************************* * * ******************************* ******************************* * * ********************************************************** ********************************************************** * * ****************************************** ****************************************** * 1 Page 25 ********* * * NetMonth Policies * * * * Everything you ever wanted to know... * * * * ...but were afraid to ask. * * * * BITLIB@YALEVM ********* NetMonth is a network service publication distributed free of charge to students and professionals in BITNET and other networks. This magazine and its companion file, BITNET SERVERS, are the work of the BITNET Services Library (BSL) staff and contributors from around the network. BITNET SERVERS is BITNETs list of servers and services. If you know of servers not listed in BITNET SERVERS, or if some listed are no longer available, please contact the NetMonth Editor. * Subscribing to NetMonth and BITNET SERVERS: Send the following command to LISTSERV@MARIST by mail or messgage: SUBSCRIBE NETMONTH Your_full_name Internet users may use this method, but must address the mail to LISTSERV%MARIST.BITNET * Back issues: BITNET users may get NetMonth back issues from the file server LISTSERV@CMUCCVMA. The FILELIST for these archives is aptly named NETMONTH FILELIST. Send the command INDEX NETMONTH to the server for a list of files. A subscriber can delete him/herself from the mailing list by sending LISTSERV@MARIST the UNSUBSCRIBE NETMONTH command. * Letters to the Editor: If you have questions or comments about BITNET or NetMonth that you would like to see printed here, mail your letter to BITLIB@YALEVM. Make sure that you specify in the "Subject:" header or somewhere in the letter that it is for the NetMonth letters column. * Article Submissions: The only requirements for NetMonth articles and columns are that they be informative, interesting, and concern some BITNET-related topic. Send your articles and to BITLIB@YALEVM. 1 Page 26 * 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 accepted by your printer. _ __- __--- The __----- BITNET __------- Services ___________ Library "Because We're Here." ***************************************************************