* * * * * ** * ** ** * * * * * * * * * * * * * * * ***** ******* * * * ***** ****** ******* ****** * * * * * * * * * * * * * * * * * * ******* * * * * * * * * * * * ** * * * * * * * * * * * * * ****** * * * ***** * * * * * * * * The guide to BITNET servers and services * * * * Volume 2 Number 2 August 1987 * * * ***************************************************************** * * * Editor: Chris Condon CONDON@YALEVM * * Assistant Editor: Steve Sutter SUTTER@YALEVM * * NetMonth Staff Supervisor: Gary Moss MOSS@YALEVM * * * ***************************************************************** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ********* * * * * * * * * * * * * * * * * * * * * * * * * * ** ********** * * * * * * * * * * ********* * * * * * * * * * * * * * * * * * * * * ** * * * * * * * ******************* ****** ********* * * * * ** * ** * * * * * * * * * * * * * * * * * * * * * * *********** * * ** ******* * ** * * * * * * * * ********** * * * * * * * * * * * * * * * * **** * * * * * * * * * * * * * * * ** * * * * * * * * * * * * * * * * * ** * ***************** ***************** * ************ * * ** * * * * ** * * * * * * * * * * ** * * ** * * * * ***************** * * * * * * * * * * * * * * * * * ***** ************ * * * *************** * * * * * * * * * * * * * * * * * * * * * * * * ** * * * * * * * * * ** * ** ***************************************************************** 1 ************************************************************************* * Contents * *************************************************************************** Bitnotes ................................................................ 1 TAKE NOTE__________________________________________________________________ Scuttlebut .............................................................. 4 BITNET User Statistics .................................................. 7 FEATURES___________________________________________________________________ The Best of the Big Flamage ............................................. 8 Commentary on WISCVM ................................................... 13 SERVERS AND SERVICES_______________________________________________________ The Poetry Server: BIALIK@BRANDEIS ..................................... 17 A New Name Server: WHOIS@UKCC .......................................... 18 DEPARTMENTS________________________________________________________________ Feedback ............................................................... 19 Policies ............................................................... 22 NetMonth is a network service publication distributed free of charge to students and professionals in BITNET and other networks. This magazine and it's companion file, BITNET SERVERS, are the work of the Yale Computer Center BITNET Services Library (BITLIB) staff. The BITLIB is a local online help facility designed to inform Yale network users about what services are available to them through BITNET, and provide instructions and utilities for their proper use. In publishing NetMonth the BITLIB staff members hope to share the fruits of their labor with institutions outside of Yale in order to promote a productive and enjoyable networking environment for everyone. The BITLIB system is now distributed to more than thirty educational institutions worldwide. BITNET SERVERS is BITNET's most complete and up-to-date list of servers and services. It is sent to NetMonth subscribers at the same time as the magazine. BITNET SERVERS is dependent on your support to remain accurate. If you know of servers and services not listed in BITNET SERVERS, or of those listed in the file that are no longer available, please contact the NetMonth staff at BITLIB@YALEVMX. For information on subscribing to NetMonth and BITNET SERVERS, see the "Policies" section on the last pages of this issue. Within "Policies" there are also instructions for submitting articles, sending Letters to the Editor, and printing this file. ----------------------------------------------------- A publication of the Bitnet Services Library "Because We're Here." 1 Page 1 ************************************************************************* * Bitnotes Issue 13 * *************************************************************************** "We trained very hard, but it seemed that every time we were beginning to form up into teams, we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising, and what a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency, and demoralisation." - Caius Petronius (A.D. 66) As usual, I found myself in something of a pickle. No, it was not large and green, nor was it a kosher dill. It was the sort of pickle I get myself into when I have to take a stand on an issue. "Oh, horror!" I said, dripping with sarcasm. "I have to make some kind of decision... What shall I do, what shall I do?" It was not a pretty sight. Not only was the confused look on my face less less than attractive, but the sarcasm was leaving a slimy green trace on the floor. Another mess to be dealt with, but that would have to wait. A more pressing situation had presented itself; this was the reason for the current pickle: The position of Editor for this illustrious publication and the editorial writing that goes along with it put me in very public position (for BITNET, that is). As such I generally end up making some sort of comment on the latest crisis, whatever it may be. In most cases it is rather easy to form an opinion on a particular subject: Network load is Bad; Relays are Good. Sometimes, however, the problem involves the Network Information Center, or BITNIC as it is usually called. Now the problem (or pickle) comes to a head. This, you see, brings me into the realm of politics, a dangerous area for someone in a position where it is best to appear neutral. Still, I do have to write an editorial about SOMETHING, and it would seem sort of silly for me to comment on the weather while there is a battle raging about Issue X. Now, I don't have much of a problem with forming an opinion on anything, but here I end up in a tight spot: If my opinion leans in one direction I could be accused of acting anti-BITNIC and extremist, and much of what I say could and would be discounted as so much hot air. On the other hand, were I to lean in the other direction I might be thought of as being simply part of the establishment worthy of being ignored. Obviously, I worry too much, but it is sometimes difficult to even consider 1 Page 2 putting our image and that for which we have worked at risk. I have seen it happen to the BITNIC, and it looks very painful. What's worse, with the way I think, I stand a good chance of offending everybody on each side of the political extreme. On yet a third hand, I don't care WHAT everybody thinks, because I tend to think I am right until proven otherwise. Not that I am one to become indignant. Not me. (Gosh, that sarcasm sure is hard to clean up!) So be it. Here is the problem (finally!) Damn the torpedos, full speed ahead! The problem was apparently caused by this announcement, from the June, 1987 Bitnews: To Serve You More Efficiently In a continuing effort to make NICSERVE@BITNIC more responsive to user needs and to provide better BITNET user services, the most frequently requested files, which are also some of the largest, are being moved to LISTSERV@BITNIC. In the past, the NAMES files were automatically distributed to designated userids at all BITNET nodes, as well as being generally available through NICSERVE@BITNIC. The dramatic increase of BITNET nodes and users made the automatic distribution of these files a time-consuming as well network-clogging activity. With the efficient file-distribution capabilities of the LISTSERV file servers, we can again make the NAMES files automatically available to those who want them. You can subscribe to these files and either receive them automatically through overnight shipments or elect to be notified of file updates. As was true with NICSERVE, you can still request the files for immediate delivery from LISTSERV, if necessary. In keeping with our goal to reduce network traffic, we ask that you contact your BITNET Technical Services Representative to determine whether a copy of the file is available at your node before subscribing yourself to the list. Our plans for future efficiency improvements include making the NAMES files available only from your BITNET Technical Representative. Sending only 1 copy of each NAMES file to a member site will greatly assist in reducing network traffic. All subscribers will be notified of the impending change, and an announcement will also appear in BITNEWS. (various technical notes followed) 1 Page 3 Now the kicker: I am not overly informed about the technical matters of running the network. I post the more interesting notes from Bitnews in the Scuttlebut column, and I saw the notice the BITNIC had posted. I read it over, their explanation for their action seemed lucid, but I didn't think it was important enough for these pages. So much for my judgement. Or maybe not. It still seems that it is a technical matter that can be solved with a little sweat. Now that the BITNIC knows that their move has caused some problems, one might hope that they will address the issue. One does not expect, however, that the network at large would engage in a flaming-frenzy every time a mistake is made. They BITNIC staff has made some mistakes. They will make more. I have noticed, however, that people tend to learn from their mistakes. In any job I have had, I have made every single mistake possible (and thought up some new ones) before settling in and doing the usual bang-up job. The trick is try not to make the same mistake twice. So who is to blame, really? The notice of the NAMES change was posted on June 2nd. The Big Flamage didn't begin until early August. What happened? Well, one person who brought the action to our attention said something like this: "I felt that it was so stupid that I didn't think they would actually do it, so I waited until after they made the change." Oh, come now. How can the BITNIC be responsive to your needs if you don't tell them what your needs are? By posting a notice a month ahead of time they essentially said, "Hey, we want to do this. Tell us if you have a problem with it before it's too late." The Network Information Center cannot and will not be effective if they are called a bunch of "sales people" every time they, well, screw up. They were chosen to run the network by the Executive Committee (now the Board of Trustees) the members of which were elected by the people who run your nodes. As such, they HAVE to be given a chance to do their job. Anything less is unfair to them and to the network at large. I am not saying that the BITNIC should not be criticized. Rather, we should concentrate on the problem at hand and work together to solve them rather than question the abilities of the people who caused them. They will learn from their mistakes, and the network will be a better place for it. Virtually, Chris Condon@YALEVM See in this issue: Best of the Big Flamage 1 Page 4 ************************************************************************* * Scuttlebut * *************************************************************************** * More list servers, and the parties responsible for telling me about them: LISTSERV @ UAVM1 Craig White, Rocky Waters LISTSERV @ BROWNVM Peter DiCamillo LISTSERV @ UBVM Rocky Waters LISTSERV @ HEARN Peter Barneveld LISTSERV @ RPICICGE Peter Barneveld * WISCVM woes: (See also the article concerning the WISCVM shutdown). On December 1, WISCVM will be shut down. Hence, as of that date, we will no longer be able to provide a mail relay service between Arpanet and BITNET. WISCVM currently handles between 5 and 10 thousand messages per day. Clearly, this service is very important to the academic/research network community. As such it should be fully supported. Many of you may not be aware that at present the WISCVM relay is only supported by a volunteer student (indeed, this summer he has a full-time job off campus). Because of the (admittedly) inadequate level of support, problems arise periodically. For example, for the past day most messages have been rejected. The current problem occurred because there was some ambiguity in our instructions for installing new host tables. We would be happy to provide advice on what is required to run a supported mail relay. Besides operations and bug fixing, such support should include consulting for system administrators (if not for users). Hopefully, some suitable organization will be found to provide this service. * Ken King, BITNET Board of Trustees, is Named EDUCOM President The following is taken from an EDUCOM press release: Princeton, New Jersey--July 2, 1987: The EDUCOM Board of Trustees has announced the appointment of Dr. Kenneth M. King as president, effective September 15, 1987. Currently vice provost for computer systems at Cornell University, King has a distinguished career of over 30 years in major leadership positions in university computing services. He will replace Michael M. Roberts, named acting president last November while serving on leave from Stanford University as EDUCOM's vice president for networking. In announcing King's appointment, Douglas E. Van Houweling, vice chair of EDUCOM's Board and chairman of the EDUCOM Council, cited King's long 1 Page 5 experience in both private and public higher education across the full range of programs from community colleges to graduate research universities as providing an exceptional background for the presidency of EDUCOM. "Ken's record of innovation and service to information technology in higher education, his demonstrated leadership ability, and his clear vision make him the ideal president for EDUCOM." Currently the chairman-elect of the EDUCOM Council, King has twice been elected to the EDUCOM Board of Trustees, from 1974-1976 and again from 1984-1987, where he has served on both the executive and finance committee and the networking committee. In addition, he represents Cornell University on EDUCOM's Networking and Telecommunications Task Force. He is also on the Board of Trustees of NYSERnet, the New York State Education Research Network, and of BITNET, Inc. He was recently named by the National Academy of Sciences to a committee on improving research productivity. At Cornell University since 1980, King's leadership has encompassed microcomputing, networking, and supercomputing. In microcomputing he has initiated work with several major companies to infuse computing into the curriculum, and he represents Cornell to the Interuniversity Consortium for Educational Computing, based at Carnegie Mellon University. In networking King has directed the design and implementation of Cornell's campus-wide network as well as its participating in BITNET, NSFNET, and NYSERnet. In supercomputing he is one of the principal investigators of the Cornell National Supercomputing Center project, one of five university- based supercomputing centers established by the National Science Foundation. Prior to joining Cornell University, King spent nine years at the City University of New York, where his last position was vice chancellor for university systems. On loan from CUNY, he spent two years as director of the office of computer plans and controls and deputy director of operations in the Office of the Mayor of New York City. Prior to those positions, he served from 1962 until 1970 as director of the Columbia University Computer Center. King received his Ph.D. in theoretical physics from Columbia University in 1962 and his B.A. in physics from Reed College in 1951. He is a member of Phi Beta Kappa and Sigma Xi. In accepting the position, King said he is particularly interested in harnessing the collective energies of the EDUCOM membership to facilitate technology transfer, information exchange, and the solution of common problems. "This is an exciting and challenging time with many opportunities to dramatically improve the quality of instruction, research, and administrative systems at universities and colleges. I love being involved. I believe EDUCOM can make a significant different." 1 Page 6 EDUCOM, a nonprofit consortium of over 500 colleges and universities and 70 corporate associates, was founded in 1964 to promote effective use and management of information technology. * Availability of the NAMES Files -- Updated The following files will remain available on NICSERVE@BITNIC and on LISTSERV@BITNIC without restriction. XMAILER NAMES MAILER NAMES The BITNIC will maintain an additional list (called NAME-REQ, NAMES request) to allow one account per site to have access to the following NAMES files: BITONLY NAMES, EARN NAMES, and NETNORTH NAMES. To add an account to the NAME-REQ list, an appointed BITNET representative must submit the request to AKLOM@BITNIC. If more than one account per site is requested a brief explanation of the reason for the additional account should accompany the request. If the account to receive the file is already one of the appointed BITNET representatives, then do not request the same account be added to the NAME- REQ list. Once the account has been added to the NAME-REQ list (and the owner notified), the owner can send a command to LISTSERV@BITNIC to subscribe for automatic file distribution. The AFD function will then distribute the NAMES files overnight whenever they are updated. Presently, users on the INFOREP, TECHREP, and BIRREP lists may send LISTSERV a command to receive the files automatically. Or, alternatively, accounts with access to the files may issue the FUI command to receive File Update Information. Rather than receive the file itself, the subscriber receives a notice that the file has been updated. --Judith Molka BITNET Information Center * Committees of the Board of Trustees The Board of Trustees have set up several userids at BITNIC to which BITNET users can send mail. BOARD-L@BITNIC - composed of the entire Board of Trustees (See NICSERVE file BOARD87 MEMBERS for the complete list) EANDF-C@BITNIC - Executive and Finance (Ira Fuchs, Philip Long, Ray Neff, Leland Williams) 1 Page 7 MEMBER-C@BITNIC - Membership and Fees (Ken King, Leland Williams, John Young) NETUSE-C@BITNIC - Network Usage Policies Ben Klein, Philip Long) SERVE-C@BITNIC - BITNIC Services (Don Laird, Marty Solomon, Ira Fuchs) TECH-C@BITNIC - Technical Issues (Doug Bigelow, Butch Kemper, Ray Neff, Ben Klein) ************************************************************************* * Bitnet User Statistics * *************************************************************************** By Henry Nussbacher HANK@BARILVM 2 Sep 1987 11:24:49 1885 nodes polled 21565 active BITNET users are logged onto 987 connected nodes 19593 VM users on 459 nodes (Average: 42) 162 UNIX users on 38 nodes (Average: 4) 1810 VMS users on 490 nodes (Average: 3) Largest sites listed: Nodename Count Type -------- ----- ---- CERNVM 550 VM HNOESA10 390 VM SLACVM 329 VM NUSVM 311 VM UKACRL 287 VM ... HWALHW50 061 VMS FINUHA 045 VMS FINABO 039 VMS ... JHUNIX 043 UNIX UHNIX2 031 UNIX WISDOM 018 UNIX Now assuming that each VM site has 10 server machines (too few for CERNVM but way too many for sites like SFUVM and USUVM): 16975 total users 15003 VM users 162 Unix users 1810 VMS users 1 Page 8 - These numbers are biased to Europe since America is currently asleep. - 88% of all logged on users are VM users - The average is 3.7 users per VMS site - The average per VM site is 32 users So when we get right down to examining the numbers, the reasons why Bitnet is "dominated" by VM shops is obvious. Functionality is driven by user requests, and most users are on VM systems. ************************************************************************* * Best of the Big Flamage * *************************************************************************** (Pulled from FUTURE-L and other lists.) I don't see how XXXXX can seem so outraged that these files have been pulled out from under him when he quotes from an entry in the Bitnews file from 2 months ago. While I will admit that I do not like the idea of not being able to get to these files either (I'm not the TECHREP here), it WAS announced. Furthermore, the removal of BITONLY/NETNORTH/ EARN NAMES was announced last week, and was put into place at this time because of the constant pressure from the EARN people who insisted that they did not want their users to be able to get to these files. I will admit I feel that Bitnic has made a mistake on restricting MAILER and XMAILER NAMES. I do not personally see the need to restrict those two files, mostly because they are not very large, and I don't think people abuse their access to them. And maybe they should have announced the restriction again, and they did not mention these two files in the last mail they did send. However, I feel that they have erred on the side of cautiousness. Everyone complains that there is too much traffic, that users ask for files that tie up the network and they don't need, anyway. If anyone felt this strongly about the need for these files, why wasn't the discussion brought up in June, when the article was posted in Bitnews? I think one major improvement in BITNIC in the past few months has been the increased amount of information placed in the Bitnews files. If you're not reading it, then don't blame Bitnic. Personally, I do not like the fact that there is only one TECHREP per node. In the past, this only meant that you could not get mail for TECHREPs. Now, it means alot more. Rather than waste time flaming about this now, why don't we make this (and the restricted access of these files) a topic for discussion in Chicago, at the preShare meeting. *************************************************************************** Does the NIC really have too much to do? Or did EDUCOM sell the Board a bill of goods. From the little experience I have with EDUCOM the latter is 1 Page 9 true. They are a bunch of salespeople with no technical abilities. All they do from my experience is to negotiate volume discounts on PCs and terminals for schools too small to do it on their own. *************************************************************************** Yes, the NIC, before it shut down INFO@BITNIC was getting hundreds of requests from people, from 'Is Oshkosh U connected', 'I am looking for Prof Wombat a famous physicist. How can I find him?', 'My Mail program just broke and no one at this site knows how to fix it. Can you help?' Not to mention the hundreds of nodes and lists that were constantly sending in requests for changes or modifications. And then don't forget everyone and their grandmother who felt their idea was the right way to go and therefore "suggested" it to the NIC. When asked if they would have the time to codeup their idea that would take 1-2 months, most people said they don't have the time or commitment from management. And so it went. So yes, on one hand the NIC was very overloaded. And you are not entirely correct about them being salespeople. EDUCOM was started as a consortium to manage EDUNET (remember that one?). EDUNET was a logical network that used Telenet as its access medium. If you were on the east coast and needed some computer service on the west coast, then you went to Edunet. Here it is important to note that EDUCOM was not responsible for traffic management in Telenet or for writing access programs to Telenet. They merely "arranged" all the loose ends for you. When Bitnet got off the ground, EDUCOM was no where near it. When IBM came across with their multimillion dollar grant to set up a NIC, it was IBM that recommended EDUCOM. EDUCOM, of course, thought it was a great idea. I don't think they realized what it was to run a Network Information Center. *************************************************************************** Even if the restriction is a good thing, the way it was implemented showed a total insensitivity to those who might have automated processes. One does not substitite bad data for good data because it is assumed a human will look at the contents of a names file. This is another example of the manual mode mindset the nic seems to have. I have just converted my software to use the NETSERV support out of EARN. While not perfect, at least they understand about automation and table consistancy. *************************************************************************** As you can see we are approaching exactly what the problem is. The people in EARN who manage the network are also the ones who write the code (Burt Pasch, Udo Mayer, Peter Castor, Dominick Pinse, Stribilt, etc.). A network is not a static item. You can't expect a menu of 'network functions' to work for 2 years. That is why when something breaks, any of the above 1 Page 10 mentioned people can go into the 3000 line Rexx or Pascal program and fix it. The staff at Bitnic is not designed for that. *************************************************************************** And this gives them the right to do it? As long as they announce something, they can do it? *************************************************************************** With enough notice, even WISCVM can say they are shutting down and have the total right to do it if that is what they wish. *************************************************************************** Clearly, the level of service BITNET provides is a joke. The state of the net and the NIC are pathetic. The Board's concept of service seems to be non-existant. *************************************************************************** I suggest you start comparing NIC services (Csnet, Arpanet and Bitnet) and present a synposis to this forum in a week or two. While you are at it, compare manpower at each site and total operating budget. You might be suprised at your own results. And if that is all the Contract with BITNET calls for then the Board is also lacking in techinical competence which shows in their inability to contract for anything meaningful. *************************************************************************** They contracted for what they could receive in terms of their budget. With a larger budget, they could have contracted for more, but people said they didn't want to pay more. So they contracted for the bare minimum. *************************************************************************** If the reason for restricting files is to cut down on network traffic.... THEN QUIT SIGNING UP NEW MEMBERS you idiots! 100-200 new nodes per quarter for a network that can't handle the traffic it has is stupid. *************************************************************************** By adding more nodes, EDUCOM pulls in more money and hopefully next year the BoD will have enough of a budget to hire more technical people for BITNIC. A major problem is finding qualified people in the Princeton, NJ area. All of them are taken already by Princeton and JVCC. *************************************************************************** 1 Page 11 In fact those who are presently members should begin to complain about making BITNET a closed membership and start forcing people to pay for what they get now. Granted, the old addage, you get what you pay for is true. Nobody pays for BITNET so you get lousy service. *************************************************************************** People pay but just too little. So why not start a revolution to hike up sites membership cost to BITNET? *************************************************************************** The idea of starting ANOTHER network is absurd. Even if it was free like BITNET used to be (which is unlikely), the committment in time and resources required to connect and maintain gateways to other networks would prohibit most universities from joining. We have to live with BITNET and do whatever we can to improve it. I think you are wasting your time waiting for BITNIC/EDUCOM to provide any technical support. BITNET has always been and most likely will always be a "volunteer driven" network. We're just running on momentum right now. *************************************************************************** In many ways, I think that the problem with the NIC is not that they provide *bad* service, but they try to do too much. On their budget, they can't compete with SRI or the ARPA NIC. What do I propose to do about this? Ok, how about this -- let's concentrate on doing a FEW things correctly and completely and not worry about the frills for a while. The few things I consider important are: 1. Timely, ACCURATE node listings and updates. This is paramount in a RSCS-style network. We can't afford to spend time fixing boo-boos created because someone didn't have their mind on what they were doing or was working on another project. 2. Availablilty of informational documents such as RFC's, Bit News files, information, etc. on an AUTOMATED basis using the BEST tools possible. I don't care if it wasn't invented there -- if it's the right tool, use it. This business of not having peered lists OR allowing off-site owners for lists is just plain absurd. 3. Facilitating access to useful network tools in a STANDARD way. Eric Thomas' LISTSERV supplies all the functionality of BITSERV NICSERV, NETSERV, and most of the functions of DATABASE in a consistent, straightforward fashion. One thing to learn, and it's run at dozens of sites, and it *works* ALL the time. 1 Page 12 Things I think the NIC has NO business doing: 1. User Support. No way, no if's ands or buts. That's the job of individual sites or mailing lists for specialized topics like XMAILER or MAILBOOK. Finding individuals should be up to the individual user or the postmaster/designate/info-rep/whoever the hell is in charge of BITNET there, not the NIC. Connectivity questions and gateways to other networks are within the NIC responsibility under section 1, above, but no further. 2. Projects like GRAND or DATABASE. Research like that is better done by universities. GRAND is a failure - let's stop beating a dead horse. DATABASE....well, maybe. It's too complicated to really use remotely, it's slow, and LISTSERV provides everything except the indexing features, which could be remedied fairly quickly. 3. Software development. Better to commission people at other sites or accept volunteer services and programs than spend time on development. It's cheaper, and it doesn't detract from their primary mission which should be to coordinate the net. *************************************************************************** And I remind everyone that the only technical person at Bitnic is the person who maintains their machine and servers. THEY ARE NOT PAID TO BE A TECHNICAL SUPPORT CENTER. I believe that this is EXACTLY the problem that myself and others are complaining about. BITNIC is a bunch of sales people, not technical people. They are NOT paid to be technical. That single fact is the most significant difference between BITNIC, SRI-NIC and CSnet's CIC, including the budget differences and staffing differences, which go with the contract. I believe that the Board should have contracted with EDUCOM to provide a "Bitnet Sales Office" (BITSO). The Board acted like they wanted something for nothing. They couldn't (wouldn't) pay for a Technical operation, so they bought a non-technical operation and gave it a technical name, hoping no one would know the difference. (CSnet has the CIC - Coordination and Information Center.) I still think that the Board rendered an incompetent decision when they opted for a sales force instead of a technical support facility, budget restrictions or not. I believe that having NO BITNIC would be preferrable to the present "non-techinical" BITNIC. Take the money paid for BITNIC and provide contracts to Computing facilites on the net to support some particular piece of software or provide some particular server. 1 Page 13 Let's face it. Networks are not CHEAP, and they are getting more expensive, not less! High speed communications cost more than low speed. As I remarked once before on of these lists BITNET is suffering from its own success. It has too many new nodes WHO WANT TO USE THE NET. If you could get people to join, but not use the net, then you might have a chance. But BITNET is selling capacity and capabilities it doesn't have and can't provide. New nodes need hand holding until they figure out how to use the net and then they generate TRAFFIC because they CAN use the net! Remember the New York Phone Crisis of a few years back (mid 60's)? One of the prime causes was traffic increased beyond the capabilities of the physical plant to handle it. Data communications traffic was just becoming a reality. Ever wonder why 3 minutes is the standard billing unit? That was the average call duration for many years. Dial-up modems changed that radically! The "Great Society" put a lot of money into the ghettos in NYC and people bought phones with that money and USED THEM. Usage went through the roof and Bell had to put in massive amounts of new equipment and cable to handle the loads. ************************************************************************* * Commentary on WISCVM * *************************************************************************** (Pulled from LIAISON and other lists.) Based on evidence that I will not describe here, I think there are many, many private BITNET Internet gateways currently in operation. They are probably kept private due to fears about being swamped, and having to support it, and answer complaints. So, what to do? I would like to see all sites with private gateways go public at the same time. This effectively implements most of the "regional gateways" proposal that's been suggested a number of times. Since I somehow don't think this will happen (officially), then what? BITNIC should work hard on convincing DoD to let them run a gateway. For the millions of dollars a year that EduCom is getting from BITNET sites, they should work on this. Any site with both BITNET and Internet nodes should work on building their own gateway. *************************************************************************** I think that this entire discussion, while nice, should be dropped squarely in the lap of BITNIC. The necessary answers and decisions are of necessity, political. (Certain individuals at NSF have already advised sites against providing such a gateway for a variety of reasons.) Questions of Funding support, DoD approvals, and the like are clearly in the domain of the Executive Committee (or whatever its name is these days). EDUCOM as the action arm of the Executive Committee should provide "competent and authoratative guidance" to the Executive Committee. 1 Page 14 I think those of us who can view things from more than one network perspective must agreee - it's time for BITNIC and the Executive Committee to provide a reason to continue paying dues. *************************************************************************** I guess I don't see that BITNIC has much to do with this. They are simply hired by the BITNET corporation and its Board of Directors (eg. BOARD- L@BITNIC, see file BOARD87 MEMBERS on NICSERVE) to do a specific job. (Just as I assume the SRI-NIC is hired by DoD but BITNIC may not get a defense sized budget!). Therefore, if we feel it is important for BITNET to have public Internet gateways, then we should let the board know! Only they can set policy, budgets, etc. Only they can decide if the BITNIC machine has the capacity to handle a gateway, etc. Whether there should be several gateways, etc. Likewise, if the Internet people feel a gateway is important to them, they should be working with their administrations (eg. for ARPAnet, CSNET, etc.) to make sure it happens. *************************************************************************** BITNET is now faced with a sink or swim situation. BITNET must either come to grips with the need for a "professional solution" to the gateway mess, or face being isolated and ostricised as a joke - an example of how NOT to build a network. It's fine to sell a product to lots of people, but if you can't provide that product, they're going to demand their money back. And EDUCOM had best realize that their reputation is on the line as well. If BITNET fails, EDUCOM fails. You may think I am being overly dramatic. That we can patch things together for a while. That's true... for a while, as long as EDUCOM quits signing up new members. 100-200 sites per quarter!!! That has been the growth rate of BITNET in the past year! *************************************************************************** Again, it is US who decide that BITNIC should sign up members for BITNET by electing and talking to the Board of Directors. As I see it, the institutions which make up BITNET are like the stockholders here, and the OFFICIAL representatives of the institution convey their wishes to their board. *************************************************************************** BITNET must face up to the fact that there are other, more functional solutions out there for any non IBM site. UUNET is just getting started and will provide a much preferred solution for any UNIX(tm) site. You still 1 Page 15 have to pay, just as you do with BITNET, so the difference will be on service. Especially on the quality of that service. The artificial constraints posed upon networking by IBM Remote Job Entry Protocols are rediculous in this day and age. The speed and topology of the network are also rediculous. When the NSF is talking about linking facilities together at 56 to 1.5meg baud rates, 9600 baud is pathetic. *************************************************************************** There is no limit in the protocol to 9600 bps! That has been chosen because of costs and its general availability all over the country. Obviously the IBM RJE protocols are not meant to compete side-by-side with TCP/IP. The RJE protocols are for information movement --- there is not TELNET for example. But until recently, the RJE protocols offered a compromise between function, reliability and cost (eg. UUCP may be lower cost using dial-up demand asynchronous lines but the capacity is not as great). *************************************************************************** Now that IBM has entered the TCP/IP market place, maybe it is time for BITNET to become an INTERNET member. You will be able to buy your hardware and software from IBM and as a Federal contractor, IBM has a vested interest in making their TCP/IP products work. Again, this situation is clearly one of major proportions and is clearly up to the Executive Committee to ask for, adopt and implement solutions. I realize that August in Academia is just like in France - Nobody's home... but somebody better start making phone calls because there are only 120 days from Labor Day to December 31st. *************************************************************************** I agree that the situation is serious and it will take a lot of work to make a go of it. I agree that "real soon now" many more sites will have their own gateways between BITNET and the Internet. This is spurred on by more available and affordable TCP/IP interface hardware and software and the emergence of NSFNET and the regional networks. I have often felt that we should have more than one gateway! You have only to watch your adjacent node with the gateway (WISCVM) build up a queue of hundreds of files in a few hours because the link to CUNYVM is out to understand the heavy use on that gateway. However, I also feel there should be a small set of "official" or "default" gateways --- a reliable set run by sites dedicated to making them work which can be used. Actually, maybe one "default" which can be used for cases where the address must be hard coded in some way, then a few regional gateways (on various "spokes" of BITNET from CUNYVM) which could be coded 1 Page 16 into peoples MAILER software. Of course, this assumes the situation as it is. Domain naming and the implied smarter networks needed to handle network-independent names will mean changes in the future. And, more and more sites will probably be providing their own gateways for their outgoing mail. For this to work, we must "do things right" and be sure domains are properly registered, etc. (Eg. see the DOMAINS GUIDE). I am sure the board appreciates our comments. I hope they will stay 'tuned in' to the discussions and keep us posted about what options they see and what the plans are by posting to the appropriate official representatives of each institution in BITNET and the various public lists. *************************************************************************** *If* SRI grants access and *if* SRI allows a ".bitnet" domain and *if* someone buys a vax and *if* that vax supports name serving *then* the vax can direct SMTP mail to more than one WISCNET site on BITNET. Now, instead of having to handle all that mail, the vax only has to provide name service. The only houskeeping required: Someone has to keep up a "host name table". Certainly a manageable task. If we wanted to take this one step further, (flame-proof suit on) we could customize each MAILER MTPLATE to also know about the closest of the above mentioned WISCNET sites. Doing both of these would distribute that 5-10,000 message load among all the participating WISCNET sites. *************************************************************************** There is a committee of BITNET Board members who are charged with evaluating technical issues, and a LISTSERV list to help them define those issues in need of evaluation. Please send your ideas for an ARPAnet gateway to TECH-C for them to see. ************ ******** ** * ** * ************** * * * ************ * * * ** * * * * * * * *********** * * * * * * * * * * * * * * ************ * ******** * ************** * * * * * * * * * * * * ************** * * * * * * * * * * * * ************** * * * * * * * * * * * * * **************** ************** ******** ************** ************** 1 Page 17 ************************************************************************* * The Poetry Server: BIALIK@BRANDEIS * *************************************************************************** BIALIK is the first BITNET server dedicated to the subject of... poetry. The three commands that BIALIK accepts are POEM, INDEX, and HELP. These commands must be sent as interactive messages to the user BIALIK at node BRANDEIS; mail and files are not accepted. All commands and qualifiers may be abbreviated to three letters. ***** POEM (synonyms: GET, SENDME) Request a poem. POEM alone, or POEM/DAY, gets you the Poem of the Day; if there is no poem for today, you get a randomly-selected poem from the past. POEM/RANDOM gets you a randomly-selected poem. POEM gets you a specific poem. The number for each poem is an encoding of the date it was slated as Poem of the Day: for example, the command POEM 870520 gets you the poem from May 20, 1987. ***** INDEX (synonym: LIST) Request an index to all available poems. The index displays the number, author, title, and first line of every poem. The qualifiers /TITLES, /AUTHORS, /DATES, and /FIRST_LINES allow you to select how the index is sorted. The default is /AUTHORS. ***** HELP (synonym: INFO) Request a copy of the help file. ***** Other qualifiers All three commands can accept one further qualifier, which specifies how the requested file is to be sent. The options are /MAIL, /NETDATA, /PRINTER, /PUNCH, and /VMSDUMP. For the HELP and POEM commands the default is /MAIL; for the INDEX command the default is /PRINTER. The help and poem files contain no lines longer than 80 characters, but the lines in the index files are up to 130 characters long and will be wrapped around if sent using /MAIL or /PUNCH. Examples: POEM 870520/VMSDUMP POEM/PRINTER 870520 IND/FIR/NET 1 Page 18 Other: Chaim Nachman Bialik (1873-1934) is said to be the greatest Hebrew poet of modern times. Questions, comments, and suggestions may be sent by mail to username LAV at node BRANDEIS. ************************************************************************* * A New Name Server: WHOIS@UKCC * *************************************************************************** from Marc Rhorer IAF101@UKCC Most administrative people at University of Kentucky and many others are listed in the database of the name server WHOIS@UKCC. It has proven very useful for offices at UKCC and may be useful for others searching for a particular official's Userid. Valid commands are: HELP Sends a list of valid commands. FIND Locate the userid associated with a name, or vice-versa. For example: VM: TELL WHOIS AT UKCC FIND Marc A. Rhorer VMS: SEND WHOIS@UKCC FIND Marc A. Rhorer The response would arrive in a message format, like so: $906@UKPR Marc A. Rhorer - Office of International Affairs CCSMR@CCOL Marc A. Rhorer - Chancellor's Office IAF101@UKCC Marc A. Rhorer - International Affairs GUESS Locate the userid associated with a name, or vice versa, using your "best guess" of the spelling. For example: VM: TELL WHOIS AT UKCC GUESS Marc Rhorer VMS: SEND WHOIS@UKCC GUESS Marc Rhorer 1 Page 19 The response would arrive in a message format, like so: $906@UKPR Marc A. Rhorer - Office of International Affairs CCSMR@CCOL Marc A. Rhorer - Chancellor's Office (CCS) IAF101@UKCC Marc A. Rhorer - International Affairs (disc.) ANT346@UKCC Mary Lucas Powell (not on) SYSDATA@UKC Mary Ellis (disc.) UKA011@UKCC Mary Kelly (not on) MMARX@UKCC Marty Marx (not on) AEN008@UKAG Mark Fiedeldey AGR003@UKAG Mark Dahmer Note that both the FIND and GUESS commands inform you about the status of the user. For example, "disc." tells you a user is in a disconnect state, "not on" is self-explanatory. ************************************************************************* * Feedback * *************************************************************************** Date: Tue, 04 Aug 87 14:15 EST From: SEWALL@UCONNVM Subject: NetMonth To: BITLIB@YALEVM Re: your "Day in Bitnet: The Game" Boy! have I discovered why "you have to figure out how to send mail to UUCP" is a -15 bummer. Getting to UUCP is easy, there are many doors (PSUVAX1, harvard.arpa, seismo.CSS.GOV, ucbvax.berkley.edu, uxc.cso.uiuc.edu, goodness knows what else). The real trick is finding a UUCP mailer that knows the path to the addressee you want to reach. Even some paths offered up by the interactive server at PSUVAX1 return: "Host Unknown" from that very site! No doubt there are sound reasons for modifying host tables. If you lookup how to address mail to dec.com in GATEWAYS HELPNET, it says: user%domain.DEC gets translated to user%node.DEC@DECWRL.ARPA, and indeed it does. The problem is SMTP at WISCVM then sends it back to you with "DECWRL.ARPA Host Unknown" AND it's right! The lastest arpa host tables have no decwrl. (and today's answer is: user%node.DEC@DECWRL.DEC.COM) ********** ************ ***** ********* ********* * ********** * * * * ********** * * * * ******** * * * * * *************************************************************************** 1 Page 20 Date: 08/05/87 18.01.24 GMT+1 From: To: Subject: The Death of Simtel20 Michael Dahlinger 0049-6151-16-3016 Institut fuer Kernphysik Schlossgartenstr.9 D-6100 Darmstadt Germany I just read in Netmonth.jul87 (which I liked very much) why my requests to ARCHIVE-REQUEST@SIMTEL20 are no longer responded. It just disappeared!! For me this is a great pity, because I used it as a source for public domain software for our PC's at the institute often. What now?? The software stored under PC-BLUE etc. is too useful to disappear just like this. I would like very, very much to have access (perhaps via a LISTSERV) also in the future. So I would like to encourage you to find a solution soon. *************************************************************************** Date: Thu, 6-AUG-1987 12:30 EST From: Kevin Cole Subject: NetMonth printing for VAX To: BITLIB@YALEVM Why re-invent the wheel? I suspect most VAX sites receiving NetMonth of running JNET software. This means that if NetMonth is sent out to those sites as a PRINT file, all the user has to do when (s)he receives it is add the qualifier /FORTRAN. The following example illustrates: $ RECE Files to be received for KJCOLE Filename From Node Records NETMONTH.1987JUL;1 BITLIB YALEVM 1234 BITNET.SERVERS;1 BITLIB YALEVM 4321 RECEIVE> REC NETMONTH.1987/FORTRAN However, Ed McGuire of Grinnel College points out that this only works if 1 Page 21 the file is type PRINT: "If it shows up type PUNCH (as these things often do) you can't RECEIVE/FORTRAN. I don't know whether to point my finger at the source of the file and say `nyah nyah, punch cards don't have carriage control' or at Jnet and say `this is an imperfect world, let me do it anyway.'" Last but not least, the method I use is a utility distributed on the network called FILE. FILE allows a user to set any attribute of a file to anything he or she wants. If your site has it, you just say: $ FILE/ATTRIBUTE=(FORTRAN,NOIMPLIED) NETMONTH.1987JUL and it's done. Hope this is useful to someone out there. Note from the Editor: This was just one of many helpful suggestions for converting NetMonth files in order to print them from VAXen. *************************************************************************** Date: 6 August 1987, 11:53:25 EDT From: Bruce ZZTong To: Chris Condon Congratulations on a year well done. Looking forward to the next action packed volume. Netmonth has proved itself as a priceless tool for increasing network awareness at this node, and undoubtably at nodes all across Bitnet. Keep up the good work. *************************************************************************** Date: Tue, 18 Aug 87 14:02:16 +0200 From: Alain FONTAINE (Postmaster - NAD)" Subject: LNAME... To: "The glorious Netmonth editorial board." Hello. Thank you for including information about LNAME in the july issue of Netmonth (received today - would it be possible to have it *printed* at yale and sent by *surface* mail to Belgium? maybe it would be faster :-)). I should have sent some words of introduction, because the help file alone looks quite hermetic. Well, I did not realize that you were going to include it entirely... Here is an attempt at such a short introduction. Maybe it would be wise to include it in a forthcoming issue. 1 Page 22 Why would you like to get the LNAME utility? -------------------------------------------- The help file for LNAME has been published in the July issue of Netmonth. Such reference information, invaluable when one does have and use some product, tends to be somewhat hermetic to the newcomer. So you will find here a little introduction. Compared to the leading brand, LNAME removes one big restriction and brings quite a few improvements. If you communicate with people (or servers) outside BITNET/EARN/NETNORTH, you need to use network addresses (userid and node, the latter beeing often replaced by a 'domain') whose parts are longer than eigth characters, and may include lower case letters. The standard command NAMES does not allow you to do that; that's the big restriction removed in LNAME. The improvements can be found in detail by studying the help file. To summarize, I would say that the biggest improvement is that the layout of the screen is user definable (using screen definition files - you may have lots of them). Since the name of the file to be viewed/edited may be specified when calling LNAME, you may use it as tool to manage any kind of small databases amenable to the 'NAMES' format. Other improvements include the possibility to define a multipage display for a single entry, the production of compacted files, a powerfull 'SEARCH' command, and more... The thing is fully maintained, and available from me. I don't put it on a server, since it is regularly updated, and I don't want to receive comments and complaints based on older versions. The acknowledgement section: LNAME is an offspring of the NAME utility, available from NYSHARE at WEIZMANN. The original idea of a definable screen is theirs. ************************************************************************* * NetMonth Policies * *************************************************************************** * Subscribing to NetMonth and BITNET SERVERS: VM users can be added to the mailing list by issuing the following command: TELL LISTSERV AT MARIST SUBSCRIBE NETMONTH Your_full_name 1 Page 23 VAX/VMS users can subscribe in a similar way: SEND LISTSERV@MARIST SUBSCRIBE NETMONTH Your_full_name If you cannot send messages in this way, you can send the following command as the first line of a mail file to LISTSERV@MARIST: SUBSCRIBE NETMONTH Your_full_name Arpanet users may use this method, but must address the mail to: LISTSERV%MARIST.BITNET@WISCVM.WISC.EDU A subscriber can delete him/herself from the mailing list by sending LISTSERV@MARIST the UNSUBSCRIBE NETMONTH command. * Letters to the Editor: If you have questions or comments about BITNET or NetMonth that you would like printed here, mail your l etter 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. This doesn't mean that your letter will be printed, but it helps. * Article Submissions: The only requirements for NetMonth articles are that they be informative, interesting, and deal with BITNET services (or any other good BITNET related topics). The editor will inform you of any changes to your writing and will submit them for your approval, deadlines permitting. Send your articles to BITLIB@YALEVM. * Printing this file: VM users can print this file by first copying it to NETMONTH LISTING and then printing the new file. This will allow page- breaks and other formatting to be understood by your printer. --------------------------------------------------------------------------- A publication of the Bitnet Services Library "Because We're Here."