******** ************************************************** * * * * * The independent guide to BITNET * * * * * * March, 1988 * * * * * * Volume 2, Number 9 * ******** * * * * *** * * * * * * * * * * * * * * * * * * ** * * * * * * * * * * ****** * * * * * * * * * * ******** * * * * * * * * * * * * * * * * * ******** * * * * *** * * * * * * * * * * * * * * *** * * * * ****** * * * * * * * * * * * **** * * * * * * * * * * ****** * * * * * * * * * * ******** * * * * * * * * * * * **** ************************************************** 1 * * * * * ** * * ** ** * * * * * * *** ***** * * * * *** **** ***** **** * * * * * * * * * * * * * * * * * * * ***** * * * * * * * * * * * ** * * * * * * * * * * * * * **** * * * *** * * * * * ***** ****** Christopher Condon Editor CONDON @ YALEVM Mike Patrick Contributing Editor PATRICK @ 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 19 ******************** EDITORIAL PAGE_________________________________________________ Bitnotes .................................................... 1 The Human Factor ............................................ 3 Forty-two ................................................... 8 Comments of a So-so Happy Crossnet User ..................... 9 Flames To: ................................................. 11 FEATURES_______________________________________________________ NetCon88 ................................................... 13 foNETiks ................................................... 15 The DECWRL Archive Server .................................. 16 CDNet and EAN .............................................. 18 DEPARTMENTS____________________________________________________ Headlines .................................................. 20 Helpdesk ................................................... 21 Feedback ................................................... 22 Policies ................................................... 23 * 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 1 Page 1 ********* * * Bitnotes * * * * by Christopher Condon * * * * CONDON@YALEVM ********* "You can't get there from here." I have a large, yellow notebook in my bookcase, filled with notes and printouts from my first months in BITNET. There are old node lists, documentation on long-forgotten servers, early issues of FSFNET... a treasure trove of network history. You might say that the notebook is the beginning of all we have come up with in the past few years. Everything from Bitlist to NetWeek has it's origins in those tattered pages. When looking through those printouts, I realize how much the network has changed over the past few years. Oh, it has grown, to be sure, but there are other, less obvious, changes to consider. The very way in which we access information in BITNET has been altered... dependant upon the actions of a relatively small number of individuals. For example, take LISTSERV (please). In little over a year it has become the dominant type of server in BITNET, changing drastically the way we communicate. It has made mailing lists and forums the norm rather than the exception. Previously there were a few well-informed people who belonged to ARPANET mailing lists (SF-LOVERS and INFO-NETS come to mind), but the vast majority of people knew nothing of these. The most common information resources were file servers and electronic magazines. Enter, stage left, LISTSERV. The first BITNET list server was developed and installed by BITNIC. It worked fairly well but did not receive much in the way of support or accolades. Enter, stage right, Eric Thomas at FRECP11 and his improvement on the concept of the mailing list server. What he added (among other things) was the ability for a mailing list to exist at multiple servers by "peering" the lists. People could subscribe to a list at a LISTSERV close to their node, rather than subscribe at a cental location. This spread out the load which would be caused by a mailing list, rather than bog down the links around a central list server. 1 Page 2 More importantly, the spread of these servers made mailing lists accessable to everybody. You'd like to start a forum for people interested in pond scum? Contact the coordinator for a a nearby LISTSERV and ask him about it. You want to subscribe to an ARPANET mailing list? There is a LISTSERV nearby where you can send your request. The growth in mail volume over BITNET has been tremendous. All of this might not have happened if Eric Thomas hadn't decided to improve upon the original LISTSERV concept. PERHAPS someone else would have thought of it, and PERHAPS someone else would have taken the time to produce such a server, but I doubt it. A similar turn of events took place a few years earlier. Henry Nussbacher took the time to point out the weaknesses and problems with single-node conference machines. Jeff Kell took it upon himself to address these problems. Today we have the Relay Conference Machine system, allowing real-time BITNET conversations among groups of people (as opposed to only two people). These and other contributions by a few determined people have changed and improved the way we access information in BITNET. They have, in fact, become prime selling points in promoting the use of the network. I am not suggesting that these Eric Thomas and Jeff Kell did this on their own. There are many people who have worked very hard to build and support the Listserv and Relay systems we have today. However, the initial effort, sacrifice, inspiration, (whatever you want to call it) was theirs alone. This is keeping with the original spirit of BITNET: A network where most of the development and support were provided on a voluntary basis. It is to the people who gave their time while the network was growing that we owe round of thanks, a pat on the back, a pedestal on which to stand, praises sung it jazz harmony.... Now that I have established the religion, allow me to play Devil's Advocate and trample on it. Where does this voluntary effort lead us? Some applications get extreme attention (Listserv) while development on others doesn't get a second thought? Who decides what services are important enough to work upon and which ones are not? Are we held by the whim of a Rexx programmer somewhere who may or may not decide to develop the next major server? If he/she doesn't do it, will someone else? 1 Page 3 What if someone builds an alternative to Listserv that is better, faster, and more efficient? Will a working Listserv network be dismantled? Who would supervise the transition? Would there be any, or would the idea die on the vine, crushed by the popularity of the current system? To but it bluntly: Who will coordinate servers and services in BITNET? Who is planning the future of BITNET, if at all? Who is at the helm? Virtually, Chris Condon@YALEVM ********* * * The Human Factor * * * * by T. D. Stephen * * * * STEPHEN@RPICICGE ********* Last month, in an aside during my discussion of BITNET's culture and its specialized language, I challenged readers to find a common language equivalent for that ghastly phrase, so familiar to many who use BITNET on CMS systems, "spool your virtual punch to rscs" (in fact, what one actually types is "sp pun to rscs cl m"). I'm sorry to report that that challenge has not been satisfactorily met. The one attempted translation I received took half a screen and began with "Send your electrons...". It was an interesting effort, but nothing beginning with "Send your electrons..." is quite what we are after. "Spool", I understand, is actually an acronym for "Simultaneous Peripheral Operations On-Line" and provides a good example of how fantastically obscure network communication concepts can be. Not only is "simultaneous peripheral operations on line" entirely without meaning for anyone who is not a computer specialist (try turning conversation toward "simultaneous peripheral operations on-line" the next time your family gets together), but it's acronym, "spool", actually misleads in its apparent association with the weaving trades. "RSCS" ("Remote Spooling and Communications Subsystem"), the other acronym in 1 Page 4 that phrase and a gem in its own right, at least doesn't steer you wrong in its associations. Since it has no vowels, it can be readily filed as just another vague acronym. Requiring users to type "spool pun to rscs cl m" before sending mail over BITNET is linguistic tyranny, pure and simple. It is a bit like the public schools requiring children to recite the pledge of allegiance. In many cases young children may not understand the significance of what they are uttering and may not even get the words right. But they do understand that it is somehow important that they engage in the ritual. Similarly, anyone interested enough in BITNET to make the effort learns that, whether "sp pun to rscs cl m" ultimately means anything or not, it's the right thing to type. From the user's point of view, being required to type "sp pun to rscs cl m" is no more sensible than being required to chant "nasa flapjack to naacp form 1040a" before being allowed to use the rest room. Primitive computer concepts like "sp pun to rscs cl m" are not unique to IBM CMS computers. Try a Unix system sometime if you want to experience this phenomenon at its hair-raising worst. There, when you want to see a list of the names of all of your files, you type "ls"; when you want to see the names of all of the files that contain the word "flapjack," you type "grep flapjack." Even more awe-inspiring in its obscurity, in its utter disregard for common sense, in its sheer nose-thumbing at the user's frame of reference -- to list the contents of a particular file on your screen, you type "cat" followed by the name of the file (the new user wonders if typing "dog" will send the file to the printer). The newcomer to BITNET confronts a maze of obscure concepts, a fog of "techno talk" that we simply have to lift if BITNET is to become a useful tool. You can argue, if you wish, that every academic specialty requires newcomers to learn unfamiliar terms and obscure ideas and you would be correct. Even in human communication studies newcomers confront "sememe", "kinemorph", "pentad", "talkover", and "double interact" to mention only a few. But BITNET is meant to be a service, not a discipline of study. And in order to be a useful service, it needs to communicate with its users in a manner that they understand and find familiar. Not long ago computer communication systems were used almost exclusively by computer scientists and engineers and it is sensible that the language system they evolved to work with the technology would reflect their own habits of thought and economies of expression. In fact, the creation of the "spool" 1 Page 5 process marked an important technological advance and its metaphoric reference to winding threads around a cylinder is not inappropriate given what actually occurs when computers "spool" things (thanks to John Fisher, RPICICGE, and David Chess, IBM Yorktown, for this information). However, now that the technology has moved from the specialized domain of computer scientists and has been placed in service as a communication medium for as diverse an audience as exists in higher education, there is a profound need to translate its operational concepts to ones that are appropriate for people with little time and sometimes, I'm afraid, little interest in computer science itself. To accomplish this, many sites have obtained or created software that protects users from having to confront primitive commands like "sp pun to rscs cl m". Here at RPI's Center for Interactive Computer Graphics, for example, we can type "Bitnote" and a much friendlier program comes alive that handles sending mail over BITNET without the user ever having to type or even think about "sp pun to rscs cl m". The Bitnote program also packages the mail in a way that saves the user from having to learn about RFC822, the "standard" for network mail. This is a good thing because reading about RFC822 is enough to drive anyone from BITNET for life. (The RFC822 document is available from Nicserve@Bitnic as file RFC822 STANDARD, but take my word for it, you'd rather read your income tax forms.) Though many sites provide Bitnote or an equivalent program, there are others that do not and in some cases, though such programs are provided, not enough has been done to let users know that they exist. The University of Connecticut maintains a program named "Memo" that is similar to Bitnote but to use it, users have to create a "link" to a detached "virtual mini- disk" and then "access" the disk. Although a little program is provided to help users to do this, the extra step is apparently enough to keep people away. Most of the mail that my colleagues from Uconnvm send continues to arrive in non- standard formats. Comserve users from a number of other sites seem to be similarly disadvantaged. "Bitnote" is a particularly good name for that program because its associations imply its purpose -- Bitnote is used to send "notes" over "BITNET". Bitnote comes easily to both the tongue and the fingers, and is not built upon obscure words or concepts like the Unix "cat" command. "Cat" is, in some strange way, short for "concatenate", a word that should have been avoided since "join" or "combine" could have done as well and are far more commonly used (of course, the fact that 1 Page 6 listing a file on your terminal screen has nothing whatever to do with joining, combining, or concatenating anything is another problem). The suffix "serve", derived from "file server", as in "Netserv", "Nicserve", "Bitserve", "Comserve", etc. is also a poor choice, although I think it is here to stay. Serving is a weak metaphor for what these programs actually do and "file servers" are something that computer specialists relate to, not ordinary people, not the educational and research community that BITNET ostensibly is in place to serve. "CSNews" was an excellent choice for an information service for computer science and "Relay" a defensible choice for a method of relaying messages. The choice of "Listserv", however, was a mistake for a service that is, potentially, the most valuable asset of BITNET. People rarely aspire to belong to "lists" and if the name has any metaphoric value at all, at best it suggests that Listserv is where one goes to get lists of things, which, of course, it is not. A similar system that is available to local users on RPI's MTS system is called "Forum" -- a much better name. The social entities that form via Listserv are sometimes referred to as "groups", sometimes "conferences", and sometimes just "lists" (as in "I'm a member of the Mail-L list"). Obviously, people do not form into "lists", but, perhaps less obviously, what occurs via Listserv does not much resemble what happens in group or conference interaction either. Our feeling at Comserve was that what usually happens on Listserv is more like what happens on hotlines than anything else -- people use them to deliver news or write asking for help; others respond with advice or opinion. Since we switched to calling our "lists" "hotlines," we've found it easier to orient faculty and students to the service. I think it a failure of foresight that so many computer commands and programs have been inappropriately named. Anyone who has brought a child into the world -- or has been close to new parents -- knows how much care and thought goes into the selection of a name. We all recognize that the name we choose will influence the way that the world relates to the child throughout life. Why has this simple truth been so often ignored in the realm of computers and technology? Why, for example, was a sophisticated file transfer and terminal communications program, "Kermit", named after a frog puppet? What did the authors of "Grand" hope to accomplish by naming it that? What did the Unix community have in mind when they chose "finger" as the name for a command that tells you who another user is? Did they expect that Unix would be popular among mobsters? 1 Page 7 Even in the choice of the name "BITNET", it would seem that the desire to communicate our technological orientation outweighed whatever advantage might have been gained by choosing a name that said something about the network's purpose or user population (but perhaps this wasn't clear during the network's beginnings). Interestingly, the Europeans chose differently: "EARN" stands for "European Academic and Research Network". "BITNET" is a jazzier acronym than "EARN". But when you unpack it ("Because It's Time Network") it is unclear what it communicates except, God forbid, that we are the network for Ernest and Julio Gallo's production vineyards. BITNET's limitations and problems are often discussed with reference to its technology. Items such as queue sizes, transmission speeds, limitations in the RSCS network protocol, and ambiguities in the RFC822 standard are frequently identified as key problems, the solutions of which are not self-evident, cheap, or easily implemented. However, the quality of service provided by BITNET could be improved substantially, quickly, and at little cost if only we would give more consideration to the frames of reference that characterize the population that BITNET serves. Immediate gains could be made if the names of the commands and services that are related to using the network were brought in line with the language of every day life. Perhaps Shakespeare did us a disservice when he had Juliet question whether Romeo Montague would be any different if he had been named something else ("What's in a name? That which we call a rose by any other name would smell as sweet."). Frankly, if he had been named "Sp-pun-to-rscs-cl-m Montague" I doubt if their romance would have ever gotten off the ground. ************************************************************* * * * * * * * * * * * * * * * * * * * * * * * * * * ************************************************************* 1 Page 8 ********* * * Forty-two * * * * by Mike Patrick * * * * PATRICK@YALEVM ********* "I'm goin' down, down, down, down." - Bruce Springsteen Hello boys and girls. Welcome to my neighborhood. Today we are going to learn all about "links". Can you say "links"? I knew you could! A link, as defined by the dictionary, is "anything connecting a single part of a series or chain". Therefore, those meaty, cylindrical wads of pig flesh you eat for breakfast are "sausage links". Those cloudy pictures of Bigfoot and the abominable snowmen for which Leonard Nimoy is always searching are called "missing links". The things that connect Relays from all over the world are called "Relay links". These are the focus of our lesson today. To illustrate the operation of BITNET "links", let's talk to our friend Mr. Mudface. You remember Mr. Mudface, don't you, boys and girls? TELL RELAY Hello Mr. Mudface! How are you today? FROM YALEVM(RELAY): Hi, Mike. What do you want? TELL RELAY Well, I thought you might talk to us about "links" FROM YALEVM(RELAY): ]signoff] User MUDFACE @ MUD (Mr_Mudface) TELL RELAY Mr. Mudface? Hello? Mr. Mudface? Well, boys and girls, it looks as though the links went down again. We'll have to talk to Mr. Mudface about links another time. FROM YALEVM(RELAY): ]signon] MUDFACE @ MUD (Mr_Mudface) Oh! He's back! Now we'll find out about "links"! TELL RELAY Hi! How about telling us all about "links" now? FROM YALEVM(RELAY): Sure, Mike. I'll tell you FROM YALEVM(RELAY): everything you need to know about them. TELL RELAY How come they keep going down, Mr. Mudface? FROM YALEVM(RELAY): ]signoff] User MUDFACE @ MUD (Mr_Mudface) 1 Page 9 They're down again. Oh well, boys and girls. I think we've covered enough ground on the subject of "links" for today. Can you say, "AAAAAAARRRRGGGGGGHHHHH! The links went down again!!!!" ? I knew you could! Next time, I'll teach you how to sell Cheerios to your friends by telling them they're doughnut seeds. Until then, bye boys and girls! ********* * * Comments of a So-so Happy Crossnet User * * * * by Eric Keller * * * * R34334@UQAM ********* I've used BITNET for about a year now and I'd rate my satisfaction with BITNET fairly high. But sending messages across the network boundaries is still downright hazardous. I'd like to suggest a number of ways to improve a service which is bound to become increasingly important as time goes on. First some background: I teach at a large, urban university in Canada and run a research lab on speech processing. I use the nets between four and six times a week to exchange messages with colleagues in Canada, the US and Europe. I receive three network bulletins, including NetMonth. I regularly (attempt to) send messages to other networks, particularly EDU, Janet, Internet and NetNorth. Recently, I have set up a SIG for the phonetic sciences and my e-mail volume has gone up considerably. I have 15 years' computer user experience on a variety of large, medium and small machines and have as many years' experience as a programmer with languages ranging from Z80 assembler to C and LISP. All that to say that I'm quite used to dealing with computer- related problems. I never give up on the first try and always try again. Still I have found networking, and especially contacting people on other networks, to be a particularly resistant problem. I'll give a few examples. 1. Mail to an EDU address was returned with "addressee unknown" (or words to that effect) because the SENDGATE EXEC converted lower case into upper case and the destination node required lower case. Fortunately, the CROSSNET EXEC preserves case and was able to do the job instead. 1 Page 10 2. Colleagues from the FR network in France can get mail to me, but I haven't found a way of getting mail back to them. No luck trying to use the return address marked on the message by BITNET. 3. I have a colleague on NETNORTH, a Canadian academic network who sent me a reference last Monday evening and it got to me Wednesday noon. The irony is that his lab is only about 10 miles away from mine. 4. As of late January, the version of CROSSNET on our mainframe was still trying to channel mail to EDU via WISCUM. So I tried to see if I could get a newer version from the Guelph University LISTSERV (CANADA01). I got as far as the NETSERV REFCARD. When I requested GET NETSERV FILELIST, or GET PROGRAMS FILELIST (as instructed by the REFCARD), or GET CROSSNET EXEC, or GET SENDGATE EXEC, I got the message "no such file on LISTSERV" (or similar). Foiled again. As it turned out, the newest version of CROSSNET EXEC was added to the LISTSERV about two weeks later and it now handles EDU and JANET okay. But the point is that for a while, there was a very frustrated network user out there. Someone less used to trying and trying again might well have given up a long time ago. 5. And finally a site-internal problem. We have a mail facility on our Amdahl mainframe that cuts off the last letter of long, but legal BITNET names. As a result, letters to perfectly well- specified addresses are returned as "addressee unknown". I now use SENDFILE to send out texts that are either uploaded or created with XEDIT to get around that problem. And so it goes. Once you know how to navigate around the major obstacles, mail within BITNET is reasonably fast and reliable. But crossing the gulf to the other networks is hazardous at best. The promise is there, but the delivery is, well, mediocre. How can the service be improved? First of all, we need a reliable, more complete and up-to-date mail exec. From the user's point of view, that's priority number one. We don't like delays, but we can live with them. Undeliverable mail, on the other hand, is wasted time and energy. From what I can figure out, neither SENDGATE nor CROSSNET can presently handle access to ALL networks that BITNET/EARN is connected to. So some work needs to be done to update one or the other or both of these execs. And let's be clear: don't expect users to have to specify anything more than userid, node and network. That's it. No backwards-forwards 1 Page 11 ordering of pathnames, for instance. Simply, an exec that does ALL the work for us, and that prompts us for the necessary information if it has to. Second, all BITNET users should have easy access to an up-to- date version of such an exec. The best way to do this--and I am quite unequivocal about this--is to make them available on the nearest LISTSERV. On-site servicing is spotty in many institutions, and the LISTSERVs are the natural places where interested users should be able to obtain their execs. Third, attack the strange phenomenon of one-way crossings. There are few frustrations greater than being able to listen, but not being able to speak. Being able to receive mail, but not being able to send it is a close second. Concretely, that means: pay someone for a summer to build or adapt an easily maintainable exec that handles all the networks and that provides all the necessary prompts, and make sure it gets posted to all LISTSERVS. Then tell us all about it, and maintain the exec religiously. I wonder if that couldn't be put somewhere very high on the BITNET development priority list. ********* * * Flames To: * * * * by Craig White * * * * CWHITE@UA1VM ********* Hello again, How many folks were able to find a copy of Toward an Ethics and Etiquette for Electronic Mail this past month? If you did, I hope you'll return it to the library promptly so that others may enjoy the thoughts that it provokes. This month has flown by for me and quite frankly, I've had trouble keeping up with my incoming mail. A couple of times this month I've ended up with over 200 unread files in my incoming box. I noticed in the mail that I was able to read that a lot of people have begun to include a disclaimer in their mail-list transactions. I hope more people will adopt the practice. I sometimes have paranoid thoughts about things and a recent one surrounds mail-lists. It goes like this: When you send something out for public distribution, you are volunteering 1 Page 12 information about yourself to the world at large. Imagine your chagrin when a prospective employer at an interview pulls out a folder with laser printed copies of several of your more choice submissions to ETHICS-L and asks is this really how you think about thus and so? Or worse yet what if you don't get the interview for the same reason as above? Oh well, on to the good stuff. First order of business: I notice that a lot of mail seems to be generated with a story line like "brand Y's computer is better than brand Z's computer (or operating system)." It seems to me that this kind of message is totally uncalled for. At my site for instance, we recently changed from brand Y's computer to brand Z's computer. There were the typical kinds of "wish we could just keep on using Y's" and the "this Z can't do this like Y's computer would". Now that brand Y's computer is no longer available and hasn't been for sometime, this kind of talk seems to have died down and more people are focusing on how to get the results that they want out of the Z computer. I suppose what I'm trying to say here is that instead of wasting your precious time and energy coming up with that one argument that will convince all those brain-dead Z computer users to see the light and make the switch to Y, you should try to get most out of your Y, and let the Z users do the same. In addition to your brain bandwidth, our net bandwidth can probably use the break just as much as my bit-bucket key can. Spelling Checkers: One of the things that surprises me is the number of misspelled words that go out on mail-lists. I am willing to bet that over 97 percent of the computers on BITnet have a spelling checker. The questions is why don't people use them? If you haven't already noticed, I have this thing about the appearance that you project to people, and using a spelling checker is one of the ways that you can make sure that your appearance is enhanced. It seems to me that some questions posed to mail-lists get more responses than others. I think that a carefully worded, correctly spelled query is more likely to get responses than one that is poorly constructed and full of misspelled words. At times I'm really surprised at the mail on the lists from people you look up to, like system programmers, node administrators, and bright programmers whose mail is full of misspelled words. I think that that one simple maneuver would certainly enhance the effectiveness of the answers that you submit. Flames to me: Now that I have ranted and raved about spell checkers let me flame myself this month about a typo I sent out in last month's Flames To. I noticed, too late of course, that I had typed an l for an I. My spelling checker on this stupid 1 Page 13 Z didn't catch it. This month I'm using a different spelling checker and it will catch that kind of thing, I hope. Now will it also help out on verb tenses? Well, its spring break time here in Alabama and I've about run out of fuel for the flames this month. I'll be here next month and as always if you have questions, comments or flames about this column send them to CWHITE@UA1VM. ********* * * NetCon88 * * * * by the NetCon Committee * * * * NETCON-L@NCSUVM ********* NetCon(tm) is a "con" or a mini-convention that is planned and coordinated by computer users, like yourself, whose main link is the BITNET. NetCon88 offers you a chance to meet the "face at the other end," meaning that you can finally meet the people to whom you have spoken on Relay, CSNEWS, or directly. NetCon88 allows you to meet many of these people at the same time, in the same location (convenient, eh?). You also have the opportunity to visit a new city and take in the sights. NetCon88 will also feature speakers whose topics range from the birth of the Relay to the future of the networks (BITNET, NetNorth, EARN,the InterNet, etc.). * Time and Place: NetCon88 will take place May 27-30, in Tempe, Arizona. * Travel Information: Piedmont Airlines has been designated as the official carrier for the attendees of the NetCon, May 27 - 30, 1988, in Phoenix, AZ. Piedmont agrees to offer an exclusive, low fare for the attendees. This special fare will offer a 5% savings off any published Piedmont promotional round trip fare for travel within the Continental United States, providing all rules and restrictions are met. For attendees unable to meet the restrictions for promotional fares, Piedmont will offer a 35% discount off the standard round trip day coach fare for travel within the Continental United States, and a 25% discount for travel from Canada. Additional restrictions apply for discounts on international travel. 1 Page 14 These convention discounts are valid between May 24 and June 2. To obtain this convention discount, you or your travel agent must call Piedmont's Convention Sales office at 1-800-334-8644; from North Carolina and Canada, 1-800-251-5720, Ext. 2224; from Bahamas, 1-800-423-8814, Ext. 2224; Monday through Friday, 8:30 AM - 6:00 PM, Eastern Time. If you prefer to travel by train, you should phone Amtrak at 1-(800)-USA-RAIL. They should be able to help with scheduling and costs. Also if you are planning to drive to NetCon please send a note to Reba Taylor (REBAT@VTVM1). She is trying to help people get to NetCon with low travel expenses. If you need a ride or can offer a ride or be of help, it would be greatly appreciated. Please do not wait too long, or a good opportunity might be missed. * Hotel Information: All meetings and lodgings will be at the Sheraton Tempe Mission Palms Hotel. This hotel is not far from the Phoenix airport, and is only blocks from the Greyhound bus depot. The hotel is near the downtown area of Tempe, so there are shops, restaurants, and nightclubs in the area. Rates vary, depending on the number of persons in the room: 1-- $50 per night, totalling $150 + tax for the weekend. 2-- $25 per night, per person, totalling $75 + tax. 3-- $18.34 per night, per person, totalling $55.02 + tax. 4-- $15 per night, per person, totalling $45 + tax. A deposit of one night's lodging must be sent to us when you register for NetCon88, so that we can make your room reservations for you. (see below) * Registration Fees: The following fees must accompany your NetCon88 registration. $15 (or more) -- One night's lodging for room deposit. $15 -- NetCon88 registration fee. $ 5 -- Membership fee in NetCon(tm) Society. You should mail this to: Bill McBrayer 518 W. Howe St. Tempe, Az 85281 You should also send Bill a note at C9M5R@ASUACAD notifying him of your intentions to attend NetCon. 1 Page 15 ********* * * foNETiks * * * * by Eric Keller * * * * R34334@UQAM ********* There was much acclaim when I first proposed the idea of a network newsbulletin for the phonetic sciences to some colleagues at the November 1987 Western Hemisphere Conference of IsPhS. Seated around a big, round table at the Villa Capri Restaurant in Miami Beach were the unwitting founding members of the bulletin: (in alphabetical order) George D. Allen, Claire Gelinas-Chebat, Jim Flege, Terence M. Nearey, Kim Silverman, and myself. We quickly came up with the name (foNETix - which I unilaterally chose to adapt to foNETiks, mostly in deference to the IPA, but also to prevent abusive comparisons with ASTERIX), and we took note of some of the items foNETiks should carry: current information about hardware and software available for phonetics, current abstracts in the phonetic sciences, perhaps current titles in phonetics-related journals, info on phonetics meetings, and (gulp) phonetic humor. Back in Montreal, I drew up a short description of the Bulletin. I envisaged two versions, a network version in ASCII characters only, and a printed version of Macintosh laser printing quality, with the possibility of printing phonetic characters as well as illustrations. I sent the description into the four winds via the electronic academic networks and via snail mail. For addresses, I used a mailing list we use at our research center, plus the address list I gathered at last year's Franco-British phonetic sciences meeting in Brittany, France. All told, I sent off well over 100 notices. I figured that if the thing took off, I would send further copies out to all members of ISPhS (the International Society of Phonetic Sciences) and AAPS (the American Association for Phonetic Sciences). Then I sat back for a month. The responses trickled in. After a month, some 10 people wished to have the electronic version of the bulletin. None had subscribed to the printed version. There were some hints that there might be some contributions to come, but as of January 8, I had essentially no material to print. Clearly, the tremendous effort required to put out two versions of the bulletin was not in keeping with the response shown to the pre-announcement materials. So I drew up a "Sorry, foNETiks is dead" letter and sent it out to everyone who had contacted me. 1 Page 16 The response was interesting. Several people wrote back and suggested that instead, we set up an informal mailbox bulletin. I would simply act as a distributing center and everyone who wanted to could send me contributions. My only responsibility would be to copy all the information into one bulletin and to send it out. Okay, why not, I thought. At least till my next sabbatical in 1991, I can indeed collect the info and push it out again via the academic networks to all those who would like to have it. In other words, I would be a moderator, and not an editor. And in 1991, we can see what happens. To subsscribe to foNETiks, send mail R34334@UQAM. To contribute to foNETiks, send your material to the same address. Optionally, you may send your material by regular mail to the address given in the title bar. Your text should be unformatted, i.e., contain no extra spaces, and should be written using the ASCII 32-127 set only. This means, no accented characters, underlines, etc. You can expect your text to be included, pretty much no questions asked, in the next issue of "foNETiks". ********* * * The DECWRL Archive Server * * * * from the DECWRL documentation * * * * ARCHIVE-SERVER@DECWRL.DEC.COM ********* ARCHIVE-SERVER@DECWRL.DEC.COM is a mail-response server. This means that you must send all commands to through electronic mail. Each command you send ARCHIVE-SERVER must be the first word on a line. The archive server reads your entire message before it does anything, so you can have several different commands in a single message. You can use any combination of upper and lower case letters in the commands. The archives are organized into a series of directories and subdirectories. Each directory has an index, and each subdirectory has an index. The top-level index gives you an overview of what is in the subdirectories, and the index for each subdirectory tells you what is in it. 1 Page 17 COMMANDS: HELP: The command HELP or SEND HELP causes the server to send you a help file. No other commands are honored in a message that asks for help (the server figures that you had better read the help message before you do anything else). INDEX: If your message contains a line whose first word is INDEX, then the server will send you the top-level index of the contents of the archive. If there are other words on that line that match the name of subdirectories, then the indexes for those subdirectories are sent instead of the top-level index. For example, you can say INDEX or INDEX PROGRAMS or INDEX RECIPES You can then send back another message to the archive server, using a SEND command (see below) to ask it to send you the files whose name you learned from that list. SEND: If your message contains a line whose first word is SEND, then the archive server will send you the item(s) named on the rest of the line. To name an item, you give its directory and its name. For example: SEND RECIPE AFRICAN-STEW or SEND PROGRAM RCKEEP Once you have named a category, you can put as many names as you like on the rest of the line; they will all be taken from that category. For example: SEND RECIPE CHOC-SHIP-1 CHOC-CHIP-2 CHOC-CHIP-3 NOTES: The archive server acknowledges every request by return mail. If you don't get a message back in a day or two you should assume that something is going wrong. Don't send mail with long lines. If you want to ask for 20 recipes in one request, you don't need to put all 20 of them in one "send" command. The archive server is quite able to handle long lines, but before your mail message is received by the 1 Page 18 archive server it might pass through relay computers that will choke on long lines. FAIRNESS: The archive server contains many safeguards to ensure that it is not monopolized by people asking for large amounts of data. The mailer is set up so that it will send no more than a fixed amount of data each day. If the work queue contains more requests than the day's quota, then the unsent files will not be processed until the next day. Whenever the mailer is run to send its day's quota, it sends the requests out shortest-first. If you have a request waiting in the work queue and you send in another request, the new request is added to the old one (thereby increasing its size) rather than being filed anew. This prevents you from being able to send in a large number of small requests as a way of beating the system. If you request 10 recipes together, you will get substantially higher priority than if you make 10 requests for 1 recipe each. The reason for all of these quotas and limitations is that the delivery resources are finite, and there are many tens of thousands of people who would like to make use of the archive. ********* * * CDNnet and EAN * * * * from the NETSERV documentation * * * * NETWORKS FILELIST ********* This is third in a series of articles about other networks. CDNnet is a Canadian academic network based on the ISO model for Open Systems Interconnection and in particular the CCITT X.400 Recommendations on Message Handling Systems (MHS). CDNnet presently has approximately 50 sites at 20 institutions across Canada. The MHS software is a distributed message system called EAN. EAN has been under development at the University of British Columbia since late 1981. A prototype system was operational immediately after the Draft X.400 Recommendations became available in December 1983, and Version 1 of EAN has been available since early in 1985. The project is funded by the Natural Sciences and Engineering Research Council of Canada (NSERC). 1 Page 19 EAN comprises a User Service, a Message Transfer Service, and a Directory Service. The User Service is implemented as a collection of User Agents (UAs). The User Service through its UAs assists in the preparation, posting, reception, and storage of messages. A number of types of UAs are implemented, including a mail program, a distribution list program, and a "remote pipe" service. Database and file transfer services are under development. The Message Transfer Service is composed of a collection of Message Transfer Agents (MTAs) located throughout the network, with each MTA being responsible for receiving messages from and delivering messages to a number of UAs. MTAs also perform routing, transfer messages reliably, and provide interim storage as required. The Directory Service maps names to addresses. It also optionally maintains a profile for each registered name including such information as home and office addresses, telephone numbers, and a personal description. As well as being used in CDNnet, the EAN software forms the basis for academic networks in several other countries including Norway (UNINETT), Sweden (SUNET), Switzerland (CHUNET), and West Germany (DFN). The software is also being used in CERN, Italy, Great Britain, Netherlands, Spain, South Korea, and Australia. The per-CPU licence fee for educational/research use of EAN is $500 Canadian for Canadian sites and $1500 for others. EAN is commercially available from Sydney Development Corporation in Vancouver, British Columbia. CDNnet addresses are of the form: user@subdomain.cdn For example: FRED@EAN.UBC.CDN Information about EAN and CDNnet is available from . ************************************************************* * * * * * * * * * * * * * * ************************************************************* 1 Page 20 ********* * * Headlines * * * * Smaller chunks of news, but not unimportant... * * * * BITLIB@YALEVM ********* * Relay news: Users of CSRLY@VTVM2, please be advised that the server has been renamed to the network-standard RELAY@VTVM2. * SERVER@TAMCBA is no more: A message from Rick Troth: "SERVER at TAMCBA received almost nil usage for a number of months. That, coupled with a shortage of disk space, (what else is new?) prompted us to take it down." Archives for PSYCHNET magazine which were stored on SERVER are also stored on LISTSERV@TCSVM. * A NETMONTH Filelist: Marc Shannon has set up a FILELIST on LISTSERV@CMUCCVMA for NetMonth and NetWeek archives. For a list of files, send the following command to the CMUCCVMA LISTSERV via mail or message: INDEX NETMONTH * Please note: Remember that all servers do not accept commands by mail. Some, such as NYSHARE@WEIZMANN, only accept interactive messages. Changes are being made to BITNET SERVERS in order to provide this information. * The OS9 Filelist: In addition to the COCO (Tandy Color Computer) FILELIST, LISTSERV@PUCC now offers an OS9 FILELIST. The files there are usable under the OS-9 operating system. More information is available by requesting the files CURRENT INFO and COCO MEMO from LISTSERV@PUCC. To get a list of files, send the server the command INDEX OS9. Thanks to Eric W. Tilenius for this information. * Another MACSERVE: As of 20th February MACSERVE@IRLEARN began providing services identical to MACSERVE@PUCC. The server at Princeton will no longer serve sites on the European side of the Atlantic. This should help in reducing unecessary trans- atlantic traffic. * Whois: The /WHOIS name modification has been added to two more list servers: LISTSERV@CMUCCVMA, and LISTSERV@UCF1VM. This LISTSERV also running the /WHOIS name server feature. 1 Page 21 ********* * * Helpdesk * * * * a Question and Answer column * * * * Send your questions to BITLIB@YALEVM ********* *Q* Who should be informed when chain letters are received through BITNET? *A* Most chain letters come from people who simply do not know any better. When I recieve a chain letter I chastize... er... explain to the sender why this is NOT an intelligent thing to do (generally citing network load). Since sending chain letters does not break any specific BITNET rules (it is merely stupid and annoying) I wouldn't make a big deal out of it (that just generates more mail!). *Q* I just entered TELL LISTSERV AT CMUCCVMA INDEX NETMONTH and got back: FROM OHSTMPA: REJECTED BY TASK VMA -- PREVIOUS COMMAND ACTIVE What "previous command" (I haven't sent an cmd message in that direction for DAYS)? Why is Ohio State sticking its oar in anyway, the "command" isn't for it (have we got some sort of RSCS conflict message here)? If this is some sort of bug, who do I gripe to about it? *A* from Marc Shannon: It's not your fault. The error message you got is a common one on busy links. What it means is that the internal RSCS queue of messages is full and cannot store your new message until there is room. The "Previous command active" is not necessarily yours. The only thing to do is either wait about 10-15 minutes and try again or send the request via mail. *Q/A* Here is an update on sending binary files by Karl Noell: Besides UU-coding there is still another methode: BOO-coding mainly used to distribute Kermit bin-files. These encoding schemes converts every three consecutive bytes into four printable characters, blowing up the filesize by at least 33 percent. If you intend to ship any binary stuff between two IBM Hosts, it's best, to transfer those files "as is" by SENDFILE in NETDATA format, which ensures a reliable transparent transmission. 1 Page 22 ********* * * Feedback * * * * I love fan mail... * * * * Send your letters to BITLIB@YALEVM ********* From: Richard Lee Holbert Subject: NetWeek, NetMonth Just wanted to repeat my thoughts that you and your co-workers are doing a great job. The NetWeek mail has really been helpful and interesting and fits right into the NetMonth with such ease that it is not noticeable. Keep up the fantastic work!!! From: Juan M. Courcoul Subject: The January and February NetMonth Several quick notes for Netmonth, done in a hurry cause I have class real soon and I didn't want to miss the deadline ! First, I wanted to congratulate you for NetMonth's new format and regular features. They're great !! The editorial and the section "The Human Factor" were very good, in the January issue. I hope we can see more articles on that vein, because it's very true that BITNET is grossly underutilized by the undergraduates, who could get much more from it. I've also tried to circulate the issue as much as possible here at my campus, as well as the Mexico State and Queretaro campus of our system, in an attempt to promote the net's use. Last of all, congrats. for the NetWeek idea ! Neat, also. I guess it's a lot of work, but I'm sure all your avid readers (like myself) really appreciate the effort. Thanks for your time and dedication. From: Rita Saltz Subject: Whew! Pretty fancy issue there! Tim Stephen turned out to be a good idea, huh? Really replete and most of it Other People's Prose, and new stuff at that. Nice job. 1 Page 23 ********* * * NetMonth Polices * * * * Everything you ever wanted to know... * * * * 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 list server LISTSERV@CMUCCVMA. For a list of issues, send the following command to the server via mail or message: INDEX NETMONTH 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 24 * 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." ***************************************************************