******** ************************************************** * * * * * The independent guide to BITNET * * * * * * August, 1988 * * * * * * Volume 3, Number 2 * ******** * * * * *** * * * * * * * * * * * * * * * * * * ** * * * * * * * * * * * * * * * * * * * * * * * * ****** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ******** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ******** * * * * * * * * * * * * * * * * * * *** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *** * * * * * * * * * * * * * * * * * * * * ****** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * **** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ****** * * * * * * * * * * ******** * * * * * * * * * * * **** ************************************************** 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 Price of Victory MOSS @ YALEVM ******************** Contents - Issue 24 ******************** EDITORIAL PAGE_________________________________________________ Bitnotes .................................................... 1 The Human Factor ............................................ 4 FEATURES_______________________________________________________ Announcing NAMESERV@DREW .................................... 8 The BITNET Board Report .................................... 10 DEPARTMENTS____________________________________________________ Headlines .................................................. 13 Helpdesk ................................................... 15 New Mailing Lists .......................................... 17 Feedback ................................................... 20 Policies ................................................... 22 * 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 * * * * BITLIB@YALEVM ********* "Fuzzyness is next to cleanliness." August 13th, 1988.... I finally ventured forth to a BITNET Technical Meeting. These are usually held in odd places on the west coast or odder places in middle America, depending on where SHARE is at the time. Luckily, this one was held in that giant among metropoli (metropolises?), New York City, a spot easily accessable to poor Connecticut residents like myself. I started off the day with a Typical Stupid Move. My train arrived at Grand Central and I had 45 minutes to spare before I had to get to Hunter College. This, I found, was *only* 24 blocks away. With plenty of time on a hot, muggy, day (and the ozone level at record levels) I decided to walk. Somewhere around Bloomingdales I came to my senses and took the rest of the trip on the subway. By now, some of you are asking, "What senses?" Highlights of the day... My first surprise of the Technical Meeting was finally meeting Judy Molka. Since she is leaving the BITNIC to attend University of Pittsburgh, I didn't expect to see her there. I had time to think up several witty lines for the occasion: 1. "You're much shorter in person." 2. "So you are the infamous Judy Molka." 3. "There is a multilegged creature on your shoulder." I decided on Option 2, a simple and not *too* strange choice. When I finally made my identity clear, I received the obvious reaction: "I expected you to have a beard." 1 Page 2 I suppose I should be pleased with reactions like that. After all, it is better than, "Eeeeeww! Yuck!", right? Scott Earley (rhymes with "curly", as in his new hairstyle) was supposed to open the meeting but missed his bus. Les Lloyd (who doesn't look anything like a Trustee) and Judy filled in. Les managed to supply us with a few new jokes: *Q* How many programmers does it take to screw in a light bulb? *A* None, it's a hardware problem. *Q* How many polite New Yorkers does it take to screw in a light bulb? *A* Both of them. We eventually broke up into our various working groups. I decided to attend the Inforep session, which Scott Earley chaired. Luckily, he recently posted a summary of that meeting: I. Create an INFOREP Packet A. Suggested contents 1. LISTSERV related a) command summary i) what is it? how to get off? who has control over? b) auto-SUB INFOREPs to certain lists i) BITNEWS, NETMONTH, CCNEWS, LIAISON, etc. c) 10 most informative files at BITNIC's LISTSERV 2. Postmaster Canon a) current action item of Board NETUSE-C committee i) urge POSTMAST userid at new nodes 3. online HELP files/tools a) for CMS shops from BITLIB@YALEVM b) for VMS shops from VMSSERV@UBVMSD 4. Internet a) tools, mailers b) Domain registration procedure c) manners, etiquette B. Distribution 1. over BITNET to new INFOREP 2. cc: over BITNET to INFOREP at 'via' a) in case of non-delivery to new b) strengthen bond between neighbors 3. send by US mail also? II. Guidelines for network use A. by Servers 1. file size restrictions a) individual 1 Page 3 b) cumulative bytes over 24 hours c) delegating authority 2. subscription a) duration of b) deletion from i) 'SIGNOFF * (NETWIDE' ii) after some elapsed time B. by General users 1. file size 2. unprofessional personals 3. job soliciting 4. software distribution C. enforcement 1. limitations 2. procedures III. User Directory ("white pages") A. invite participation by INFOREPs 1. define known servers around network 2. solicit comments on design and use 3. professional purposes only IV. Weird Gateways A. make an effort to inform users 1. heed to responsible limitations (End of summary) One of the more interesting points that came up was the development of the new name server at DREW (highlighted somewhere in this issue). This is an attempt at building a real, central name server for the network. The problem (as always) is getting people registered in its database. People in our session were invited to try out other name name servers and compare features and make suggestions. The best point to come out of the Inforep session was the recommendation to create "new user packets" for new Inforeps and new BITNET users. There were plenty of suggestions about the content, but there is some confusion as to who will do the job and when. Most of the Inforeps seemed willing to make contributions, but someone/something is needed to tie the whole thing together. Other interesting events... Apparently I am even more infamous than Judy Molka. I heard no end to questions and comments about what I could/should/would write about the events of the day. This was very helpful, although I am aghast that everyone thought I was there in a "journalistic" capacity. 1 Page 4 During the long lunch hour some of us took a walk around Central Park. It seems that we went in the wrong direction in the search for an entrance, hence the walk *around* and not within. Later in the day I met Randi Robinson, who gave me a mini-tour of City University of New York. She is one of those people on the network that has been on the network so long that I should have met her a long time ago, but never did. Randi lives in Connecticut so I had someone to bore... er, gab with on the train ride home. When the reports from the other working groups come in I will put them in NetMonth. The exiting Autumn awaits. Virtually, - Chris ********* * * The Human Factor * * * * by Timothy Stephen * * * * Rensselaer Polytechnic Institute * * * * STEPHEN@RPICICGE ********* The Fall semester is here and like the dawn of any day, there are those who have waited for it with excitement and there are those who are indifferent to its arrival. For some, the start of the 88-89 academic year signals new opportunities to learn and explore, new possibilities for achievement, new challenges, new avenues for creative enterprise, new prospects for refining or developing social relationships. For others, however, the coming year seems simply routine, just another turn of the wheel. I confess a little schizophrenia in this department. My feelings about fall semesters have run both ways over the school years, this being the 32nd new one that I've faced. However, I think I've discovered that my feelings are influenced by my sense of whether the coming year will provide opportunities to build upon the previous one (to learn more about an exciting subject that I've been studying, to extend my research another step, to refine a course I've been teaching, to renew or extend rewarding professional relationships) or whether it seems that the new year will only offer more of the same old crap-ola. I think that I feel most optimistic when 1 Page 5 the prospects for a new year are for controlled change in a constructive direction. For me, no growth means boredom and anxiety. BITNET, of course, has almost become synonymous with the idea of growth. The dream of a comprehensive inter-university electronic communication network is virtually fulfilled. By last spring, in fact, it had become evident that as the number of connected schools is so rapidly increasing, so too is the need for basic technological enhancements: wider bandwidth (i.e., the ability to pass more information between computers at the same time), dynamic routing (raising the IQ of the network software so that it can automatically route messages around machines that are temporarily broken) and greater speed. These are challenges for the future, the sort that make a new year interesting and exciting to participate in and I hope that they'll bait the interest of enough technologically oriented people that solutions will be identified and adopted before gridlock brings BITNET to a standstill. The real challenge for the coming year, however, is to find ways to sensibly manage BITNET's environment and channel its growth. What has been created is far from a finished product. It remains a system, as the real estate agents would say, "with lots of potential" rather than a system whose value to higher education has been established unassailablly. The coming year and those that follow soon after are going to play a determining role in the future of inter-university networking. If much is accomplished during this period, the future of networking in higher education will be assured. However, if BITNET's most important problems remain unresolved, it may actually begin to hinder networking's future, serving as an easy negative example. The days of innocent, unquestioned faith in academic computing are over -- no one still believes that computers are going to magically transform the business of education. These days one must deliver or decamp. With the exceptions already mentioned, the important problems in BITNET's future are less technological than organizational. For example, though it is clear that a faster network would be better, increases in speed will be of little consequence in an environment where nodes stay off-line for hours or days at a stretch due to poor or irresponsible management. When I called one central site to ask about the prognosis for their downed BITNET connection I was told, "Sorry, BITNET is Joe's baby and Joe is on vacation." I recently called another school to ask why they were disconnected from the next site up-stream. I was told that although it was known that the problem was at the up- stream school, staff had been instructed that they were not to use the phone to report problems to neighboring nodes. I 1 Page 6 called the up-stream school (where the problem had not been noticed) and the situation was quickly straightened out. Dynamic routing would help the rest of us to avoid the inconvenience created by irresponsible schools, but it is small consolation for users at those schools to know that everyone else's mail is successfully avoiding their node. One of the greatest problems continues to be the lack of any mechanism for enforcing needed standards. In what seems to be an effort to connect as many schools to BITNET as possible, the BITNET Board of Trustees has apparently chosen to admit virtually anyone and standards have been almost completely neglected. Schools are allowed to connect that don't provide local support or documentation for BITNET, subjecting the rest of BITNET's user community to the otherwise avoidable errors of underinformed users. Schools are allowed to connect using software that returns mail to the sender when the recipient's mail box space is full or too small (think about it: you send someone mail and it comes back because too little space has been allotted for the receiver's mailbox. What do you do next?) Schools are allowed to connect that assign users needlessly complex userids (1Xl1CJOZ@SOMENODE), contributing to a constant stream of returned mail. Schools are allowed to connect using clustered computer systems that assign a user a node name that may change from one terminal session to the next. This creates chaos for servers that keep track of usage statistics and automatically deliver start-up information to new users. Schools are allowed to connect that issue userids that are longer than eight characters. This wouldn't matter except that other schools are allowed to connect which, even after persistent urging from faculty, still refuse to install and maintain public-domain mailer programs. Other schools that have been allowed to connect do have mailer programs, but ones which issue error messages encrypted in some kind of computer gobbledegook. And even at this late date, schools are allowed to connect that deny students access to the net. Many of these problems could be solved without much difficulty if people were interested in taking them on. But since they have persisted so long, it seems doubtful that they are going to go away without organized intervention and that should come from the Board of Trustees. Will 88-89 be the year that the Trustees begin to play a more visibly active role in smoothing out BITNET's wrinkles? Will we see standards proposed, discussed, adopted, and finally enforced? The alternative is that the net will continue as an anarchy where site administrators enact policy as if it affected their own users only and as though they have obligations to no one else. I hope that the Board is looking with excitement at 88-89 as an opportunity to lead BITNET up the next rung of its evolutionary 1 Page 7 ladder. Leadership is needed indeed as the challenges and problems of human organization are often as complex and subtle as any in the area of technological development, sometimes more so. I hope too that others in BITNET's user community are looking at the year ahead as one rich in possibilities for creative involvement and activity -- not content to be passive consumers of the net, but aware of the important role that users have played in BITNET's evolution. If BITNET was merely comprised of a set of technical specifications, communications protocols, and software systems, the role of the user would be sharply reduced. In fact, however, if BITNET's success were to be computed, it would have to be as a function of its relevance to the everyday activities of higher education. Every such activity that has occurred on BITNET to date has come about through the unsponsored and spontaneous efforts of individual users. As we move into the first days of the 6th year of BITNET, it is increasingly difficult to characterize BITNET as a "new" network. It is now in place and it is now time for it to begin to demonstrate its potential to higher education as a whole. To paraphrase Francis Bacon, potential is a good breakfast but a bad supper. 1 Page 8 ********* * * Announcing NAMESERV@DREW * * * * by Les Lloyd * * * * Drew University * * * * LLLOYD@DREW ********* If you have ever searched aimlessly for that friend or colleague that you knew existed somewhere on BITNET but didn't know where, you will be very excited about at new BITNET feature created at Drew University. Titled NAMESERV, this VMS based program allows people anywhere in the BITNET, NetNorth or Earn communities to register not only names and electronic addresses, but also some keywords about themselves. Anyone on the system can then search for a user by looking for first and/or last name, node name or any of the up to 5 keywords the person may have entered. NAMESERV will accommodate any of the approximately 500,000 people throughout the world connected to BITNET or its affiliated networks. The information provided below will give you an idea of what NAMESERV can do. Of course, at any time, you can SEND NAMESERV@DREW HELP and receive up to date HELP information on using the system. To receive the entire help file, just send the command HELP FILE to NAMESERV@DREW via mail or message. * REGISTERING: Registering on NAMESERV is easy. Just send a command in the following format: REGISTER first last Õkeyword1...keyword5å For example: REGISTER John Doe physics modula_2 engineering How you send this command to NAMESERV@DREW depends on your system. If you are using a VAX/VMS/JNET system, you would use the SEND command. People on VM/CMS systems should use the TELL command. Of course, you can always send commands to NAMESERV as the only text of a mail message. Consult your local documentation for more information. The system does not care about upper or lower case entries, they are shown above for clarity. NAMESERV will keep track of the date you registered and each year on that date will send you a re-registration reminder. If you don't re-register, your 1 Page 9 name will be automatically dropped from the list (you will be sent another message when you are dropped). This will allow the system to maintain an up to date list. If you re-do your registration at any time during the year, the date you re- register will be the new date upon which the one year expiration period will be based. The system was created for academic and professional use. Registrations are screened by the name server for keywords that might be inappropriate or might encourage inappropriate uses of this feature. We are very excited about providing this service to users of the network, but are committed to BITNET's usage guidelines and principles and will make sure our service does not allow for violation of those policies. * SHOWING YOUR REGISTRATION INFORMATION: To see what your entry looks like, send the command SHOW and your registration information will appear. If you want to change it, just re- register as shown above. * SEARCHING FOR ANOTHER USER: There are a variety of options that allow you to search for different information. The general format of the command is: SEARCH/Õqualifierå search_pattern The qualifiers are as follows: NAME: Looks for first and last name, i.e. JOHN DOE. This is the default if no qualifier is present. FIRST: Searches for first name only LAST: Searches for last name only USER: Looks for the username. You may enter the full address (USERNAME@NODE) or just the username. NODE: Will locate all users at a specific location FIELD: Searches the keyword fields for matches Examples: SEARCH/NAME John Doe SEARCH/NODE Drew SEARCH/FIELD physics SEARCH/USER JDOE * REMOVING YOURSELF FROM THE SYSTEM: If you want to remove yourself from the NAMESERV database, simply send the server the REMOVE command. 1 Page 10 This program was written by Drew junior Jac Fried. Jac spent several weeks this summer designing and programming this innovative feature. If you have any suggestions or comments for Jac, please send him mail, his address is JFRIED@DREW. ********* * * The BITNET Board Report * * * * by the BITNET Board of Trustees * * * * from BITNET Board Newsletter * * * * Send your comments to BOARD-L@BITNIC ********* * BITNET/CSNET MERGER STUDY: Gillespie, Folkner and Associates have been hired to identify the potential costs and benefits of a BITNET/CSNET merger. They have been engaged in this work and are expected to produce their report in August. A review of the report is scheduled for August 24 and will be reported on separately. * MEMBERSHIP IN BITNET VERSES OTHER NETWORKS: The Board discussed briefly the possibility that some prospective BITNET members may not join BITNET since they may be able to obtain many of its benefits via gateways to other networks. The Board feels very strongly that membership in BITNET conveys real advantages, and also notes that the BITNET advantages could disappear if many institutions chose not to join (!). This issue is one of the primary reasons for studying a possible merger with CSNET. The Board has resolved to draft a paper outlining the advantages of BITNET membership to inform prospective members and to focus its thinking on the strategic issues which BITNET must preserve. * NETNORTH, EARN AND OTHER COOPERATING NETWORKS: Many sites in foreign countries have connected to BITNET over the last year and more continue to apply. The Board has concluded that it does not make sense for BITNET to accept membership by sites from foreign countries, except as an interim step. Instead we wish to encourage a model of regional "cooperating networks" with membership rules conformable to BITNET such as EARN and NetNorth. Among the issues motivating this conclusion are minimizing communications costs and encouraging self- sufficiency in the regional networks for management of node tables and other NIC support. 1 Page 11 To this end the Board has drafted a "Cooperating Network Agreement." A number of Persian Gulf institutions had applied to BITNET for membership; assuming their membership rules prove to be conformable to BITNET's, our expectation is that rather than membership in BITNET per se, we will execute a Cooperating Network Agreement with "GULFNET." The number of institutions already connected, or expressing interest in connecting to BITNET in Japan, and in various Central and South American countries suggests that both of these regions may also be maturing toward eventual status as cooperating networks, assuming those foreign institutions agree. * "BITNET II" PROJECT / BITNET DISCOUNT AGREEMENTS: Ira Fuchs reported to the Board on the progress of the BITNET II research. An overview of the BITNET II project and its current status has been prepared as a separate paper and is available from LISTSERV as BIT_II INFO. Related to the BITNET II research is an effort by BITNET to make the equipment required for a BITNET II installation affordable. Early this year, BITNET announced an agreement with cisco Systems offering a substantial discount (30%) on cisco products used to enhance BITNET connectivity. In July, BITNET announced a second vendor discount agreement with Bus Tech Inc. for an IBM channel/ethernet interface at a very attractive price ($5,900). BITNET BIRs should have received a mailing on this offer directly from BTI. These two agreements help to make the IP router and the ethernet interface required for implementation of BITNET II affordable. We are now actively negotiating for an excellent price on a high performance modem to complete the required equipment. * NETWORK USAGE ISSUES: Over the last year a number of usage issues have come up which suggest BITNET needs to re-examine its usage rules. For example, current rules prohibit the shipping of "proprietary software," yet copyrighted software is shipped over BITNET regularly; rules prohibit commercial use of the network, but some members would like to see limited software support available over BITNET; rules prohibit commercial use of the network but, at members request, the Board has agreed to a trial allowing a commercial service to forward mail into and out of BITNET. CSNET allows commercial membership - any merger would require BITNET to understand well the basis for its current rules, that is, which rules might be usefully relaxed and which maintained. To this end, the Usage Committee has been charged with drafting a discussion paper on usage issues. As soon as a draft has been reported out of the Usage Committee, it will be posted to the NIC with notification to BITNEWS to solicit membership as well as Board comment. 1 Page 12 * BITNET FINANCIAL STATUS: Due to rapid membership growth and the open NIC manager's position, BITNET has a surplus for FY87/88. This surplus will grow slightly as delinquent membership fees are collected (there are not many delinquencies, but there should be none!). * THE NETWORK INFORMATION CENTER: In April, the BITNET Board of Trustees sent out a User Survey to over 300 BITNET Institutional Representatives. While participation was disappointing (only 49 BIRs responded), the survey proved useful in several respects. The Board is working on a new service agreement and will use the feedback from the user survey to ensure that the NIC service priorities are consistent with the views of the users. Specifically, the responses indicated a need for more detailed "new user" documentation, better communication between the Board and members, and more technical expertise at the BITNET Network Information Center. Also listed as priorities were a directory of users, LISTSERV expansion, domains, a move to TCP/IP, and consolidation of networks. The Board discussed the open NIC Director position and agreed that, in the face of the continued growth of BITNET membership, this position should be full-time. The Board then approved the current level of NIC service for the coming year (and the corresponding budget), but charged the Services Committee to examine whether additional services may not be required as well. The Services Committee is also to recommend how any additional services might be provided; for example, it may be appropriate to sub-contract "one-time" or short lived services rather than budget permanent staff for them at the NIC. 1 Page 13 ********* * * Headlines - smaller pieces of news * * * * by Christopher Condon * * * * Yale University * * * * Send them to BITLIB@YALEVM ********* * Good Reading: The University of Texas System Office of Telecommunication Services' July 1988 edition of the "Users' Directory of Computer Networks Accessible to the Texas Higher Education Network Member Institutions" is now available. This directory contains general, host, domain and contact information, maps, an electronic mail tutorial and an organization index for networks such as ARPANET/MILNET, BITNET, SPAN, CSNET, ESnet, HEPnet, MFENET, NSFNET, SPAN, THEnet, USENET/UUCP and Internet Domains. The purpose of the directory is to ease the difficulties of working with various networks by providing complete host and domain lists. In addition to the hard copy version, there is an on-line version available to Internet users via anonymous FTP to EMX.UTEXAS.EDU. The printed version of the directory differs from the ftp version primarily in the inclusion of maps and fancier formatting of the tables and host information. The printed version can be ordered for $15 (please add $2 for postage and handling) from: The University of Texas System Office of Telecommunication Services Balcones Research Center 10100 Burnet Road Austin, Texas 78758-4497 Thanks to Tracy LaQuey for this information. * LISTSERV news: Two new LISTSERVs are up and running: LISTSERV@ALBNYVM1 and LISTSERV@UWAVM. Thanks to Jim Derost and Ben Chi for this update. * New name servers: Two new name servers are up and running, but we were unable to acquire documentation in time for this NetMonth. Dare we say it? The links were down. They will be covered in detail in the next issue. In the meantime, the servers are: WHOIS @ ALBNYVM1 - State University of New York at Albany INFO @ IRUCCIBM - Cork University 1 Page 14 Both of these servers accept commands via mail or message. Thanks to Terry Sommer and Ben Chi for the information. * EDUCOM to Move Offices and Explore Mergers: EDUCOM, a consortium of more than 500 colleges and universities involved in computing, will move its headquarters from Princeton, N.J., to Washington this fall. The move is designed to make it easier for EDUCOM to work with federal government agencies and other higher-education organizations, said Kenneth M. King, president of the consortium. The principal issue that requires the move, Mr. King said, is "the requirement to raise on the order of $100-million a year for the next 10 years" to establish and operate a national network for instruction and research. EDUCOM's efforts to improve integration of computers in the curriculum also requires working with organizations representing academic disciplines as well as organizations of college presidents, he noted. EDUCOM is also exploring mergers with both the Interuniversity Consortium for Educational Computing and CAUSE. The 28-member I.C.E.C. works with computer manufacturers and software publishers to encourage the development of machines and software appropriate for higher education, and has developed software for advanced computing in education. CAUSE, which has about 700 members, is a consortium based in Boulder, Colo., that focuses principally on administrative- computing issues. EDUCOM works predominantly on academic- computing issues. "The networks on campuses and the microcomputer revolution are bringing administrative and academic computing together," Mr. King said. "As one organization," he added, "we could address the whole spectrum of university technology issues." Õfrom The Chronicle of Higher Education, July 20, 1988å Thanks to Lee Wolfle. 1 Page 15 ********* * * Helpdesk - a Question and Answer Column * * * * by Marc Shannon * * * * Carnegie Mellon University * * * * Send your Questions to HELPDESK@DRYCAS ********* My, my, how time flies when your world is changing rapidly around you. I've now switched jobs, been "awarded" a beeper (to make me one of the few local miracle-workers-on-call), and managed to find myself desperately in need of a vacation. I think I may survive long enough to finish up this (belated) column... First, to those of you whose mail to HELPDESK was rejected, I have fixed up the mail setup on DRYCAS. It seems that a "feature" of VMS MAIL which worked under VMS V4.x no longer works with V5.0. These are the trials and errors from which we all learn. Here are some questions which are on file... *Q* Who maintains the actual physicals network of links? IBM? *A* As you may know, each link on BITNET has a direction toward the hub, CUNYVM. Each site which connects to BITNET makes a link to a node which has a link to another node (which has another link to another node...) which all finally end up at CUNYVM. The site which makes this new connection will pay for the line (generally a leased-line via the local phone companies) and also the hardware to connect at both ends (usually a pair of high speed modems). Each site, when connecting to BITNET, is required to provide service to connect an additional node to that site. This provides for continual expansion of BITNET (although many theorize that BITNET is too large already). The international link between CUNYVM (actually CUNYVMV2) and FRMOP22, in the past, was paid for by IBM. Due to budgeting restrictions, IBM discontinued monetary support for this link. It is now being paid for by EARN (the European counterpart to BITNET). 1 Page 16 *Q* When a link goes down, who/what's usually at fault? *A* There can be many reasons why a link is not working. First, let's look at the different "states" of links in an NJE network (which BITNET is)... CONNECT: Both sides have negotiated the appropriate networking parameters and have made a successful connection. (Since no communication goes over a link unless there is data queued for that link, it is possible for a link to show up as CONNECT when it isn't. When one side attempts to send data to the other, it will then change the link status.) ACTIVE: The side of the link which is ACTIVE is ready to connect to the other side but is not able to reach the other end of the link. Often, one side of a link will show up as ACTIVE and the other as INACTIVE. (Sometimes both sides of the link will show up as ACTIVE and not be able to connect. This is often due to a synchronization problem and can be fixed by restarting both sides.) INACTIVE: INACTIVE links are "shutdown". No attempt to communicate with the remote computer is made. If a link is INACTIVE ("FROM WVNVM: LINK OHSTVMA INACTIVE") then WVNVM, in this example, is "at fault" and they would need to start the OHSTVMA link. If a link is ACTIVE ("FROM PSUVM: LINK CUNYVM NOT CONNECTED") then it is generally assumed that either there is a communications problem (the leased-line or the modems are out of service) or that the other side of the link (CUNYVM->PSUVM) is INACTIVE. If the link state is CONNECT but no traffic seems to go through properly (it may appear to be a black hole and not respond with any error though you do not get any response to your commands or messages), there is most likely some connectivity problem which the local system has not yet determined or resolved. System programmers and data communications people would need to properly identify the problem in such a situation. 1 Page 17 ********* * * New Mailing Lists * * * * by Rich Zellich * * * * from List of Lists * * * * ZELLICH@SRI-NIC.ARPA ********* AVIATION Aviation discusses topics of interest to pilots, including training systems, laws affecting availability or usability of airports, planes, and procedures, characteristics of aircraft and avionic products, comments on commercial aviation, such as safety and convenience issues, occasional advertisements for fly-ins or similar private pilot activities, historical notes, whatever else the readership wants. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to AVIATION- REQUEST@MC.LCS.MIT.EDU. Coordinator: Oded Feingold Gaylord Miyata CMSUG-L This list unmoderated discussion for topics that relate to CMS; any related question is encouraged. The list is intended for the beginner as well as experienced CMS users. To subscribe to the list send the collowing command to LISTSERV@UTARLVM1 via mail or message: SUBSCRIBE CMSUG-L your_full_name. Coordinator: Gary Samek FACSER-L FACilities and SERvices is a LISTSERV for the exchange of ideas related to college and university facilities and services, including: Physical plant operations Security and public safety Transportation and parking Telephone 1 Page 18 Mail service Environmental health and safety Capital planning Facilities utilization To subscribe to the list send the collowing command to LISTSERV@WVNVM via mail or message: SUBSCRIBE FACSER-L your_full_name. Coordinator: Roman Olynyk FIREARMS-POLITICS Mailing list for the purpose of political discussion, announcements, and coordination in the area of firearms legislation and general talk about 2nd Amendment rights and current trends. Companion mailing list to FIREARMS@TUT.CIS.OHIO-STATE.EDU, which is restricted to technical discussion. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to FIREARMS-POLITICS- REQUEST@TUT.CIS.OHIO-STATE.EDU. Editor: Karl Kleinpaste FRAC-L Mailing list dedicated to the computergraphical generation of fractal images. In conjunction with the list, an archive of programs submitted by users will be maintained. Mr. Homer Smith of "Art Matrix" in Ithaca, New York, has donated a program library, which will soon be available from LISTSERV at GITVM1. To subscribe to the list send the collowing command to LISTSERV@GITVM1 via mail or message: SUBSCRIBE FRAC-L your_full_name. Coordinator: Michael Burtz HUMANIST HUMANIST is an international electronic discussion group for computing Humanists and for those who support the application of computers to scholarship in the humanities. It currently 1 Page 19 consists of nearly 300 members in 13 countries in North America, Europe, and the Near East. Relevant topics are technical questions about hardware and software, specific problems in humanistic scholarship, and both the administrative difficulties and philosophical issues arising from the application of computing to the humanities; calls for papers, bibliographies, and reports of lasting interest are also welcome. Interested individuals should send a note together with a brief biography to the Coordinator in the following format: Family-name, Given-names Title, mailing address(es), telephone number(s). Body of biography. This should not be a c.v. and need not be very detailed but should cover the full range of your professional activities and interests, both present and past. Mention other things at your discretion. Biographies vary considerably in length, though few are less than 100 words or more than 500. Coordinator: Willard McCarty INFO-FRAME Mailing list for System Frameworks. This group is designed to provide information for software tool developers that are responsible for integrating heterogenous software products. This can include in-house and vendor supplied. Usually, the integration of the products is designed to provide an environment that makes using the tools easier. The basic issue is to build a `framework' around the tools that provides a common and consistent view of the system. The framework is not limited to homogeneous environments, but also can span heterogeneous systems. Companies like EDA and government sponsored projects like EIS are trying to tackle this problem. This group can be viewed as a forum for users and developers to voice their opinions on this subject. Frameworks are common in the area of CAD/CAE, CASE and office automation; but they are not limited to only these areas. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to INFO-FRAME- REQUEST%LOKI.EDSG@HAC2ARPA.HAC.COM. Moderator: Louis McDonald 1 Page 20 MEDNEWS The MEDNEWS list is for distribution of the Health Info-Com Network medical newsletter. It is distributed weekly and contains the latest MMWR from the Center for Disease Control, weekly AIDS Statistics, FDA bulletins, medical news from the United Nations, and other assorted medical news items. Submissions for the newsletter are welcomed; please contact the Editor if you have any questions or newsletter submissions. To subscribe to the list send the collowing command to LISTSERV@ASUACAD via mail or message: SUBSCRIBE MEDNEWS your_full_name. Editor: David Dodell ********* * * Feedback * * * * a Letters column * * * * Wherein we see the final word on the Soviet Union * * * * Send your letters to BITLIB@YALEVM ********* From: Hank Nussbacher Subject: More on Russia and networking... Some comments on David Hibler's July editorial: First, let me correct you on one point. The Soviet Union has requested connection to the network but not to BITNET - rather to EARN. If you are in favor of open communication paths then perhaps the United States and people within BITNET should stop using geocentricism when assuming that all networks revolve around them. True, many do, but the fact that Russia (and Hungary and Bulgaria) have requested EARN membership and not BITNET membership should say something to you. The major problem of connecting all these communist countries to the network is not a security fear. It is the US Dept of Commerce that forbids it. Whenever any country buys a supercomputer from the United States (Cray or ETA for example) they are required to sign a very stringent agreement with the US Dept of Commerce that that supercomputer will not be made in any way shape or form available to communist countries - which includes via electronic methods. The US Dept of Commerce realized that one way around the trade ban would be for a non- 1 Page 21 aligned nation to order a Cray XMP/48 and install an M1 (2Mb) line to Moscow. True, the computer never made it over the border, but its computing power would be sent over the border. So, all EARN sites (as well as many Canadian sites) that have a super computer connected directly or indirectly to BITNET or EARN would have to *renegotiate* their contract with the US Dept of Commerce. Feelers are being made in that direction, but the game is just in the early innings so it is too early to tell if the US Dept of Commerce will relent and alter the supercomputer licences already issued. EARN has been working over the past year on accepting various new countries to their network. Voting was concluded last year for four new countries and their ratification was formally approved: Algeria - University of Annaba Cyprus - University of Cyprus Luxembourg - CEPS/INSTEAD Yugoslavia - UNESCO International Centre Last month two new countries have been ratified as valid for EARN and they are: Morocco - EMI India - Tata Institute Currently, EARN is discussing requests from 3 eastern countries to join EARN, principal among them is the USSR: Hungary USSR - USSR Academy of Sciences Bulgaria There are various legal problems with this and it may be some time before a formal decision is reached. Just thought I'd let you all know how things are currently rather than the usual speculation and philosophy behind this topic. From: Alejandro Kurczyn Subject: Let's Bring BITNET to the Soviet Union I wish to comment on the article that appeared in the July issue, regarding the inclusion of the USSR in BITNET. I think we must think seriously on this idea, and to think in the problems it will carry, some of them might be: 1 Page 22 * Language: I doubt the russians will want to learn english, or north americans Russian. This will cause a great lack of communication on both parts. * Net load: How many nodes in the USSR are going to get into BITNET? Considering the size of the USSR, it's probably they have a 'BITNET' on their own. If a whole USSR net is going to get into BITNET, this can't depend on a single link. And what about protocols? * Education: Are we prepared to know a "new" culture? Communicating with the Soviet people could get into a much better and truer knowing of cultures, but there will be troubles, one would probably see a "we hate commies" Relay channel or something like that. If one day we can communicate freely with people of places once "forbidden", and not to provoke problems, but rather promote mutual help and understanding, this world will be a better place to live. ********* * * 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 1 Page 23 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. * 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." ***************************************************************