* * * * * ** * ** ** * * * * * * * * * * * * * * * ***** ******* * * * ***** ****** ******* ****** * * * * * * * * * * * * * * * * * * ******* * * * * * * * * * * * ** * * * * * * * * * * * * * ****** * * * ***** * * * * * * * * The guide to BITNET servers and services * * * * Volume 2 Number 5 November 1987 * * * ***************************************************************** * * * Editor: Chris Condon CONDON@YALEVM * * NetMonth Staff Supervisor: Gary Moss MOSS@YALEVM * * * ***************************************************************** * * * It was the spring of 1981. In Manhattan and New Haven a pair * * of modems were brought to life, and data began to flow over a * * leased telephone circuit between the computing centers of the * * City University of New York and Yale University. A bold * * experiment had begun that over the next several years would * * grow link by link into a worldwide network of academic * * computers. BITNET started with only a single wire, but with * * the inspired vision of a global community of scholars, * * sharing research, ideas, and information. Few at t he time * * believed that such a network, based on cooperation among * * academic institutions, would ever succeed. At least two * * individuals believed that it would. Ira H. Fuchs, then vice * * chancellor for University systems at CUNY, had seen a network * * within the IBM Corporation grow worldwide, interconnecting * * not only programmers but researchers and managers. This * * network, called VNET, spread among IBM sites using standard * * IBM software and leased telephone lines, with each new link * * responsible for its connection to the network. Together, * * Fuchs and Greydon Freeman, then director of the Yale Computer * * Center, saw in this model enormous potential for * * communications among institutions of higher education: * * administrators, faculty, and even students could use such a * * network to share information. Fuchs and Freeman envsioned * * more than CUNY and Yale sharing computer data. Nothing in * * the network software restricted the communications to * * computer programs. Increasingly, universities were beginning * * to view the computer as a tool for for processing information * * and text as well as number crunching... * * * ***************************************************************** * * * From "BITNET: Past, Present, and Future" * * by Daniel J. Oberst and Sheldon B. Smith * * * ***************************************************************** 1 ************************************************************************* * Contents * *************************************************************************** Bitnotes ................................................................ 1 Scuttlebut .............................................................. 2 FEATURES___________________________________________________________________ Internet-BITNET Gateways ................................................ 4 Relay, Bitnic, and Christmas ............................................ 8 Finding People in Other Networks ....................................... 12 SERVERS AND SERVICES_______________________________________________________ A New Name Server: LOOKUP@RITVM ........................................ 13 New Mailing Lists ...................................................... 14 DEPARTMENTS________________________________________________________________ Feedback ............................................................... 17 Policies ............................................................... 18 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 BITNETs 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@YALEVM. 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 16 * *************************************************************************** * And now for something completely different... ...and more of the same. There is little need for me to repeat what I have mentioned too many times before. BITNET is changing and growing day by day, and yet it remains recognizable. More important, your needs have changed and grown with the network. NetMonth should reflect those changes. NetMonth began as a weekly list of servers and services known as Bitlist. The need for more in-depth information on this subject became apparent, and the current magazine came into being: "The monthly guide to BITNET servers and services." That caption was a guideline for what should be included in each issue. Now, I offer you a new caption for a new NetMonth: "The independent guide to BITNET" How will this new NetMonth differ from the old? This changed magazine will include information on all issues of relevance to the network, be it news about servers and services, tips for using the network more effectively, or editorials by the network users. Here are some of the new features I'd like to include: 1. A "Question and Answer" section. I may not know the answer, but I'll find someone who does! 2. An "Editorial Page" featuring regular and irregular columnists from different areas of the network, both physical and virtual. 3. A monthly spotlight on a network outside of BITNET with instructions for how to send mail to people there. In order to achieve all this there is a catch: We will need your contributions more than ever. We will need questions for the Question and Answer section. We will need writers for the Editorial Page. Yes, let's make it official: WANTED: Bright people with any range of BITNET experience needed to write monthly columns about any network-related topic. Applicants should posess at least passable writing skills. Editorials do not have to be long ( 1 to 3 pages) and may be serious, humorous, or anything in between. People who are unable to contribute regularly are welcome to submit anything they can, whenever they are able. There is no pay, but visibility is high. 1 Page 2 Now, I know that you are busy people. However, if I can find the spare time to put together the magazine, couldn't you find a little to write something? Many of you have a wealth of information and understanding about the technical aspects of the network that I do not yet understand. All of you have a different insight, and contrasting opinions. This is one of the things that makes BITNET an interesting place environment in which to work and play; I want to reflect that in NetMonth. Also, a question: What would your reaction be to a NetMonth published on paper and delivered by your postman? I am, of course, speaking of a desktop-published newsletter with attractive fonts and graphics. Would a format like that make you more or less likely to contribute? Next month: A new format, a new design, a new NetMonth... ************************************************************************* * Scuttlebut * *************************************************************************** * Relay at TCSVM shut down: Wendel Bordelon and John Voigt of TCSVM issued the following statement: "Well - it has finally happened. We have shut RELAY down. Reason: Load on our system. Last night We were getting better response from the RELAY at Aggieland than the one here. There were over 140 users on 57 channels. Many of the private channels had only 1 user signed on. "Recommendation: Limit number of public channels to 10. Limit number of users per channel to 6. Eliminate /m command. If you want to send a private message don't use RELAY to do it. It doesn't save any network bandwidth and just causes extra overhead in RELAY. Limit number of private channels. Allow the same number range (or use names(make Phil happy)) but limit how many can be created. Kick off users on a private channel by themselves at the next clock tick check. "If RELAY at TCSVM is to come back we have to make RELAY something that is worthwhile and useable. No one should have to live with the kind of response time that RELAY provides when that many users are on. I find it very hard to hold a conversation with 19 other users. That's how many were on channel 1 last night. This has got to be corrected." * BITNET-Internet Gateways announced (from Bitnews): The City University of New York, Princeton University, Cornell University, and Massachusetts Institute of Technology have each committed to provide gateway service for electronic mail between the BITNET network and the Internet. 1 Page 3 Current gateway services provided by the University of Wisconsin (WISCVM) will end on December 15, 1987. Prior to that date, at least two of the above announced gateways will be in operation in parallel with WISCVM - there will be no interruption in gateway services. Prior to a regionalization plan and significant coordination with the Internet, the most expeditious approach is to name the first few gateways the same, namely, INTERBIT. That would mean that any gateway-destined mail that landed at any INTERBIT node would be appropriately handled. This change will be reflected in the December DOMAIN NAMES file which is used for MAILER generation; users need not do anything - mail will go automatically to the closest gateway. This is a transition measure necessitated by the time frame, by the complexity of more desirable solutions, and by the need to coordinate more with the Internet. Plans are to regionalize gateway service between the networks in order to balance traffic flow and increase reliability. Several other institutions are seriously considering functioning as gateways. An analysis of topologically best locations for such gateways will be conducted under the auspices of the BITNET Board of Trustees' Technical Committee; and the BITNET Network Information Center will coordinate regionalization plans and associated software modifications. See also in this issue: BITNET-Internet Gateways. (Please note reference to Internet, rather than ARPANet, and Internet's inclusion of ARPANet, NSFNet, NYSERNET and the other regional networks.) * A warning from Malcolm Dickinson: There is a self-propagating "virus" exec that has recently been released by a grumpy scrooge onto BITNET. It is called "CHRISTMA EXEC". This virus is a sneaky one. You may find it in your reader, sent to you by a friend of yours in BITNET. If you load it from your reader and then type CHRISTMAS, it will draw a little christmas tree on your screen, then SEND A COPY OF ITSELF TO EVERY USERID IN YOUR * NAMES fille. This may not seem to be so malicious, until one considers the amount of file traffic such an exec can create. If you have 20 people in your NAMES file, and 15 of them run the exec that gets sent to them, and each of them has 20 people in their NAMES file, the resulting file traffic on the network will be 320 file transfers. In the next generation it will be 6400 files, and in the next generation, 128,000 files. If the exec is spread thoroughly without a concerted effort to stop it, a few million copies will be flying around the net within a week, slowing file traffic immeasurably and costing thousands of dollars in CPU time. 1 Page 4 ************************************************************************* * Internet-BITNET Gateways * *************************************************************************** By Henry Nussbacher and Douglas Bigelow from Bitnews Much progress has been made in BITNET toward establishing a robust interconnection with the Internet. The following is a report on the current gateway situation. Hopefully it will provide a stimulus and focus for further short-term and long-term developments. Douglas Bigelow Chair, BITNET Board of Trustees Technical Committee The removal of the University of Wisconsin BITNET-ARPAnet gateway (WISCVM) on December 15th, 1987 has caused a reanalysis of the entire gateway situation in BITNET. The Internet (ARPAnet, CSnet, NSFnet, etc.) presents a unique problem of interconnection, due to its size. A single gateway, albeit a simple and easy to implement solution, presents problems of large backlogs and network congestion, both to the Internet and to BITNET. This was proven very clearly with the Wisconsin gateway. This paper will detail the "regional gateway" proposal, the pros and cons of this interim solution and what steps need to be taken in the future. I. THE BITNET SOLUTION: The regional gateway solution states that every node is to use the Internet gateway closest to them. The gateway id of SMTP@INTERBIT has been decided upon as the universal gateway id that all BITNET nodes will need to know about. The steps required to implementing "SMTP@INTERBIT" have been: a) register the node INTERBIT in EARN, BITNET, and NETNORTH as being connected to node CUNYVM. This has been done. As of December 1st 1987, most nodes have updated their tables and therefore know of the existence of a node named INTERNET. b) alter the DOMAIN NAMES file (the file that many sites use to customize their mailer support to handle domain type names) to have all Internet traffic sent to SMTP@INTERBIT (originally was SMTP@WISCVM). This will be released to the public on the week of December 5th. c) have more nodes create pseudo nodes called INTERBIT. The sites that have agreed (so far) to act as regional gateways are: City University of New York, MIT, Princeton University and Cornell University. (These were the intiial four; other serious offers and inquires continue to come into 1 Page 5 the BITNIC.) This will be an ongoing process which will constantly contribute to the equal distribution of Internet traffic among all gateways. As more gateways connect, the load on CUNY and the other three initial regional gateways should be reduced. It is expected that within one year there will be in excess of 20 regional gateways. d) alter the route table generation programs (in EARN and BITNET) so that more nodes make use of end-of-path regional gateways. An example would be MIT, which has many high volume neighbors, all of which will be initially pointing to CUNY (which is much further away). II. POTENTIAL PROBLEMS: 1) JES2: The JES2 Path Manager attempts to route files to any INTERBIT node it may know of. If one is down or not available, then the JES2 Path Manager has no qualms about routing the data to any other known INTERBIT site. This can cause network loops. The solution to this is to define only the CUNYVM-INTERBIT connection to all JES2 sites and not to elaborate the alternate connections. 2) Loops: Each site receives a customized route table from BITNET's Chris Thomas or EARN's NETSERV GENROUTS. Initially, they will all have INTERBIT being a node connected to CUNYVM. But as more and more INTERBITs become available, a need for customizing the route tables becomes more urgent. Imagine the following topology: X-A-B-C-D-E When " X" represents an INTERBIT node, then all nodes (A-E) have their route tables pointing to A as being the final link before INTERBIT. But if the following were to occur: X-A-B-C-D-E-X then it would be foolish for nodes D and E to route their Internet files to A; but rather they should route their data to E. In addition, node C decides that it wishes to route its Internet traffic to E. That too is also valid. But if for some reason node D changes its routing from E to A, then there will be a loop between C and D. It is imperative then, that all nodes be warned that they are not to tamper with the routing of INTERBIT in their customized route tables. If a node has complaints about an INTERBIT site (rejects valid BSMTP mail, garbles headers, is always down for maintenance, etc.) and these complaints are justified, then the INTERBIT gateway in question will be removed from the routing tables and all neighboring sites will be assigned to another regional gateway. But under no condition should a site decide on its own about where to route INTERBIT traffic. 1 Page 6 Advanced nodes that need to alter their routing can change the DOMAIN NAMES file to point away from SMTP@INTERBIT to some other regional gateway "true userid" - like SMTP@CUNYVM, and in that way bypass the RSCS looping problem. In general, the rule should be: NEVER ALTER RSCS ROUTES BUT YOU CAN ALTER DOMAIN NAMES III. PROPOSED ALTERNATE SOLUTIONS: Customized DOMAIN NAMES: This solution would work if every node used a mailer and the DOMAIN NAMES file. Unfortunately, there are many sites out in BITNET, who have only the time to update their RSCS route tables and do not wish to be bothered with another set of tables to be updated - namely mailer tables. These sites will just latch on to the most common gateway available to replace WISCVM, which in all probability will be CUNYVM. This will put a large strain on CUNYVM - one that it is not prepared to handle. Even if these sites could be convinced to route their Internet traffic to some site other than CUNY, we run into the problem two years from now, when there will be 50 or even 100 regional gateways and these "small" sites will still be pointing to one of the 4 original regional gateways. The method described in the Solution section, solves this problem of the "lazy" node. IV. THE INTERNET SOLUTION: Now that we understand what needs to be accomplished from the BITNET side, we need to also analyze what needs to be done from the Internet side of the network. Mail originating in BITNET, that is sent into the Internet, will have the RFC822 headers altered by the gateway to indicate which gateway has processed the mail. Therefore, the user in the Internet will have a valid header which will point back to the BITNET regional gateway and from there to the destination user. Example: user%TUCC.BITNET@VM.PRINCETON.EDU The more major problem comes about when a user in the Internet wishes to originate mail to a BITNET user. Here, once again, there are multiple solutions: 1) On your own: Each site or each user will have to decide on his/her own which regional gateway to use. They might just hardcode a known regional gateway into their mail software and from then on, all traffic from that Internet node will flow via that stated node. This is not an optimal solution but it is one that works. TCP/IP does not have the problem with network loops that RSCS has, so users user can decide on their own which gateway is best for them. 1 Page 7 2) Create a BIT.NET domain: This is similar in concept to the INTERBIT generic nodename. The user in the Internet would type in a user address like: user@GWUVM.BIT.NET or user%VAX.OX.AC.UK@BIT.NET and the Internet software would determine which gateway is closest via MX records. This approach has had a mixed response from the ARPAnet. However, most network people seem to agree that the following solution (3) is the one toward which we should all work. 3) Register all BITNET domains in the Internet: This should actually be viewed as a long term solution for the merging of BITNET and the Internet. The problem with this is that every institution that wishes to be registered in the Internet, needs to have i ts own "house" in order. That means that each institution needs complete domain support covering ALL nodes at that institution. If a few nodes at the institution are not supported via domains locally or if there are two or three seperate Ethernets that do not communicate one to the other, then the registration of a domain type name in the Internet will not solve these problems but rather compound them. Once all sites are registered with SRI, then mail flowing from the Internet can determine how to send it via the domain name server. If the site has a direct connection to the Internet, then the data will flow through the Internet until it reaches the correct gateway. If the site does not have a connection to the Internet, then the data will be pointed to one of the numerous regional gateways which will move the file over to BITNET and from there the file will be delivered via Mailer or BSMTP. For this solution to be most effective, all BITNET institutions should support domain-style names for all their nodes. The RSCS nodename will become the equivalent of an IP address, and the dotted domain address will be transparent whether it originated in NSFnet, ARPAnet or BITNET. Henry Nussbacher _______-----___--______________________________________ ____------------------_________________________________ _-----__-----------------______________________________ ---____----__---_----_-----____________=======_________ -_____---___----_----___----________=============______ ______-____----____--_____---______===============_____ _________----________-_______-_____===============_____ _______----_________________________=============______ ______----_____________________________=======_________ ____----_______________________________________________ __-----________________________________________________ 1 Page 8 ************************************************************************* * Relay, Bitnic, and Christmas * *************************************************************************** from the RELAY-L list Date: Tue, 01 Dec 87 12:11:49 EST From: Valdis Kletnieks Dear fellow Relay Operators: Due to recent events, I find it in the network's best interests to (at least temporarily) shut down RELAY@CLVM (the Twilite_Zne). It is not a decision that is coming easily to me. The basic problems are as follows: (1) When I posted my note about file queues last night, the file backlog was not high. By the time Gary Moss got it, the queue at YaleVM was 450. As of noon EST today, it is 680 and climbing. (update: It is now 12:30EST and 760 files are queued). This is reportedly due to a gateway at MIT. Why it is doing it, and what is being done, I have not the slightlest clue. (2) Relay@BITNIC has been quiesced for 3 days. The Relay-L list was NOT told why. This is about par for the course. Those who have been on this list for a long time have seen me repeatedly flame about this point. (How long does it TAKE to send a note that says: "We've got a rogue gateway, we're loaded with files, we're shutting down till it's fixed.."?) (3) I have been hit with a sudden rash of weenies, a good number of whom should know better. The people involved know who they are... I won't comment any more on this point. (4) The end of the semester is coming. We will be beseiged by a CPU crunch. This is an immutable fact. I cannot justify the CPU resources for RELAY if the only place I can reliably link to is YaleVM, and when our CPU is loaded, and when the network is so overloaded, and the information (mostly idle chatting) is not of an urgent nature. When push comes to shove, something must give. RELAY is currently one of the lower-priority Bitnet services. Zone is NOT being shut down because of a CPU problem. Although we DO have a slight problem with cycles, management is willing to overlook RELAY's CPU use during the off-prime time if it is not TOO outrageous. The reason I pulled RELAY was because I see it as NOT worth the effort if all it will talk to is the Yale relay. 1 Page 9 It will be restored to service as soon as it is feasible to have it connected to the rest of the Relay network. Unfortunately, I do not see it as surfacing before the end of next week, given the current speed that problems are being resolved. Also, I am still debating if I will ever resurrect it unless the problems I have with the Bitnic relay are resolved. I cannot in good faith rely on a relay that is (apparently) arbitrarily quiesced without warning or explanation. Admittedly, it DOES have to be shut down if there is a large queue in a place that it makes a difference. However: It *should not* shut down for files coming TO cunyvm from yalevm - it should still come up and connect Europe and the rest of the US. Shutting down to offload the link is Yale's problem in this case. Gary Moss was nice enough to send a note saying what was done and why. It *should* be announced why, and on what link the problem is on. It *should* be woken up in a timely fashion after the queue is cleared. If the staff at Bitnic cannot see fit to logon at 9PM and check if it should be woken up, they should assign a few trusted masterops class 4 privs. Then they can post a note saying "689 files queued for Zanzibar. Wait till it's under 35 before waking it up". The other possibility is that relay at bitnic either be removed and linked around, or have some other topology change. To re-iterate: My problem is not a CPU problem, it's more a problem with the way the net is managed. Amazingly enough, I still have enough management support for RELAY that it will not be going away. If at some time in the future, the network improves, I will bring RELAY back online. (End factual discussion, begin political commentary....) When it first started out, BitNet looked like a great idea. Yesterday was the third anniversary of CLVM connecting to Bitnet. We were 'node number 421' according to BITEARN NODES. It is now 3 years later. 1700 more nodes have joined on. This has provided an unprecedented ability to intercommunicate between colleges and universities. However, some things have not kept up. We now have internodal war about 'Bitnic vs EARN tools'. A failing link can cut off a lot more nodes than it used to. Gateways are folding under the load. 1 Page 10 Crucial links are running further and further behind. I see 5 times the nodes connected. I do not see 5 times the infrastructure (redundant and higher capacity links, support personell, network information services, network leadership). Bitnet is in a state of chaos not unlike Rome of 300AD. The empire is falling, but the barbarians are not pounding on the door - yet. Date: Fri, 04 Dec 87 11:03:01 EST From: Craig Barefield In reply to Valdis's last mail message regarding his shutting down his Relay, I agree with him 1000% to every point he is making. I too am faced with a similar situation, and am considering shutting down NYU's Relay. The only difference is that we connect directly to Bitnic thus when they are quiesced, we are an isolated Relay. I am also at the point where I can no longer tell the Systems programmers at our lower level links (vaxes, etc.) not to write their own chat machines. Once that happens, they will in effect be running PUBLIC relay- like machines open to message traffic from ANY NODE and I WON'T be able to stop them from doing it. I'm sure that will wreak havoc on the network as well as my machine. Then maybe someone will take notice of what's going on. Then on the other hand, I think it was mentioned before that nobody from Cunyvm or Bitnic is on the Relay-L list. Was that true? Maybe nobody will notice, maybe nobody will care. Date: Mon, 7 Dec 87 20:40 EST From: John McMahon With the advent of Relay@Bitnic going into a permanent (?) state of comatose, and the complete lack of response from anyone who has anything to do with the control of it, perhaps we should take some sort of action. Let's link around Bitnic. (Ack... Blasphemy) What I am proposing is a test re-link around Bitnic. My reasons are the following: a) The file queues at/around Bitnic are nonexistant. I realize Yale still has a bunch of files sitting there, but they are handling that problem by remaining unlinked. b) Relay at Bitnic has not come up in several weeks as far as I can tell. c) Noone at Bitnic seems to remember that they have a relay. 1 Page 11 I realize Bitnic's importance, and that they often have held life-and-death over Relay. But, are they keeping up their end of the bargain ? Would we expect the same kind of treatment from the operators at Urbana ? or Aggieland ? or TwiliteZne ? Date: Tue, 08 Dec 87 12:36:28 EST From: Peter A. Klein I understand the situation that you are in, However, I have a few simple questions for you since you have been brave enough to step forward. o Is it still the policy of BITNIC not to allow users from other nodes than BITNIC and CUNYVM to have privs on service machines at BITNIC? o Since no one at BITNIC seems to want to spend the time to look after the relay there, can someone off node look after it? I think that most people on this list would agree that we don't expect the people AT Bitnic to run their relay on a day to day basis but we do expect them to be responsible enough to make sure it is logged on and that someone else can monitor it and make the appropriate quiesces and wake ups. Hence, I would like to make the following proposal. 1) Make Jeff Kell the contact for the BITNIC relay (if you are up to it Jeff) since he is the person who will live or die if relay screws up. 2) Give several currently trusted master ops class 8 privs at BITNIC and give several regular ops class 4 privs. The idea behind the class 8 privs is to allow responsible parties to change the relay's basic operating parameters when things like file queues, etc... come about. The reason for class 4 privs is to allow less trusted operators to also watch after the BITNIC relay. It is my suggestion that two people from each major link off of BITNIC be given these privs to allow for link failures and the like. Finally, these ops should be chosen by Jeff since again he is the person who will live or die if relay screws up. I hope this proposal or something like it is implimented soon. __________________________________________ / /[ /__________________________________________[/ ] ] ___________________________________ ] ] ] /[ ] ] ]_______________________________[/ ] ] / ] ]/__________________________________ ] /[ ]__________________________________________[/ 1 Page 12 ************************************************************************* * Finding People in BITNET * *************************************************************************** People ask me questions. Scattered within the electronic junk mail I will find pleas for help, information, and assistance. However, the questions are not what you would expect. There are no questions about why the Relay is the quiesced today, or how to use a particular server, or how to send someone a file. No, nothing as mundane or commonplace as that. The Earth- shattering question of our times? "How can I find out the userid of X at University of Y?" Here then, are a number of ways to find the answer on your own: 1. Does the node have a local name server? Not many do, but if so, your search for information should end here. BITNET SERVERS contains a list of name servers, and BITNET USERHELP contains an explanation of how to access them. 2. Check the larger name servers: Some name servers, such as NETSERV or CSNEWS allow people from all over the network to register themselves. You may find the person you are looking for listed here. I make it a point to check the CSNEWS Bitnauts List; it seems to be one of the more popular places for people to register themselves. If I were searching for John Doe at YALEVM, I would send CSNEWS the following commands: VM/CMS: TELL CSNEWS AT MAINE BIT SEARCH Doe TELL CSNEWS AT MAINE BIT SEARCH YALEVM VMS/JNET: SEND CSNEWS@MAINE BIT SEARCH Doe SEND CSNEWS@MAINE BIT SEARCH YALEVM This way I will receive two lists: One with all the people in the Bitnauts list with the name "Doe" (or with "Doe" as a portion of their name or list of interests) and another lists with the people from YALEVM. The person you are looking for might be listed there. At this point there is a strong temptation to contact someone on the list you just received and ask them if they know your friend John Doe. Well, there are MANY people at each node, and the chances of someone you randomly contact knowing Mr. Doe are quite slim. The only thing this strategy will accomplish is annoying somebody. This is NOT proper network behavior. 3. Reach out and touch someone. If you know the phone number of the person you want to contact, it may be simpler to call them and ask "What is your userid@node?" This costs you some money, but saves you some time. 1 Page 13 ************************************************************************* * The Name server LOOKUP@RITVM * *************************************************************************** LOOKUP@RITVM is a name server at Rochester Institute of Technology. You should send commands to the server via interactive message. For example: VM/CMS: TELL LOOKUP AT RITVM /HELP VAX/VMS: SEND LOOKUP@RITVM /HELP There are few actual commands for this name server. The text of your message is the search string, although you may add certain qualifiers. The default is to search for a particular userid. For example: TELL LOOKUP AT RITVM POSTMAST will return information on the userid POSTMAST: * POSTMAST Jenny Beaven Staff 752 ISC - Technical Support If you are looking for a specific last name, add the /NAME qualifier: TELL LOOKUP AT RITVM BEAVEN/NAME will return all entries with the last name of Beaven: * JMBSYS Jenny Beaven Staff 752 ISC - Technical Support * JMBTST J. M. Beaven Staff 752 ISC - Technical Support * JMB1989 Jenny Beaven Staff 752 ISC - Technical Support * POSTMAST Jenny Beaven Staff 752 ISC - Technical Support The /FNAME qualifier work much the same way: TELL LOOKUP AT RITVM JENNY/FNAME will return all entries with a first name of Jenny: * JMBSYS Jenny Beaven Staff 752 ISC - Technical Support * JMB1989 Jenny Beaven Staff 752 ISC - Technical Support * POSTMAST Jenny Beaven Staff 752 ISC - Technical Support The commands /HELP and ? will return a list of commands. + ] + *-[[]//-* > +--+--+ < *-//][[-* + ] + 1 Page 14 ************************************************************************* * New Mailing Lists * *************************************************************************** 386USERS@UDEL.EDU A moderated list for Intel 80386 topics, including hardware and software questions, reviews, rumors, etc. Open to owners, users, prospective users, and the merely curious. You can request the archives be sent via mail by sending a note to 386USERS-REQUEST. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to 386USERS-REQUEST@UDEL.EDU. List Maintainer: James Galvin List Moderator: Bill Davidsen BIG-LAN@SUVM Mailing list for discussion of issues in designing and operating Campus- Size Local Area Networks, especially complex ones utilizing multiple technologies and supporting multiple protocols. Topics include repeaters, bridges, routers and gateways; how to incorporate smaller Personal-Computer type LANs into the campus-wide LAN; how to unify the mail systems, etc. This is an ideal list in which to debate the relative merits of bridges vs. routers. Archives are available through revised LISTSERV. To subscribe, send the following command to LISTSERV@SUVM via message or as the first line of a mail file: SUBSCRIBE BIG-REQ Your_full_name Coordinator: John Wobus FINEART List for dissemination of information on the use of computers in the Fine Arts. Topics to be included are: Computers used in the design of works of art Computers used to fabricate works of art Computers used within works of art Computers used to analyse works of art 1 Page 15 General areas of interest include: Computer Animation Computer Aided Fabrication Shape Grammars Design Rule Systems Style Simulation Image Synthesis Image Rendering Interactive Video Sensory Environments All requests to be added to or deleted from this list, or to have files distributed, should be sent to the Coordinator. Coordinator: Ray Lauzzana GayNet@ATHENA.MIT.EDU A mailing list about lesbian and gay concerns on college campuses including, but not limited to, outreach programs, political action, AIDS education, dealing with school administrations, social programs, and just finding out what other support and social groups are doing. IItems of general gay/lesbian interest are also welcome. Requests to be added or deleted from this list, problems, questions, etc., should be sent to gaynet-request@ATHENA.MIT.EDU. The list is not moderated. IDX3000@SUVM Mailing list for discussion of the IDX-3000 Data PBX (manufactured by M/A- COM Linkabit). Topics include good news and bad. Archives are available through revised LISTSERV. To subscribe, send the following command to LISTSERV@SUVM via message or the the first line of a mail file: SUBSCRIBE BIG-REQ Your_full_name Coordinator: John Wobus INFO-CELERITY@DOLPHIN.BU.EDU Discussions pertaining to superminicomputer systems manufactured by Celerity. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to INFO-CELERITY-REQUEST@DOLPHIN.BU.EDU. Coordinator: Glenn Bresnahan 1 Page 16 INFO-MINIX@UDEL.EDU Mailing list for the discussion of the Minix Operating System: a Version 7 Unix clone written for IBM Compatible PCs by Andy Tanenbaum (minix@vu44.uucp or minix@CS.VU.NL). This list is gatewayed to the BITNET list MINIX-L@NDSUVM1 which in turn is gatewayed to the USENET newsgroup comp.os.minix. Archives are available by request from INFO-MINIX-REQUEST. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to INFO-MINIX-REQUEST@UDEL.EDU. List Maintainer: James Galvin mail.interleaf Discussions on all aspects related to the Interleaf publishing environment, including (but not restricted to) the Interleaf language, user environment, implementations on new platforms, user written enhancements, and filters, bug reports and workarounds. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to leaf-request@TEKSCE.SCE.TEK.COM Coordinator: Pete Lancashire ORGCHE-L Organic Chemistry mailing list. To facilitate the interchange of ideas, information, computer programs, papers, to announce opportunities for doing collaborative efforts (teaching and/or research activities) between specialists in Organic Chemistry and related areas. To subscribe to the list send an interactive message or mail file with the following command to LISTSERV@RPICICGE: SUBS ORGCHE-L Your_Real_Name Coordinator: Asuncion Valles SQLINFO%UICVMBITNET@WISCVM.WISC.EDU Mailing list for discussions about SQL/DS and general database topics. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to INFO@UICVM. Coordinator: Glori A. Chadwick 1 Page 17 STAMPS@QUEENS Discussions concerning philatelic matters of all kinds, new issues announcements, and news items. Coordinator: Geert K. Marien ************************************************************************* * Feedback * *************************************************************************** Date: Wed, 25 Nov 1987 10:44 PST From: Gene Hart Subject: Netmonth suggestions Chris, you certainly won't catch me volunteering to write write something for NetMonth (my excuse is that I don't know enough about anything), but I have suggestions: 1) An article describing the network of networks out there would be very interesting. I think that I have a good idea of what BITNET is, but what is Internet and what is NSFNET? What is ARPAnet, CSnet, DECnet, etc. Clearly this could go on forever. A very basic piece, just describing what some of these networks are (mentioning gateways only in passing) could be very interesting. 2) An editorial or article on the gateway problems/discussion going on could be very interesting. I am thinking here of discussing the politics involved. Why does WISCVM want to get out of the posistion? Why is the solution to have regional gateways? 3) An article on gateways which is more technical, that is why do some only pass a certain kind of mail, a simple description of TCP or whatever this new protocol is called. 4) A simple discussion of why domain names are good and why they should simplify the network. 5) A column I would find interesting would be to take a to and a from address each month and follow that path of a message and a reply. This could start off simple (bitnet to bitnet) but could also get into interesting gateway stuff such as that the return path can be quite different that the to path. The problem of ebcdic to ascii conversion changing characters could also be addressed. For example, I exchange mail with someone in Australia and I don't have any idea what strange contortions my messages have to go through to get to her. I realize that as a network user I have no NEED to know, but it still would be interesting. 1 Page 18 I hope that you find something useful in these suggestions. As you can infer from these ideas, I frequently use bitnet as a path to get to other networks and I assume that many others on bitnet do as well. It would be of interest to many people if NetMonth devoted more space to other networks. P.S. Of course, I need to add that I find NETMONTH very useful and interesting. Keep up the good work. ****** Thanks for the ideas! However, I won't take any excuses failure to make contributions. :-) *************************************************************************** Date: 25 November 1987, 20:44:30 EST From: Tim Sly This may not be anything new, but we are using the international networks to supervise our exchange students. The university at Umea in Sweden (Seumdc51) and Ryerson Polytechnical Institute (Toronto, Canada) are the only schools of environmental health in the two countries. We exchange students in their respective final years, and one of the tasks they are required to carry out is a research project in the health field. Supervision of the project is carried out between the student and the advisor through the medium of the north american and european networks - including the sending of drafts, and revisions. The arrangement works very well, and if the time zone 'window' is taken into account, direct interactive 'conversation' proves invaluable. Tim Sly, School of Environmental Health, Ryerson ************************************************************************* * 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 VAX/VMS users can subscribe in a similar way: SEND LISTSERV@MARIST SUBSCRIBE NETMONTH Your_full_name 1 Page 19 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 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."