******** ************************************************** * * * * * The independent guide to BITNET * * * * * * September, 1988 * * * * * * Volume 3, Number 3 * ******** * * * * *** * * * * * * * * * * * ******* * * * * * ********* * * ** * ** ** * * ** * * * ******* ********* * * * ****** ********* * ****** * ** ** * * * ********* ** * * * ********* ******* * * ** * ******** * ******* ** ** * * * ********* ********* * * * ** ** ******* * * * ** * * * ******* ********* * * * ****** ********* * ******** * ** ** * * ********* ** * *** * ********* ******* * * * * ** * * * * ******* ** ** * * * * ********* ********* * *** * ** ** ******* * * ** * ****** * ******* ********* * * * ****** ********* * * * ** ** * * * ********* ** * **** * ********* ******* * * ** * * * ******* ** ** * * * ********* ********* * ****** * ** ** ******* * * * ** * * * ******* ********* * * ****** ********* * ******** * ** ** * * * ********* ** * * * ********* ******* * * * ** * **** ************************************************** 1 * * * * * ** * * ** ** * * * * * * *** ***** * * * * *** **** ***** **** * * * * * * * * * * * * * * * * * * * ***** * * * * * * * * * * * ** * * * * * * * * * * * * * **** * * * *** * * * * * ****** ****** Christopher Condon Editor CONDON @ YALEVM Timothy Stephen Associate Editor STEPHEN @ RPICICGE Craig White Associate Editor CWHITE @ UA1VM 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 Point of View MOSS @ YALEVM ********************* Contents - Issue 25 ********************* EDITORIAL PAGE_________________________________________________ Bitnotes .................................................... 1 Flames To: .................................................. 3 An EARN-Poland Link ......................................... 5 FEATURES_______________________________________________________ The White Pages for Albany .................................. 8 Using IDSERVER .............................................. 9 Exchanging Mail Among Usenet, BITNET, and FidoNet .......... 11 DEPARTMENTS____________________________________________________ Headlines .................................................. 17 Feedback ................................................... 20 Policies ................................................... 24 * 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 ********* "We learn by doing." I hid her notebook. In retrospect I suppose it was a silly thing to do, but we learned a lot from it. She was a bright, intelligent Co-op student who made my grade point average look like burned waffles. I was the Co-op student she was replacing. As such, I was given the task of passing knowledge to a person obviously more intelligent than me. Worse, she was a snappy dresser. She had a little stenography notebook that she carried around during her training period, and she would write down almost everything I said and did. When it came time to perform a particular task, she would flip to the appropriate page in the notebook and follow the instructions therein. When she ran into trouble she would call me over to help her. She would then add whatever I did to her instructions. I began to wonder whether she was really learning anything at all. The whole idea of working as a Co-op was to gain a kind of knowledge and experience that one can't get from reading a book or taking a test. This was a reasonable facsimile of the real world of computers, with all of its delights and dangers. Somehow this Co-op was taking this experience and reducing it back to the textbook (in this case, notebook) level. So I hid the notebook and asked her to perform some task. She of course protested that she couldn't do it without a reference of some kind. I suggested that there was a real rush on this particular item, and that she had better hurry. It took her a little longer to reach her goal, but when she was done she had a better understanding of the software we were using. It wasn't a matter of pressing F1, typing "A", pressing Control-Q and so on. If the commands were changed or the software was different, she now knew that she had the mental tools to *figure it out*. 1 Page 2 This is true every time a new user begins using the network to communicate. The concepts of electronic mail, messages, mailing lists, and forums become real tools and challenges, not words and pictures in a book. When a student passes from the world of education to the world of business, they will inevitably be faced with other networks and other software. After BITNET, however, many of these people will have the ability to use these tools and use them effectively. The benefits of exposure to BITNET vary from user to user and from discipline to discipline. The key to maximizing these benefits is education and training. Handing someone a userid and a copy of BITNET USERHELP is a nice idea, but it hardly matches the payback of sitting people at terminals and saying, "Do it." Watch them receive mail and send messages to each other. The concepts come to life before their eyes. Suddenly, the network isn't a burden, but a tool to be used. It can even be fun. When they understand this, give them real examples of how they can get the most out of the network. If you are training a psychology class, give them information on the Psychnet magazine and server. If you are teaching Communications majors, show them COMSERVE and CRTNET. Then let them explore and find other services and topics to thrill and amaze them. The value of BITNET isn't just in the information and services that these students receive today. It is in the understanding and abilities they will take with them when they are no longer part of this network. Virtually, Chris Condon@YALEVM 1 Page 3 ********* * * Flames To: * * * * by Craig White * * * * University of Alabama * * * * CWHITE@UA1VM ********* Hello everyone, I have been hopelessly behind this month. I hope your month was slower. Around here it's time for the students to return for the fall semester and things are really hopping. I have gotten a ton of mail this month and at one point I just deleted the whole lot and got a fresh start with an empty in-box. From my perspective, the network seemed to be down more than it was up this month. I would go for days without receiving a single piece of mail, and then very suddenly many files would arrive all at once. I really think that this is a serious problem with BITNET but that's a flame for another day. This month's flame is about the sending of large files over BITNET. I understand that under some circumstances sending a large file is unavoidable. A reason that comes to mind is when the information is needed quickly and there's not enough time for a tape, granted that the time variable is very subjective. From my experience, those who attempt to send or receive a large file, are generally new to BITNET. Usually they know nothing about networking and the concept of a limit on the size of your files comes as a shock. At least twice in the past month I have had people who were new to networking either trying to send large files or waiting on files to arrive that were way over the 300K limit. The ones who were trying to send the files were the easiest to deal with because they were local. The ones that were on the receiving end of a large file were more difficult to deal with. It was obvious to me that the files had been put on hold or even purged at some point along the way. I've found that nine times out of ten when I start hearing things like "What is taking my file so long to get here?" or, "Do you think my file got lost?", it's time to ask about the size of the file. Most of the time, the file is in fact over the limit and I go into a standard BITSEND/BITRCV talk with the user. 1 Page 4 Now for the flame, when a file is put on hold or purged because of size problems, both the SENDER and the RECIPIENT should be notified of this fact and, in addition, both should be informed as to where they can get BITSEND/BITRECV. Some people may argue that only the sender should be notified or only the recipient. My reasoning for both is that most files are not unsolicited, both parties have probably discussed the file in question and reached a decision that the recipient needs the file. Because of this, they both should have a good idea of the size of the file. If this is the case, and the file gets sent anyway, then both people should be told the fate of the file. Winding down, I think that the sending of large files is done mainly by uninformed users of the network, and purging or putting the file on hold without any notification of this fact is cruel. If it was the US Postal Service it would be criminal. At the very least notification should be sent to one of the parties. Optimally, the file sending program would check the size of the file and BITSEND it if necessary , but that is just too much to expect right now. Finally, LDBASE.COM for VAX sites is now available. It is in the tools filelist at a LISTSERV near you. To obtain a copy you could use the LISTSERV command GET LDBASE COM TOOLS FILELIST. I understand that it is written in FORTRAN and comes with everything you need to get it up and running. As always, questions, comments and flames to CWHITE@UA1VM. 1 Page 5 ********* * * An EARN-Poland Link * * * * by Dave Phillips, et al. * * * * State University of New York at Buffalo * * * * V184GAVW@UBVMSA ********* A May, 1988 NetMonth article proposing an academic computer link to the USSR spawned a series of discussions, a couple of which surfaced in subsequent issues of this publication. Since June a discussion group has formed, comprised of Polish graduate students studying in the West, Western scientists who have worked in Poland and/or who have Polish colleagues, and others on the network who are familiar with the potential scientific and cultural benefits offered by a link between EARN and Polish universities. The private list is small but growing, and extends from Vancouver to Lund, Sweden. This group has as its purpose to identify the problems involved in establishing such a link, and to elaborate the benefits, and to place a developed proposal before EARN and some of the more autonomous institutions in Poland. From John Duchowski, 4th year PhD student, Carnegie Mellon University, originally from Warsaw: "Being a chemist, I fully appreciate the need for rapid access to information. The advent of Chemical Abstracts On-Line has greatly simplified and improved the usual literature searching methods. However, personal communications between scientists in the West and the East still have to rely on sometimes lengthy standard mailing procedures. At present, we in 'the West' have only a limited access to 'Eastern' publications and vice versa. Providing an EARN link could be set up, both of these problems would be alleviated. "Historically, since the end of World War II, people on both sides of the 'iron curtain' have also been drifting apart culturally. Open discussions on subjects other than science are few and far between. Access to electronic discussions, such as RELAY, would also lead to a greater and presumably more open minded exchange of cultural viewpoints. Idealistic as all this sounds, and where the initial discussions on subjects such as history may be heated, with time the differences on certain issues may become of purely academic interest. This would of course lead to the decrease in tension between the two sides. 1 Page 6 "Finally, from a purely social point of view, the benefits of open communication are particularly easy to see. Although this may be looked upon as a glorified 'pen pal' aspect of the Electronic Mail, the free exchange of ideas and opinions between private citizens on both sides should not be underestimated. "The above comments apply equally well to any Eastern European country. Nothing has been said thus far about why the first candidate for a BITNET connection should be Poland. Being of Polish origin, I may indeed be accused of some kind of a bias in that direction. From a historical perspective however, Poland has always been a very western-oriented country. Even as a member of Soviet bloc Poland probably enjoys the least controlled society, vis a vis Bulgaria or even Hungary, albeit at the expense of a ruined economy. Therefore, an EARN link to Poland would probably be under a lesser degree of government control as compared to other Soviet bloc countries. "We also have to consider the drawbacks on equal footing with the benefits. The most obvious is the sad state of Polish economy. To maintain a good quality telephone line in Poland is far from cheap and frequent breakdowns should be taken into account. Moreover, the cost of EARN membership, yet another drain of badly needed Western currency, may not be seen as one of the first priorities by the Polish government. Also, the existence (or lack of it) of a sufficiently up-to-date technical base, such as mainframe computers, may limit the number of candidate sites. Another question that needs to be asked is how is the access to the EARN-linked computer going to be controlled. Even minimal (by East Bloc standards) government control might invalidate the benefits mentioned above." From Andrew Duchowski, Simon Fraser University: "I just learned recently from a friend of mine here in Vancouver of another example of potential for scientific exchange. Biochemistry at several educational institutions in Poland is at a fairly close level to some research institutions here in Canada. Specifically, protein purification research is one such example. With an EARN link, this research may be assisted by the use of information exchange between the East and West. " From David Phillips, SUNY at Buffalo: "The benefits to the world outside the Soviet bloc would outweigh any real or imagined risks incurred in establishing such a link, particularly if that link is connecting a relatively independent society like Poland's. 1 Page 7 "Although Poles suffer official censorship, a pervasive secret police and laws similar to those in the USSR, there are thousands of underground publications, a legal independent Church, private agriculture, and the East bloc's first and only independent trade union federation, NSZZ Solidarnosc, which is an affiliate of both the International Confederation of Free Trade Unions and the World Confederation of Labor. There is literally a world of difference between Poland - even in its present state of collapse - and Soviet society at the peak of its "glasnost." This difference has been maintained at great cost by the Poles since 1944. "There is also a thriving independent student movement in Poland, and thus there is a strong possibility (though no guarantee) of making an EARN-Poland link, should it ever come about, a genuine link - not a vacuum cleaner attachment for a Bloc information gathering apparatus rationed to trusted apparatchiks. "The problems are at four levels: 1) Faculty, students and administrators at the more autonomous universities and polytechnics in Poland have to be made aware of the potential for a link and of our support for such a venture; they will request it once it appears possible, of this (viz. the students at least) we're certain. 2) EARN must decide in principle that such a link, if requested, is OK; this involves in part EARN's members' relationship with the US government, which leads to 3) the assessment by the US government of the relative merits versus risks in acquiescing to a positive decision by EARN. Finally, there are 4) the technical problems of a first link itself, involving site selection, phone line, money and institutional commitment. "The perception of the US government would seem to hinge on concerns of technology leakage and perhaps potential sabotage. How much such a link would expose genuine US security interests is hard to say, but there would seem to be a large and ongoing exposure in the territory of the USA itself (from East Bloc diplomatic personnel, intelligence gatherers, communications monitoring, illicit export of hardware). "Finally, we cannot guess in advance whether the regime in Warsaw will accept requests from schools for a link; this would depend in part on their perception of the international climate." John Duchowski - Pittsburgh (jd3a+%andrew.cmu.edu@CMCCVB) Andrew Duchowski - Vancouver (USERQP4C@SFU) David Phillips - Buffalo (V184GAVW@UBVMSA) 1 Page 8 ********* * * The White Pages for Albany * * * * by Deba Patnaik * * * * University of Maryland * * * * DEBA@UMDC ********* WHOIS@ALBNYVM1 is an online white pages for the University at Albany. It accepts commands by both interactive message and electronic mail. If you send a command by mail it should be places on the Subject line or on the first line of the message area. Your command, as such, is the last name of the person for whom you you are looking. For example, to look for people with the last name of "Jones" you would send the command JONES. The response would look much like this: Name: Jones, Arthur; Phone: (518)442-1234; Office: Service Bldg A 904B; E-mail: none Name: Jones, Heidi; Phone: (518)442-1001; Office: Social Sciences 290; E-mail: HUGGA@ALBNY1VX If you are unsure of a spelling, wildcards are allowed, as long as they are preceded by two characters. For example, a search for S* is invalid, but a search for SM* would work: Name: Smirensky, Hubert; Phone: (518)442-7717; Office: Library A23A; E-mail: none Name: Smith, Wayne; Phone: (518)442-5290; Office: Service Bldg A; E-mail: WAYNE@ALBNYVM1 If the server can not find a match for your search, it will respond with names that sound much like it. In this example I was searching for the name TOMAS: Name not found. Possibly similar name(s) are: Name: Thomas, Andrew; Phone: (518)442-1623; Office: Earth Sciences 132F; E-mail: none Name: Tomaski, Herb; Phone: (518)442-1158; Office: Computing Svcs 05; E-mail: HERB@ALBNY1VX 1 Page 9 ********* * * Using IDSERVER * * * * by Gerry Santoro and Chris Sacksteder * * * * Pennsylvania State University * * * * GMS@PSUVM and CJS@PSUVM ********* IDSERVER@PSUVM is a service machine that looks up the name and userid of persons with accounts on node PSUVM. You send it a message containing either a name or userid. It's main purpose is to provide PSUVM userids to BITNET users. If a person is not found that does not necessarily mean they are not at Penn State or are not joined to a system operated by another department and accessible via e-mail. Student accouts expire at the end of every semester and are given only to students taking course requiring mainframe use. Also, not all faculty and staff have accounts on PSUVM. USING IDSERVER: IDSERVER accepts interactive messages only. Mail is not accepted at this time. For example, on an IBM VM/CMS system connected to BITNET, a command to send a message to IDSERVER would be of the form: TELL IDSERVER AT PSUVM ( Users on DEC VMS/JNET systems would use this syntax: SEND IDSERVER@PSUVM ( The may be the following, and may be abbreviated to the shortest form shown in upper case: Userid - search string is a userid (synonyms: Id, Initials) as opposed to a last name ANy - match any part of the name, not just the last name Campus - also show campus where user is located * Examples of searches: Names and userids do not have to be sent in uppercase. SMITH find users with the last name SMITH 1 Page 10 SMITH DAVID find users with the last name SMITH, and first name DAVID. SMITH RICHARD B find user RICHARD B SMITH. SMYT* find users with last name starting with SMYT. DXS (USERID find userid DXS. SMITH (C find users named SMITH, and list the PSU campuses where they are registered or working. TOM (ANY find users with TOM in any part of their name. * Capbilities and Limitations: The IDSERVER simply runs an end-user command called FINDUSER, collects the output, and returns it to the requestor. The FINDUSER EXEC depends on several local fixed-format data files, and is therefore not very portable. The number of records returned is currently limited to 20 for network users. That is, only the first 20 matches are returned to the requestor. If there are too many occurrances of a particular last name, add the first name as shown in the examples above. 1 Page 11 ********* * * Exchanging Mail Among Usenet, BITNET, and FidoNet * * * * by Chris Graham * * * * Guest Writer from Usenet * * * * moore!graham!chris@uunet.uu.net ********* This article describes the use of gateways between Usenet, BITNET and FidoNet, especially within the Canadian province of Ontario. Using techniques described here it is possible to send mail from an academic computing account on BITNET to someone far away who does not have access to any medium or large computer system (such as relatives in one's home town or other far-away place, or a penpal). Conversely, this article contains techniques which can be used, by people who have no access to large or medium sized computer systems to send mail to individuals who have BITNET accounts. And the best thing about mailing from BITNET to the other destinations is that it's free. The reverse route can be free in some cases and if it isn't, the cost is very low. The way the above can be achieved is by making use of communication links between BITNET and various independent bulletin board systems (BBSs). A BBS is a small computer (usually some sort of IBM compatible) which is connected to the telephone system and maintained by its owner as a hobby. BBSs run software, such as Fido and Opus, which allow other computer owners to log into them over the phone, by means of a modem and quite ordinary telecommunications software. Once a user is logged into a BBS, he may exchange mail with other users of the BBS. And he may transfer files and programs from his computer to the BBS for other users, or pick up files and programs that other users have left in the BBS. In most cities, there is a plentiful abundance of BBSs, and access to most of them is free. Some BBSs are members of a network, designed for and populated by BBSs, called FidoNet. On BBSs connected to FidoNet, it's possible to exchange mail, not only with users of the same BBS, but with users of other BBSs on the network, in much the same way as this can be done with BITNET. Since membership in FidoNet is popular among operators of BBSs, and since it's possible to route mail from BITNET to FidoNet and vice versa, it is likely that, within any town or city, a BBS may be found which will facilitate communication between a user on BITNET and any individual within that town or city who has access to a microcomputer or terminal and a modem. 1 Page 12 The method used to accomplish the above is to make use of gateways which mediate between BITNET and Usenet (which is another network) and other gateways which mediate between Usenet and FidoNet. In this way, a third network is used as a path between FidoNet and BITNET in much the same way a string is used between two tin cans. This may sound complicated but the rest of this article will show how simple this is. Incidentally, some individuals have access to computers because of their employment and it's possible that these computers are linked to Usenet. Literally thousands of computers are connected to Usenet, including those of AT&T, Commodore Business Machines and others. If someone works for a company which has a computer that's linked to Usenet and the individual in question has access to that computer, then the techniques of this article may be used in order to exchange mail between that person and people on either BITNET or FidoNet. Communicating between Usenet and BITNET is free and sending mail to FidoNet is free but sending from FidoNet to either BITNET or Usenet is free or costs very little. Gateways are computers which are connected to two or more networks and allow information to be routed from sites on one network to sites on another. For example, if a sender has an account on a BITNET site and he addresses mail to a destination on Usenet, that mail will be routed through a computer which resides on both networks so that it can be conveyed to the network which contains the destination site. Using the information presented in this article, it is possible to reliably route mail from sites on FidoNet, through Usenet, and on to a site on BITNET. Likewise, techniques for the converse movement of mail will be presented within this article. A lack of details about more than one Fido/Usenet gateway prevents this article from explaining precisely how, but it will provide a general framework of how gateways may also be used to move mail between FidoNet sites in a way that minimizes long- distance telephone fees. This can be accomplished by moving the mail through Usenet and back to a FidoNet nearer to the destination. While FidoNet sites telephone each other directly, Usenet sites pass mail to intermediate sites like a team of messengers relaying a message. For example, if a Fido site in Toronto has mail aimed at a site in Washington D.C., the Toronto site will incur long-distance charges by telephoning the Washington site directly. In contrast, a Usenet site in the same situation will figure out the path of least cost using other Usenet sites along the way. In this way, the mail would be passed along by several different sites on its way to the destination and each intermediate site would only have to place a local call. Not only is this an advantage in saving on long-distance but it's also how Usenet sites get mail to other sites to which they are 1 Page 13 not connected; such mail is bounced around the network until it reaches a site which is. This is why addresses on Usenet sometimes take a form like "moore!graham!chris". Such a form is called a bang-path and this particular example is understood to mean that the mail is routed to a site called moore which then passes it on to another site called graham, which then passes the mail to chris (which graham knows as one of it's users so it gets to the user and goes no further). If moore is not directly connected to the site which is first to receive mail so addressed, it will use a smart mailer program to figure out the path of least cost so that it can be passed as far as moore. Because of smart mailers, it's possible for a Usenet address to be as short as chris@graham or graham!chris. However, such addresses will fail on sites which do not run a smart mailer or if the site (graham) is not known to the smart mailer program. At this point, it should be mentioned that upper-case characters should not ordinarily appear in a Usenet address; doing so can cause mail not to be delivered. FidoNet addresses are much simpler but harder to remember. They are in a form such as "chris graham ON 223/228". Here, "chris graham" is the login name of the target individual and 223/228 is the designation of the destination site. If the destination site is in a different region than the originating site, then an additional region number must be specified in the destination address as in 1:223/228. This is not usually necessary since all of North America is counted as region 1: . Beyond this, it's not important to know what the numbers mean; any BBS connected to FidoNet will make the right numbers available on request. In this article, three BITNET/Usenet gateways are described: uunet, gpu and PSUVAX1. At least in Southern Ontario, mail addresses (sent from BITNET) which bear the domain .uucp (as in chris@graham.uucp) are routed through PSUVAX1 which is a VAX at the University of Pennsylvania. Mail can also be explicitly routed through uunet (which is a major backbone site on Usenet in Virginia) by appending the suffix "@uunet.uu.net" to the destination Usenet address. Likewise, mail can be explicitly routed through gpu (which is at the University of Toronto) by appending the suffix "@gpu.utcs.toronto.edu" as in "moore!graham!chris@gpu.utcs.toronto.edu". Since graham is located in Toronto, this latter route is the fastest since it allows the mail to stay in BITNET for more of the trip. For example, if a sender on BITNET desires to send mail to a receiver on Usenet, and the destination site is graham and the destination user's username there is chris, then the sender may address the mail to either "chris@graham.uucp" or "graham!chris@gpu.utcs.toronto.edu". In the former case, the mail is routed through PSUVAX1 and in the latter, it is routed through gpu. 1 Page 14 In some cases, PSUVAX1 is a black hole. That is to say that some mail won't arrive at its intended Usenet address and the sender won't be notified of the failure. Such is the case when the destination site is unregistered or it is a new site whose registration has not yet been published in the appropriate news group and implemented in PSUVAX1. The logical solution would is to include more of the destination path but PSUVAX1 will ignore the extra routing information, find that it can't route the mail by itself and dump the mail without informing the sender. In contrast, uunet and gpu will adhere to the destination routing specified by the user. For example, the address chris@ziebmef.uucp will work because ziebmef is known at PSUVAX1 but chris@graham.uucp will fail because, at the time of this writing, graham is a new site and is not yet known to PSUVAX1. It will seem to work but the mail will fail to arrive at its destination. A reliable way to address mail to chris@graham.uucp is to address it to either moore!graham!chris@gpu.utcs.toronto.edu or moore!graham!chris@uunet.uu.net Here, moore is a registered site adjacent to graham and so the smart mailer of either gpu or uunet will route the message as far as moore, and moore knows graham so it will arrive reliably. In VM (which runs on medium to large IBM systems), read "@" as " at " in the preceding addresses. It is impossible to specify a domain such as ".utcs.toronto.edu" using JNET on VAX/VMS as in JNET%"moore!graham!chris@gpu.utcs.toronto.edu". However, IN%"moore!graham!chris@gpu.utcs.toronto.edu" will work if the necessary software is accessible on the sender's system; otherwise, VMS will complain of the absence of an .EXE file in sys$system: . In any case, it is required that the sender find a means of specifying a domain or the formula to gpu won't work. Going the other way, from Usenet to BITNET is much simpler, at least from a site with a smart mailer; it is simply a matter of suffixing ".bitnet" to the destination address. For example, if "doe" is the destination site on BITNET and "john" is the username of the intended recipient, a sender on Usenet can simply specify john@doe.bitnet as the destination address and the mail will be automatically routed to a correct gateway and arrive reliably at the destination. Two ways are described in this article for addressing mail from Usenet to FidoNet. One way is to specify the address in the form firstName_lastName@f.n.z.fidonet.org 1 Page 15 For example, if it is desired to send mail from Usenet to Chris Graham ON 1: 223/258, using this method, then the address to use is: chris_graham@f258.n223.z1.fidonet.org. The main disadvantage of this method is that it can be routed through a Fido gateway that's very far away from the destination and the gateway has to make a long-distance call to the final destination site. This doesn't directly affect the sender except that it takes roughly two more days to arrive. Nevertheless, it is inconsiderate to cause the gateway to incur long-distance charges in this way so it's better all around to find a gateway that's local to the destination and route the mail through it explicitly. That last point brings us to isishq. isishq is a Fido/Usenet gateway that's connected through the University of Waterloo and mail can be addressed to FidoNet destinations in the form isishq!network!machine!firstName_lastName. For example, to send mail to Chris Graham ON 223/258 from Usenet using this method, the mail would be addressed to isishq!223!258!chris_graham . If the destination zone is other than one, then another field is added to the address as in: isishq!1!223!258!chris_graham. It should be added that the sysop of isishq will request contributions if you cause his gateway to incur too much in long-distance telephone charges. His BBS can dial Waterloo, Toronto and Montreal rather cheaply but if you specify a destination very far away, it will arrive at his gateway and his gateway will have to place an outgoing telephone call to the destination site. If you plan to send to FidoNet sites outside of the places I've mentioned, you should find a gateway for yourself which is closer to the destination. isishq, which is 1:221/162 in FidoNet, will also serve to move mail from FidoNet to destinations on Usenet. To accomplish this, go to the net-mail section of the BBS which is the Fido site and address mail to uucp on 221/162 (adding the 1: if you're outside that region). Specify the subject as usual, but the first line of the message text must be the destination address on Usenet prefixed by "To: ". For example, if you wished to send mail from a FidoNet site to chris@graham.uucp, you would address net-mail to uucp ON 221/162 and begin your message with the line (left justified, of course): To: moore!graham!chris Unfortunately, there is a snag, which is the cost of sending mail to 221/162 from another Fido site when a long distance telephone call is required to do so. For example, to send mail from 223/258 in Toronto, through 221/162 in Waterloo, requires 1 Page 16 that 223/258 place a long distance telephone call to 221/162. Most BBSs will check an on-line list of FidoNet sites to estimate what charges will be incurred by the required telephone call and then check to make sure that you have enough credit on balance to cover the charges. If the balance is insufficient, the BBS will refuse to accept the mail message. If there is intent to use a BBS in this manner, then arrangements should be made with the sysop so that there will be an adequate credit balance. Most BBSs in Toronto seem to charge around 35 cents to route mail through 221/167. It's always best to find and use the gateway closest to the sender's (or destination) FidoNet site. Because of the elegance and transparency of the addressing methods of Usenet and BITNET and the involved gateways, it's easy to modify the above formulations in order to address mail from BITNET to FidoNet or from FidoNet to BITNET. For example, addressing mail from Chris Graham ON 223/258 to john@doe.bitnet is a simple matter of addressing net-mail to uucp ON 221/162 and specifying "To: john@doe.bitnet" as the first line of the message text. Similarly, addressing mail from john@doe.bitnet to Chris Graham ON 223/258 is a simple matter of addressing the mail to isishq!223!258!chris_graham@gpu.utcs.toronto.edu . Both of these methods make use of Usenet to carry the mail between Fido/Usenet and Usenet/BITNET gateways, like using a string to connect two tin cans together. In a similar manner, it should be possible to use Usenet as the string between two FidoNet sites but that will be left for later. 1 Page 17 ********* * * Headlines * * * * by Chris Condon * * * * Yale University * * * * Send your Headlines to BITLIB@YALEVM ********* * King Testifies before Senate Subcommittee (from Bitnews): Kenneth M. King, President of EDUCOM, recently testified before the Science, Technology and Space Subcommittee of the United States Senate Committee on Commerce, Science and Transportation. Discussing the formation of a national educational and research network, King stated that "there is a broad consensus among government, education, and industry leaders that creation of a high-speed national research and education computer network is a critical national priority." The complete text of the testimony is available from LISTSERV@BITNIC as the file SENATE TESTIMON. * BITNET Statistics (by Hank Nussbacher): From a section on Wide Area Networks found in Communications of the ACM - July 1988, "Fourth Annual UCLA Survey of Business School Computer Usage": "It appears from Table X that BITNET has become almost ubiquitous, and that, with an endorsement of 4.0, the users are quite satisfied with this capability." The table shows that in 1987, out of 83 business schools that replied, 90% had BITNET connection, with the next closest being Arpanet (31%). The numbers for 1985 (42 business schools) were 67% had a BITNET connection with Arpanet getting 19%. * EDUCOM'88 (by Dan Updegrove): EDUCOM is gearing up for its biggest conference ever, October 25-28 in Washington, D.C. Featured speakers for EDUCOM'88, "Campaign for Excellence: Education, Government, Industry," include Erich Bloch, Director of the National Science Foundation; Alan Kay, Apple Fellow, Apple Computer, Inc.; H. Ross Perot, Founder of Electronic Data systems Corporation; and Edward Redish, Professor of Physics at the host University of Maryland. 1 Page 18 Program tracks include Emerging Technology, Computer Networking, Educational Software, Strategic Planning for Information Technology, Libraries, Social, Legal, and Ethical Issues, and Management. In addition, EDUCOM'88 will feature exhibits of select academic software including this year's winners of the EDUCOM/NCRIPTAL Software Awards; a "playroom" in which conference attendees can explore commercially available software; extensive demonstrations by EDUCOM's Corporate Associates, and tours of capital area campuses and government labs. Networking is the focus of six program sessions: "National Networking Update", "Conferencing", "Networking at Small Colleges", "Access to Library Databases", "The New Network Applications", and "Using Networks to Aid Collaborative Learning." Network-oriented Special Interest Group meetings include "BITNET in Other Countries", "Using LANS to Provide Bibliographic Databases to Faculty and Students", and "Networks and Electronic Publishing." There will also be demonstrations of NSFNET, BITNET, and multi-vendor ethernet connections among EDUCOM's Corporate Associates. As a result of the great demand for information, EDUCOM has posted materials in the articles archive of CCNEWS, a forum for campus computing newsletter editors that uses LISTSERV@BITNIC. Four separate files are available, containing: Conference Brochure, Conference Registration Form, Conference Tours Information, and Hotel Registration: EDUCOM88 BROCHURE Lines: 1878 EDUCOM88 REGFORM 181 EDUCOM88 TOURS 322 EDUCOM88 HOTEL 109 For more information, or to register, contact CONF88@EDUCOM. * New BITNET Director (from Mike Roberts): I am very pleased to announce the appointment of Dr. James B. Conklin Jr. as the new Director of the BITNET Network Information Center. Jim joins EDUCOM and BITNET with a strong background in academic computing. He most recently was head of the computing center at the Harvard-Smithsonian Center for Astrophysics. Previously, he was Associate Professor of Physics and Director of the Center for Instruction and Research Computing at the University of Florida at Gainesville. He holds Bachelor, Masters, and Doctoral degrees from M.I.T. 1 Page 19 Jim has been an active participant in BITNET since its inception and brings both experience and enthusiasm to the Director's challenging job. I know that he looks forward to working with all BITNET members, small and large, and would be pleased to hear your thoughts on how to strengthen the network and improve the services provided by the BITNIC. * BITNET Technical Meeting (by Scott Earley): Host: Harvey Mudd College (BITNET node: YMIR) Date: Saturday, October 15, 1988 Time: 8:30 am - 6:00 pm Where: Harvey Mudd College 260 E. Foothill Blvd Claremont, California Free: Registration and refreshments Registering: If you plan to go please use LISTSERV@BITNIC to SUBSCRIBE to BITTECH to facilitate communication. Staff at BITNIC will use the list for logistics at Harvey Mudd. Don't hesitate to use BITTECH for your own inquiries, making additions to the agenda and so on. Directions from Anaheim and room assignments will follow shortly. Watch BITTECH for details. Objective: To provide a forum for BITNET users to become involved with network-related issues and to develop proposals for submission to the BITNET Board of Trustees, or its Committees. Structure: The meeting opens with a one-hour Plenary Session at 9:00, after which two Working Groups will break off for the rest of the morning. Following lunch the groups reconvene, allowing time for a summary and wrap-up later in the afternoon. Plenary: James Conklin, Director BITNET Network Information Center. Jim will make a "state of the BITNET address", including progress of BITNET merging with CSNET and the RSCS over TCP/IP pilot (BITNET II). Parallel Working Group Tracks: Each group will report on the status of recommendations made at the August 13 BITNET Technical Meeting at CUNY Hunter College. The working groyps are "Being a TECHREP", chaired by Jim Gerland, and "Being an INFOREP", chaired by Scott Earley. 1 Page 20 ********* * * Feedback * * * * a Letters Column * * * * "Something more intriguing..." * * * * Send your letters to BITLIB@YALEVM ********* From: June Genis Subject: User directory services on BITNET The following is in response to Les's article on NAMESERV@DREW in the August 1988 issue of Netmonth, but it also summarizes some points I brought up at the recent BITTECH meeting. Without meaning to disparage the effort Drew has made to make this service available, I feel it falls far short of what is needed in directory services for BITNET. While NAMESERV offers an improvement over the old BITSERVE directory in that obsolete entries will automatically expire, it does not address the problem of building critical mass on the entry side. It has been my experience with all of the servers of this type to date that I can never really find anyone I need in them because those people haven't seen fit to register themselves. On the other hand, more and more schools are developing some kind of computerized directory for local use. Sometimes, as here at Stanford, that directory may be searchable by all machines on a local network even through it may not be accessible via remote BITNET query. At other places it may just be part of a batch file used by personnel or student records. But somewhere the critical data is being gathered in machine readable form. More importantly, there is someone whose job it is at that institution to see that the data is keep current, at least on a yearly basis. For this reason I would like to see more of the following sorts of efforts: 1. The creation of a registry of local directories with an indication of who has access to it locally, if there is any network access to it, if the owner would be willing to contribute the data to a centralized server on a periodic basis, whether they would be will to convert the data to a standardized format for export to such a centralized server, and who owns the data and how that person can be contacted. 1 Page 21 2. A lot more discussion on a common BITNET protocol for directory searches. By this I mean that no matter what form a local directory was stored in, participating institutions could create an intermediate server which would translate between the common protocol and the syntactical requirements of the local facility. End users would then need to know only one protocol and the list of nodes which subscribed to it. I will post a copy of this correspondence to the USRDIR-L list in the hope of provoking further discussion on both of these ideas. * Editors note: I see your point, in that getting people to register in a name server is terribly difficult. However, I don't see the problem as a hardware or software one, (i.e command syntax, local vs. distributed servers, etc.). To coin a cliche, we have a "people problem". Assuming that NAMESERV@DREW is a workable central name server, we have two questions: Why don't people register themselves, and how can we get them to? I think this largely stems from the greater problem: People are uninformed, there is no true users guide, and so on. We need something that says, "Step 2 in becoming a BITNET user: Register yourself with the central name server." The alternative is to require/encourage nodes to automatically register their users with a central name server. This, of course, poses some software and cooperation problems, but certainly less than, say, LISTSERV. In terms of command syntax and the plethora thereof, I object to most of them. If NETSERV can have a neat full screen query (NETNAMES) I don't see why one couldn't be written for a central server. My objection to a central name server is the problem of links. Once we get everyone to register, the server is of no use if people can't access it. Perhaps yet another mod to LISTSERV... nah. From: W. Dean Pesnell Subject: The Eastern Bloc and Censorship The astronomical community uses BITNET and EARN to bridge the distances and time zones between individuals in the same field. At present there are limited connections to Moscow, Warsaw, and Budapest to talk to people at institutions in those countries. Increasing the number of nodes is always on their minds and any help would be appreciated. 1 Page 22 Something more intriguing is the lack of access to South Africa. Due to the efforts of a single individual in the State Department, mail sent to South Africa is halted at a European node - not in the USA. There are other connections to South Africa that enable US government agencies to talk to South Africa on a more or less daily basis. Only private communications are disabled by the decision of this unnamed individual. Any information as to why US mail can be halted at a foreign node would also be appreciated. * Editors note: We received a number of letters about Alejandro Kurcyns letter about the potential problems of linking EARN or BITNET to the Soviet Union. I think that this one sums up the major points nicely: From: Michael Bloom Subject: The Soviet Union Contrary to the assertion by Alejandro Kurczyn that the Russians don't want to learn English ("Let's Bring BITNET to the Soviet Union"), my impression is that the Russian people are among the most enthusiastic students of our language in the world. English enjoys roughly the same status in Soviet grade school and high school curricula as French in this country, and there are various indications that their children learn more in school than ours. Moreover, there is much more incentive for the Russians to continue to practice English, both because English has become the de facto trade lingo of the world and because America still represents a sort of promised land. (Remember the scene in the movie "Moscow on the Hudson" where Robin Williams and his friend the clown practice their English by discussing Hemingway?) The Voice of America, and other English-language broadcasts, offer anyone who owns a radio a terrific opportunity to keep up with the language. Educated Europeans in general (which the Russians consider themselves) speak several languages as a matter of course, given how many different countries and native tongues are in close proximity. In contrast, we Americans don't feel the need to accommodate anyone else's speech at home (comfortably far from French- speaking Quebec or Spanish-speaking Puerto Rico)-- and I fear we've become so chauvinistic that we've grown to expect the rest of the world to adapt to our language, and culture, forever. From: Gershon Kunin Subject: Listserv Lists Over the last few months, the number of LISTSERV lists on BITNET has been on the rise. In principal, this is a good 1 Page 23 thing, and has led to cooperation between people and institutions to a degree that a mere three or four years ago couldn't have been imagined. But what happens when three or four people each start a list on a specific topic, without realizing that there is already a list out there which handles that topic, or one close to it? An example of such a thing could be ADVISE-L and LIASON-L. Both lists are certainly among the most helpful on the LISTSERV, but there is redundancy between them. There's REXX- L, and a new list CMSUG-L was just started. How much repetition can we expect to see between these two lists? A person may write to one of the lists, and the person with the best answer may be subscribed to the other! The point that I'm trying to get across is that there should be some kind of coordination among the various lists, with (more or less) specific topics being set out for each list. There might be a central clearing house for starting new lists. Before a new list is started, someone should see if this list isn't basically another name for an existant list. Users should also know what lists are available for them to subscribe. I don't mean the LIST GLOBAL command that's available now, as it's a bit too heavy (1000+lines). What might be more reasonable might be something like this: a user sends a LIST LISTS command to the nearest local LISTSERV. He receives a list of lists only, with a one-line explanation. Each list name appears once. Such a file might be 150 or so lines. If a user is interested in a list, he can send a query to his local LISTSERV, asking where is the nearest server for that list (eg. QUERY SERVER ABCDE-L). These are a couple of ideas that could make the LISTSERVs on BITNET/EARN even more productive for all of us. * Editors note: If you are planning on starting a mailing list, it might be a good idea to check Rich Zellich's List-of- Lists and LISTSERV GROUPS to make your topic isn't already covered. 1 Page 24 ********* * * 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 A subscriber can delete him/herself from the mailing list by sending LISTSERV@MARIST the command: UNSUB NETMONTH Internet users may use these methods, but must address the mail to LISTSERV@MARIST.BITNET * Back issues: BITNET users may get NetMonth back issues from the file server LISTSERV@CMUCCVMA. For a list of files, send the server the the command: INDEX NETMONTH * 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 25 * 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." ***************************************************************