******** ************************************************** * * * * * The independent guide to BITNET * * * * * * July, 1988 * * * * * * Volume 3, Number 1 * ******** * * * * *** * * * * * * * * * * * * * * * * * * ** * ******** * *************** * * *************** * * * ************** * ****** * ************* * * * ************ * * * ************ * * ********** ********* ******** * ********* *************** * * ******** ************** * * * ******* ************* * * * ****** ************ * * ****** *********** ******** * ***** ********** ************** ******** **** ********* ************* * *** ******** ************ * *** ** ******* *********** * * * * ****** ********** * * * * ***** ********* ********* * * ***** ******** ************* * *** **** ******* ************ * *** ****** *********** * ****** ** ***** ********** * * * **** ********* ***** * * *** ******** ************* * **** ******* ************ * **** *** ****** *********** * ** ***** ********** * * * **** ********* ****** * * *** ******** *************** ****** *** ******* *********************** * ** ****** ****************************** * * ***** ************************************ * **** ***************************************** ******** *** ********************************************* * ** ************************************************ * * ************************************************** * **************************************************** **** ************************************************** 1 * * * * * ** * * ** ** * * * * * * *** ***** * * * * *** **** ***** **** * * * * * * * * * * * * * * * * * * * ***** * * * * * * * * * * * ** * * * * * * * * * * * * * **** * * * *** * * * * * ***** ****** Christopher Condon Editor CONDON @ YALEVM Timothy Stephen Associate Editor STEPHEN @ RPICICGE Craig White Associate Editor CWHITE @ UA1VM Wendel Bordelon Contributing Editor TACVRWB @ TCSVM June Genis Contributing Editor GA.JRG @ STANFORD David Hibler Contributing Editor ENGL0333 @ UNLVM Henry Mensch Contributing Editor HENRY @ MITVMA Deba Patnaik Contributing Editor DEBA @ UMDC Gerry Santoro Contributing Editor GMS @ PSUVM Marc Shannon Helpdesk Editor HELPDESK @ DRYCAS Glen Overby Technical Assistant NU070156 @ NDSUVM1 Gary Moss Pillar of Virtue MOSS @ YALEVM ******************** Contents - Issue 23 ******************** EDITORIAL PAGE_________________________________________________ Bitnotes .................................................... 1 Flames To: .................................................. 7 Bringing BITNET to the Eastern Bloc ......................... 3 FEATURES_______________________________________________________ The NeWS Archive SErver ..................................... 9 The UTC Name Server ........................................ 10 DEPARTMENTS____________________________________________________ Headlines .................................................. 13 New Mailing Lists .......................................... 12 Feedback ................................................... 17 Policies ................................................... 20 * 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. * ----------------------------------------- 1 Page 1 ********* * * Bitnotes * * * * by Christopher Condon * * * * Yale University * * * * CONDON@YALEVM ********* "Your kindness will never be obliterated by your good looks." FSFnet 12/84 - 08/88 When I was first learning about BITNET, Dave Liscomb was distributing an announcement of his electronic magazine, the Fantasy and Science Fiction Network (FSFnet). These were the days when the network was small (a few hundred nodes) and there were no list servers or Relays. Come to think of it, there was no NetMonth, or Bitlist, or BITLIB. There was only VM/COM, a computer science interest magazine distributed by the people who ran CSNEWS. If I remember correctly, Dave was a staff member of that publication. Here was Dave, starting out a magazine of his own. I found out about in the typical way that people found out about those things in BITNET-1984. When I was learning about the CSNEWS file server, I added myself to the legendary Bitnauts List. Dave sent out his announcement to everybody in Bitnauts who said they had an interest in Fantasy or Science Fiction. It seems that I was one of those people. About this time, many of you are thinking, "Big deal. I have not the slightest interest in Science Fiction or Fantasy." You might not realize the important role that FSFnet has played in the development of the network. FSFnet was the first BITNET electronic magazine with a subject matter having absolutely NOTHING to do with computers. While you may or may not care for the topic, Dave Liscomb showed that the network could be an effective form of communication for people interested in non- computer topics. This served as the inspiration for the early BITNET magazines, many of which are still in production today. There was NutWorks (humor), CRTNET (communications), Bitlist... 1 Page 2 Bitlist, the weekly predecessor to NetMonth, was, of course, based on a computer-related topic. Early on, however, FSFnet served as the inspiration for producing an electronic magazine. Later, when Bitlist became NetMonth, FSFnet was the model of consistency and quality I hoped to achieve. Dave is leading the network now, and FSFnet will cease publication. He has made arrangements for the startup of a new magazine to carry on FSFnet projects (see Headlines). I cannot help but feel, however, that these are, in network terms, deaths (hence the eulogy tone of this editorial). When Dave leaves BITNET that will most likely be the last contact I have with him. He has been a pioneering networker and a good friend. Still, we must not think of this as an end, but as a beginning. He is going on to a far better life... The network will go on without Dave Liscomb and FSFnet, a little less whole because of their absence, better because of thier presence. *************************************************************** I have some good news and some bad news. The good news is the staff listing you see on the second page of this issue. The people there have generously offered their time and talents to keeping NetMonth going. I, of course, am going to take full advantage of them.... er... this. In the coming months you will see that the various features and news items will be carry their bylines. Their contributions will increase the quality and timeliness of the magazine. The bad news is that there will be no NetWeek this summer. There just hasn't been enough news to justify sending one out every week. Rather than cancel the whole thing, we will simply start it up again when the fall semester begins. Call it a summer vacation. Since this lack of news happens every summer, we will no doubt go on vacation again next year. Virtually, Chris Condon@YALEVM 1 Page 3 ********* * * Flames To: * * * * by Craig White * * * * University of Alabama * * * * CWHITE@UA1VM ********* Hello once again, I have had a very nice month, hope you did too. A couple of times during the month, parts of the net that were important to me were down for long periods of time, but, overall it was a good month for my networking activity. I am really having problems with mail as there are more lists that I feel I need to read to keep up with the technical aspects of my life. This just means that my allotted time for mail is pressed to it's limit. Unfortunately, I've had to unsubscribe to some of the more esoteric digests that often make my day a little brighter. It seems I am becoming a solely technical person. Maybe I'll just resubscribe and allot a little bit more time for mail so that I can have time to relax with some non-computer type mailing lists. I've been meaning to address this for some time now but I just keep forgetting to put it in the article: I appreciate all the mail I get from people who read the column and I do read every one. Normally, I do not respond to those of you who write but this by no means indicates that I'm not interested in what you think. I think many people have noticed that I've used gripes of theirs in my columns and when I feel that it's absolutely necessary that you get a response I do send one off. I'm sorry that I'm not able to answer every letter that I get but I promise I take what you say seriously and I do read and use ideas that are sent to me. This months flame is about the flood of mailings that often occur following a large posting, a multiple list posting and often flames. What I'm talking about is the many follow-up posting to the effect of; "I had to discard that note from XX number of lists that I'm on and I'm sick of seeing that piece of mail"; Or, "I wish so and so would take their gripes off the list and discuss them privately." I hate to discard multiple posting and I also get tired of discarding personal flames. 1 Page 4 This particular topic is a very hard one for me because, on the one hand I think that the way changes in net behavior occur is for fellow networkers to write and gently chastise each other for behaviors that they think are inappropriate or that violate the official rules of conduct. On the other hand, sending these to the list costs a lot in terms of traffic, especially when it is made public via a list. It seems that somehow these proddings need to be private. Unfortunately, by doing this we are not allowing newcomers to the net world an opportunity to find out what the unspoken rules of the game are. At the moment with our current network saturation level, we cannot afford to allow a few to learn at the expense of others. Therefore, I am recommending that if a person makes an inappropriate posting and you feel the need to flame them, please make it private. If 10 people feel the need to make the same flame then fine. If it's private, there are a lot less copies of that flame moving around. This could really add up on some of the more popular lists. Finishing up, I think that when someone posts something that is inappropriate we should GENTLY (that means without insulting someone's intelligence, family, family to be) chastise that person PRIVATELY about their behavior. You will want to be sure to include logical arguments and possible alternative actions rather than blast them for their error. It was brought to my attention this month that LDBASE COM (the LDBASE program for the VAX) is not yet available. I do not know the current status of this project but maybe there will be more news about this next month. As always questions, comments, and Flames should be sent to CWHITE@UA1VM. 1 Page 5 ********* * * Bringing BITNET to the Eastern Bloc * * * * by David J. Hibler * * * * University of Nebraska-Lincoln * * * * ENGL0333@UNLVM ********* Jason Ohler's provocative article ("Let's Bring BITNET to the Soviet Union") in the May issue of NETMONTH has already elicited comment, but much more still needs to be said. Personally, I think the proposal is a very sound one, and I had toyed with suggesting the same a few months back but never got around to writing up the ideas. I'd like to thank Ohler for bringing the issue into public view so it can be discussed more widely. The fundamental assumptions behind Ohler's proposal are certainly quite valid. It is in the best interests of everyone if we can find ways for direct and peaceful interchanges with the Soviets rather than military ones. And he is quite correct in asserting that advances in modern technology have bridged previously insurmountable barriers of physical distance. Yet let us not be naive about what may be one of the most profound obstacles to be overcome before such an exchange becomes possible: the seemingly insurmountable barriers of political paranoia, hostility and intransigence on BOTH sides of the ocean. Ohler asserts that "to allow BITNET to become the same kind of force that it has become in the west is asking a lot from a government that has presided over an information constrained culture for half a century," thus implying that the Soviet government would be the one which felt most threatened by any such exchange. In his June commentary on the article, Dave Phillips picks up this theme and develops it even further by asserting, "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." Both are generally correct in acknowledging the existence of previous Soviet restraints on the flow of information, though there is certainly no better time than the present to test whether or not glasnost and perestroika have truly altered the Soviet landscape. But both are incorrect if they mean to imply that the Soviet government is the only government which might have reservations about a computerized linking of our cultures. 1 Page 6 For just as crucial as the question of Soviet resistance is the question of U.S. roadblocks to such a venture. Recent years have seen direct Presidential interdictions on the exchange of high-tech with the Soviets. Our government seems acutely sensitive to the transfer of computer-based technologies, for it is particularly in this area that we enjoy a commanding lead on the Soviets. Put in simple terms, it is quite possible that some people in our government might see a BITNET link with the Soviets more as a threat to our national security than as a means of advancing intercultural dialogue between our respective peoples. And if we are to be perfectly honest, such fears are not entirely groundless. As we all are quite aware, even the people who invent systems do not always know how they will be applied or what capabilities they might eventually assume. For proof, simply look at the way in which BITNET or e-mail in general have evolved in only a few short years. And once the technology is in place, who is really in a position to control what is sent out over it? Such an information transfer would no doubt be a two-way street. Just as the Russian bureaucracy might tremble at the implications of its citizens in direct link with the West because of the social implications, so the American bureaucracy will no doubt tremble at the ease with which sensitive databases might end up in Soviet hands. In my mind, the opportunities are well worth the risks, for personally I feel we will be in a much better position to impress their citizens with our friendliness, our openness, our excitement, and our eagerness to learn--and to be similarly impressed in turn by their own citizens--than the Soviets will be to steal secrets which they'd otherwise probably pilfer eventually anyway. But more is needed now than merely raising the idea. Someone must take up the standard and advance the issue, keeping in mind that there will undoubtedly be resistance from both governments. As the issue is advanced, there must be a comprehensive strategy which will allow both sides to explore the implications of such an exchange without suffering any loss of face. Such a strategy might contain at least some elements of the following proposal. First, General Secretary Gorbachev should be approached, probably through the cultural liaison at the Soviet Embassy, and asked directly whether or not his view of glasnost would permit communication via computer by students and professors at Soviet universities with their counterparts at American universities. If he responds negatively, there is really 1 Page 6 little point in pursuing the matter any further at this time. For if the principal architect of perestroika is not in favor of the idea, don't expect any of his subordinates to advocate it. But if he responds positively and indicates at least a willingness to discuss the matter further, then the monkey will be on our back and we will need to confront those who are about to be in power as to their intentions in this regard. Notice the careful phrasing of that last sentence, for there is little point in initiating discussions with an American administration which has less than a half-year left. But there might be much point in presenting such an issue to the two Presidential contenders and seeing if substantive differences in this regard exist between the major parties. Indeed, such an inquiry might even make an interesting addition to a Presidential debate--for we've listened to the candidates belabor the other issues for months now, but we've heard precious little about how either party might go about improving the cultural and educational climate between our respective peoples. Some closing notes. Ohler cites an American professor who has managed to establish e-mail links with his Soviet counterparts, but does anyone know of any other instances? In particular, does USENET have any such links? Finally, why should we limit ourselves only to Soviet links as Ohler suggests or to Polish links as Phillips counterproposes? Why not simply advance the concept of opening the entire Eastern bloc to BITNET access? And why stop there? How about the mainland Chinese? Are they to be ignored? We fashion ourselves a "world-wide" network, but isn't it time we took steps to live up to that billing? 1 Page 7 ********* * * The NeWS Archive Server * * * * by the NeWS Archive Manager * * * * Sun Microsystems * * * * MANAGER-NEWS-ARCHIVE@SUN.COM ********* The NeWS Archive Server at Sun Microsystems (NEWS- ARCHIVE@SUN.COM) is a mail-response program. That means that when you mail a request to the server, it will mail back a response. The file server does not perform extensive error checking. If you do not send the server commands that it understands, the response will be: "I don't understand you." The file server has several commands. Each command must be the first word on a line. The file server reads your entire message before it does anything, so you can have several different commands in a single message. The file server treats the "Subject:" header line just like any other line of the 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, as does each subdirectory. The top-level index gives you an overview of what is in each of the subdirectories, and the index for each subdirectory tells you what it contains. If you are bored with reading documentation and want to try something, send the server a message containing the line: SEND INDEX APPLICATIONS When you get the index back, it will give you the names of all of the application program files in the archive. Next, send the server another message asking it to send you the files that you want: SEND APPLICATIONS SUNCLOCK You should send the commands to NEWS-ARCHIVE@SUN.COM. 1 Page 8 Commands: The four server commands: HELP command: The command HELP (or SEND HELP) causes the server to send you the 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 command: If your message contains a line where the first word is INDEX, the server will send you the top-level index of the archive contents. If there are other words on the line beginning with INDEX that match the name of subdirectories, then the indices for those subdirectories are sent instead of the top-level index. For example, you can say: INDEX or INDEX APPLICATIONS or INDEX DEMOS You can then send another message to the file server, using a SEND command (see below) to request the file(s) that you learned from the response to the INDEX command. INDEX APPLICATIONS and SEND INDEX APPLICSTIONS mean the same thing. That is, you can use the SEND command instead of the INDEX command, if you want, for getting an index. If your message has an INDEX or a SEND INDEX command, then all other SEND commands will be ignored. This means that you cannot get an index and files in the same request. (This is so index requests can be given high priority.) SEND command: If your message contains a line where the first word is SEND, the server will send you the item(s) named on the rest of the line. To name an item, you must specify its directory (category) and its name. For example: SEND DEMOS COLORTABLE or SEND APPLICATIONS SUNCLOCK Once you have named a subdirectory (or category), you can specify more than one item on the rest of the line. They will all be retrieved from that category. For example: SEND DEMOS COLORTABLE SLIDER CLIENT 1 Page 9 Each SEND command can reference only one subdirectory. For example, if you would like to be sent one demo and one application, you must use two SEND commands: one beginning SEND DEMO and the other beginning SEND APPLICATION. You may put multiple SEND commands in one message to the server, but the more items you request, the longer it will take to receive. (See "FAIRNESS" below, for an explanation.) The number of send commands is limited. If the server must use uucp mail to send your files, then it cannot send more than 100K bytes in one message. If you ask for more than it can send, the server will send as much as it can and ignore the rest. Notes: Don't send mail with long lines. If you want to ask for 20 files in one request, you don't need to put all 20 of them in one "send" command. The file server is quite able to handle long lines, but before your mail message is received by the file server it might pass through relay computers that will choke on long lines. Fairness: The file 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 shortest requests 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. The reason for all of these quotas and limitations is that the delivery resources are finite, and there are many people who may like to make use of the archive. 1 Page 10 ********* * * The UTC Name Server * * * * by the UTC Name Server Manager * * * * University of Tennessee * * * * UTSERVER@UTKVM1 ********* UTSERVER@UTKVM1 is a service machine written by the University of Tennessee Computing Center to provide additional PROFS services. The main function of UTSERVER is to update an on- line electronic mail directory, and to perform housekeeping and cleanup functions associated with this electronic mail directory. The University of Tennessee Computing Center electronic mail directory contains user name, userid, and BITNET node information for non-student UTCC timesharing accounts. It may contain additional information, including the user's department abbreviation and office telephone number. Users on one of the University of Tennessee Computing Center BITNET nodes can issue commands (via BITNET) to delete their entry from the electronic mail directory. All BITNET users can issue commands to search for entries in the electronic mail directory. All BITNET users can search the directory for string arguments by issuing one of the following commands. From a VM/CMS host, the command is: TELL UTSERVER AT UTKVM1 FIND string From a VMS host, the command is: SEND UTSERVER@UTKVM1 FIND string In both of these examples, "string" is the search argument. It may contain an asterisk as a "wildcard", and is not case sensitive. The result from the search will be a file which contains all entries in the directory which contain the search string. A message which tells the number of matching entries will be sent to your timesharing userid. If matching entries are found, the file containing the matching entries will be returned to your CMS reader or to your JNET receive area. 1 Page 11 If an initial search of the directory does not return the information you are searching for, enlarging the scope of the search or changing the search arguments sometimes will return the results you are searching for. For example, if you search for "Smith, John", and cannot find John Smith's entry, then performing two searches, one for "Smith" and one for "John" may provide the results you are searching for. ********* * * Headlines * * * * Smaller bytes of news, but not unimportant... * * * * by Christopher Condon * * * * send them to BITLIB@YALEVM ********* * PolymerP FILELIST: The PolymerP filelist on LISTSERV@HEARN and LISTSERV@RUTVM1 stores a new Polymer Physics Database. The Database is intended for information which is of interest for the polymer physics community, such as email addresses, projects, software, physical data, meetings, vacancies, etc. The database is related to the Polymer Physics Discussion list, an open discussion group dealing with all relevant topics in polymer physics. You can receive the PolymerP filelist by sending the following command to LISTSERV@HEARN or LISTSERV@RUTVM1 via mail or message: INDEX POLYMERP. * FSFnet: With the distribution of issue 11-3 in mid-August, the FSFnet electronic fantasy and science fiction magazine will cease publication due to the graduation of its editor, David A. Liscomb (CSDAVE@MAINE). FSFnet began publication in December of 1984 and has produced nearly 50 issues. The magazine initiated a shared-world writing group called 'the Dargon Project', and this group will continue to produce Dargon stories. These stories will be printed in a new magazine, edited by John White (WHITE@DUVM), which will replace FSFnet. All readers who are subscribed to FSFnet at the time of 11-3's distribution will automatically be subscribed to the new magazine, or subscriptions may be obtained from Mr. White. Back issues of FSFnet are currently available from LISTSERV@TCSVM. 1 Page 12 ********* * * New Mailing Lists * * * * by Rich Zellich * * * * from List-of-Lists * * * * ZELLICH@SRI-NIC.ARPA ********* DISARM-L DISARM-L provides off-line and on-line discussion (with monthly logs) on ways to accelerate disarmament. Topics cover political, peace movement strategy, and military strategy (for technological discussions try ARMS-D@XX.LCS.MIT.EDU) for reducing nuclear, conventional, chemical, and biological weapons and forces. Also reducing destabilizing intervention in the Third World by the Superpowers. We want a broad membership (especially Europeans, Asians, Latin Americans) and lively debate; non expert grass-roots opinions are welcomed. To subscribe, send the following command to LISTSERV@ALBNYVM1 via mail or message: SUB DISARM-L your_full_name. Coordinator: Donald Parsons DFP10@ALBNYVM1 EPID-L Mailing list for the discussion of current topics in Epidemiology and Biostatistics. To subscribe, send the following command to LISTSERV@AQUCDN via mail or message: SUB EPID-L your_full_name. Coordinator: Robert C. James JAMESRC@QUCDN FWAKE-L A forum for a broad discussion about James Joyce's FINNEGANS WAKE. The James Joyce Institute of Ireland's Finnegans Wake Study Group has been doing their best to get the jokes in Finnegans Wake for the past decade or so. The Study Group thinks it is time for such groups to pool their findings. 1 Page 13 There are plans to start a second associated service to share page-by-page, line-by-line notes to the text of FINNEGANS WAKE in a fixed format analogous to that of Roland McHugh's ANNOTATIONS. The Coordinator is working on a program to vet the mail from such a service. All requests to be added to or deleted from the mailing list, or to have files distributed, should be sent to the Coordinator. Coordinator: Michael O'Kelly MOKELLY@IRLEARN HOMEBREW The Homebrew Mailing List is primarily for the discussion of the making and tasting of beer, ale, and mead. Related issues, such as breweries, books, judging, commercial beers, beer festivals, etc, are also discussed. Wine-making talk is also welcome, but non-homeade-wine talk is not. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to HOMEBREW- REQUEST%HPFCMR@HPLABS.HP.COM. Coordinator: Rob Gardner RDG%HPFCMR@HPLABS.HP.COM INFO-CAMAC Topics relevant to any Computer Automated Measurement And Control (CAMAC) hardware or software issue are appropriate. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to INFO-CAMAC- REQUEST@KL.SRI.COM. Coordinator: Richard Steinberger STEINBERGER@KL.SRI.COM INFO-PDP11 INFO-PDP11 is an unmoderated mailing list for discussion of any and all issues relating to Digital's PDP-11 series minicomputers and their operating systems. 1 Page 14 All requests to be added to or deleted from this list, problems, questions, etc., should be sent to INFO- PDP11-REQUEST@SEI.CMU.EDU. Coordinator: Pat Barron PDB@SEI.CMU.EDU iPSC Mailing list to allow iPSC/1 and iPSC/2 users and systems administrators from different installations to communicate easily and directly. Local aliases for this mailing list are to be handled by the local systems administrators, since most sites already have local user mailing lists. What is desired to accomplish is to link all these iPSC user lists together. The first thing needed is an administrator list and the user list will hopefully follow. If you are a system administrator for Intel Hypercube(s) you are invited to send the following information to IPSCLIST@TCGOULD.TN.CORNELL.EDU: - systems, iPSC/1's or iPSC/2's - administrator's e-mail address OR alias - institution - user alias list - suggestions, opinions, ideas.... PLEASE! Systems Administrators Only. Coordinator: Dave Fielding FIELDING@TCGOULD.TN.CORNELL.EDU MVSTCPIP A mailing list for discussion of MVS TCP/IP implementations. To subscribe, send the following command to LISTSERV@USCVM via mail or message: SUB MVSTCPIP your_full_name. Coordinator: Deba Patnaik DEBA@UMDC NEWSB-L This list is a forum for discussion of issues related to college News Bureaus. Expected topics include: common 1 Page 15 controversial campus issues, press releases, general information exchange, and building a network of contacts among staff in this field. To subscribe, send the following command to LISTSERV@BUACCA via mail or message: SUB NEWSB-L your_full_name. Coordinator: Kim Billings K_BILLINGS@UNHH OZONE This list is run by a group of researchers of the Italian National Council (C.N.R.), working at the CNUCE Institute, to awaken sensitivity of people working in the scientific institutions about the extremely serious problem of the pollution in the world. We believe the hole in the ozone, the "hot-house effect", acid rains, and toxic waste are disasters provoked by man by using Nature as a "never-ending" resource. Everybody can verify other effects of the pollution, in the cities, in the seas, in the rivers, etc. We think that the scientific community must create an opinion movement able to force some decisions at political level. To subscribe, send the following command to LISTSERV@ICNUCEVM via mail or message: SUB OZONE your_full_name. Coordinator: Erina Ferro ERINA@ICNUCEVM PCSUPT-L A users' group for the discussion of issues that address end- user support for IBM PC's and similar microcomputers. By providing a central forum for users worldwide, the group will foster the timely communication of solutions to problems with hardware, operating systems, and applications. The group is to include technical support professionals as well as those who find themselves in the role of ad hoc "PC expert". Participants in the group will determine what specific issues are discussed. To subscribe, send the following command to LISTSERV@YALEVM via mail or message: SUB PCSUPT-L your_full_name. Coordinator: Bob Boyd RWBOYD@YALEVM 1 Page 16 PSTAT-L A forum for the exchange of information about the P-STAT data management and statistics package; code, macros, applications, user news, user group reports etc. All requests to be added to or deleted from the mailing list, or to have files distributed, should be sent to the Coordinator. Coordinator: Peter Flynn CBTS8001%IRUCCVAX SIMULATOR-USERS SIMULATOR-BUGS Mailing list to allow users of the Rochester Connectionist Simulator to talk to one another. Please send BUG REPORTS to SIMULATOR-BUGS@CS.ROCHESTER.EDU. We are interested in fixing bugs, but can't make any promises! Please make your bug reports as specific as possible. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to SIMULATOR- REQUEST@CS.ROCHESTER.EDU. Coordinator: Liudvikas Bukys BUKYS@CS.ROCHESTER.EDU 1 Page 17 ********* * * Feedback * * * * a letters column * * * * "You PRO, we PRO, we don't go for REPRO!" * * * * send your letters to BITLIB@YALEVM ********* From: Jim Cerny Subject: David Benson's comment in "Feedback" I just finished reading the June issue of NETMONTH and, as usual, found a number of interesting tips and items. This is a further thought/comment on David Benson's wish (in the June "Feedback" section) for institution names. Early-on in our use of BITNET (way back, about a year ago!), we realized that many node addresses are pretty cryptic. As a very simple, but very useful, tool for my own use as Inforep and for our users, we created a VAX/VMS command ("symbol") that uses the VMS SEARCH utility to find matches to a specified string in one of the files that lists BITNET nodes. We use BITNET.LINKS. This saves us having to tell people that there even *is* a VMS SEARCH facility, since the average user is probably unaware of it. When they give our local command that enables BITNET use, it automatically defines the symbol BITSITES for them as $ BITSITES == "SEARCH our_library:BITNET.LINKS" So, to follow Benson's example, they could just say $ BITSITES UA1VM to see where it is. Or, what we find is more common, people want to know if a given school has a BITNET node, so then they might say $ BITSITES EMORY to check out Emory University. A final way that it is useful is in the process of reading mail. Suppose you read a message and want to reply, but for some reason it is not clear from the message, where the site 1 Page 18 is. Without leaving VMS mail, they can give the command Mail> SPAWN BITSITES EMORY How straightforward it is to find direct equivalents to this on various IBM and other operating systems, I have no idea, but as I say, on a VAX/VMS system it is both simple and very useful. * Editors note: Some IBM nodes have an EXEC known as NODE which will list information such as an institution's name, inforep, computer type, and so on. We distribute this with the BITLIB help system. c From: Eric Thomas Subject: REPRO feature 1. I am not at all sure that the majority of users agree with Tony d'Angelo. I personally find it a bit irritating to get interrupted by new mail which is in fact a copy of what I just sent. I know what I have said, and just have to discard it and get back to what I was doing. Most people seem to be satisfied with the present setup. 2. You DO get an acknowledgement that your mailing was successfully processed, unless you turn the option off of course. After 2-3 postings, users come to rely on the fact that LISTSERV works and that, when it says your mail has been distributed, it has indeed been. 3. Sending you back a copy increases network load, especially for "digest" type lists. From: Rodney Elin Subject: REPRO feature This is in response to the letter published in Netmonth Volume 2 Number 12, by Tony D'Angelo. In his letter, he discusses the LISTSERV REPRODUCE option, which is a flag allowing the sender of a message to a list to receive a copy of his/her submission. Currently, the overwhelming majority of lists on LISTSERV have the REPRO option set to "NO", so that the originator does not receive a copy of the message from the LISTSERV. Mr. D'Angelo calls for all lists and for future revisions of LISTSERV to have the default REPRO option be "YES", so that each sender would receive a copy of his/her posting unless each individual changed the option, for each list to which he is subscribed. 1 Page 19 I am opposed to his suggestion, and would like to voice my support of the "status quo". Mr. D'Angelo gives two explicit reasons for receiving a copy of his postings, the first being simply "just to see how it looks...Õto seeå if there are any gross errors in the message." This is unnecessary, as a writer, using ANY medium and not just electronic mail, should thoroughly proofread all that he writes before he sends it to be read, published, or critiqued. Mr. D'Angelo is proposing that, with the use of the REPRO=YES option, a writer proof his material AFTER it is published, which is unheard of from any writer's point of view. As for seeing how something looks, as long as the LOG option is in effect, which is the default for almost all mailers, a copy of each mail file sent is saved on the sender's disk, and immediately, without waiting for the LISTSERV, can the sender see how his mail looks (though he should know this before it is sent.) Mr. D'Angelo also states that the REPRO=YES option is needed to find out "if and when Õthe postingå got distributed." This is also not necessary, as LISTSERV additionally supports several levels of acknowledgement for each user and each list, including no acknowledgement (SET NOACK), acknowledgement by interactive messages (SET MSGACK), and mail acknowledgement (SET ACK), from each peer of a particular list. Using message or mail acknowledgment is preferable to a copy of the posting, as it is a small, concise message, with statistics involving the distribution volume and time. Message acknowledgement is faster than a copy, and tells the sender exactly when (and if) a posting was re-distributed to all subscribers of a list. What Mr. D'Angelo fails to mention is the impact a global default of REPRO=YES would have on network load. During the summer months, the network is relatively fast, due to the fewer number of users. But beginning in September, more and more people will use BITNET, meaning a heavier and heavier load, especially on major links. The fewer files and mail that are sent through the network, the less load that will be on the network, and the faster other information can be sent. In his letter, Mr. D'Angelo explains exactly how an individual, for whatever reason, can set his individual entry in a list to REPRO=YES when the default is NO. This is one of the main reasons for keeping things the way they are. The default for all lists SHOULD be NO, in the interests of keeping down network load, but anyone can change this for his own entry just as simply as he subscribed to the list. * Editors note: Enough said on this subject. I probably should have made similar comments when I printed the letter, 1 Page 20 but hindsight is 20/20, no? Also, many of you will be happy to see that I have given in and will now print the network addresses of people who send letters to Feedback. ********* * * 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 NICSERVE@BITNIC. 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. 1 Page 21 * 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. * Printing this file: VM users can print this file by using the "( CC" option of the PRINT command. VAX/VMS users should RECEIVE NetMonth with a format of FORTRAN. This will allow page-breaks to be accepted by your printer. _ __- __--- The __----- Bitnet __------- Services ___________ Library "Because We're Here." ***************************************************************