* * * * * ** * ** ** * * * * * * * * * * * * * * * ***** ******* * * * ***** ****** ******* ****** * * * * * * * * * * * * * * * * * * ******* * * * * * * * * * * * ** * * * * * * * * * * * * * ****** * * * ***** * * * * * * * * The monthly guide to BITNET servers and services * * * * Volume 1 Number 9 March 1987 * * * ***************************************************************** * * * Editor: Chris Condon CONDON@YALEVMX * * Assistant Editor: Steve Sutter SUTTER@YALEVMX * * NetMonth Staff Supervisor: Gary Moss MOSS@YALEVMX * * * ***************************************************************** * * * File queue? What file queue? I don't see any... * * * * * * * * * * * * * * * * * * * * * * * * * * * * 000000000 * 000000000 * * 0000>>>>>>>>>0000 * * 00000(((((((((((((( * ))))))))))))))00000 * * 000((((((((((((((((((( * )))))))))))))))))))000 * * 00!!!!!!!!!!!!!!!!!!!!! * !!!!!!!!!!!!!!!!!!!!!00 * * 00((((((((((((((((((((( * )))))))))))))))))))))00 * * 00>>>>>>>>>>>>>>>>>>>00 * * 000000000000000>>000000000000000 * * 00((( * )))00 * * 0((( * )))0 * * 0((( * )))0 * * ''''4''''3''''2''''1''''0''''1''''2''''3''''4'''' * * 00(((( * ))))00 * * 000(((((( * ))))))000 * * 0000000000000 * 0000000000000 * * &(>&)>((>&>>)@&#&)&%(>@&<&<%(<#<<@ * ***************************************************************** 1 ************************************************************************* * Contents * *************************************************************************** Bitnotes ................................................................ 1 TAKE NOTE__________________________________________________________________ Scuttlebut .............................................................. 1 Netcon - Spring 1987 .................................................... 3 Global Teachers' Network ................................................ 4 FEATURES___________________________________________________________________ Network Load ............................................................ 5 To NIC or not to NIC? ................................................... 9 NetMonth Reader Survey Results ......................................... 14 SERVERS AND SERVICES_______________________________________________________ A New File Server: SERVER@SUZEUS ....................................... 16 A New Name Server: VMNAMES@UREGINA1 .................................... 18 New Mailing Lists ...................................................... 20 MACSERVE Moves to PUCC ................................................. 22 DEPARTMENTS________________________________________________________________ Feedback ............................................................... 23 Policies ............................................................... 24 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. 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. ------------------------------------------------------ FuzzyBytes Electronic Publishing "Because We're Here." 1 Page 1 ************************************************************************* * Bitnotes Issue 8 * *************************************************************************** Nobody, so I'm told, is perfect. This came as a shock to me, but I have learned to live with it. My juggling of School/Work/Friends/Netmonth has become (to say least) strained. This has two major implications: 1. ALL of the glorious improvements that the Reader Survey inspired do not appear in this issue of NetMonth (or in BITNET SERVERS). They will be appear slowly but surely in the next few issues, as I find the time to deal with them. With this issue we have made the initial change of organizing the articles a bit more (see the Table of Contents for details). 2. I am unable to give you a proper Bitnotes this month. However, there are some issues which need to be addressed, but I just haven't found a moment to write about. These are fairly complex, and a LOT of debate has been keeping my mailbox full of interesting postings to LIAISON and LSTSRV- L. I have chosen the best of these to replace me for this month. And, rather than contact all of the people involved for permission, I have simply removed any traces of names and network addresses. You will find all of this in the articles "Issue: Network Load" and "Issue: To NIC or not to NIC?" Before I go, one last issue to address: Please excuse our odd publishing schedule. This magazine goes to the "presses" on the second-to-last weekend of each month. We have not been late. Just strange. Virtually, Chris Condon@YaleVMX ************************************************************************* * Scuttlebut * *************************************************************************** All the news that's fit to bit... * From Zvika Bar-Deroma: The LOOKUP name servers at RITVAXA/B/C/D have been consolidated into one server: INFO@RITVAXD. For more information send the HELP command via interactive message to the server. (More information will be published in April NetMonth, or as soon as the links are up (whichever comes first). --Ed.) 1 Page 2 * From Niccolo' Avico: "The LFCNET file server has been shut down for an unlimited period of time; this due to a rearranging of the files stored. The main reason for this is that this kind of server is no longer needed to the net. "LFCNET was born in a pioneering era, which is now over: no LISTSERV, NETSERV and other amazing servers were available then. The network load was also lower, and a file server like this was able to survive. Now this is no longer the case. I can understand this. "Moreover I already planned to definitively close LFCNET because of it is time consuming for my own life. Because of this there remains the possibility of permanent shutdown." * From John Voigt: "TCSSERVE is being discontinued in favor of the file service facilities on Eric Thomas' LISTSERV. Most of the files previously available on TCSSERVE are now available from LISTSERV. To get a current filelist of what was moved one of the following commands should be used: "INDEX TCSSERVE" or "GET TCSSERVE FILELIST" "The main reason for this change is the additional capabilities offered by the LISTSERV file server. It will respond to mail, messages, notes and files. TCSSERVE only responded to interactive messages, something that a very large part of the network was incapable of sending. We regret any inconvenience these changes cause. Our desire is to provide the best possible service to the BITNET community and we feel these changes will better serve the needs of most BITNET users. "We have also implemented a local LISTSERV command to provide NAME service. The command is $WHOIS and will return E-mail address for most of the user at Tulane University. To use this service simply send a command to LISTSERV of the form: "$WHOIS userid/last_name". Note that some users have several accounts and all will be displayed. I would appreciate comments, complaints and problems be reported to me." TCSSERVE processed over 30,000 commands 16,743 files were sent to 3,861 users at 389 different nodes. * From Peter Jaspers-Fayer: "As of Mar 1st, the old and creaking SERVER@UOGUELPH will no longer be running. The project was fun once, but politics have so soured the whole concept here that I haven't touched it in many months. I'm putting it out of it's misery." * New list servers/file servers: LISTSERV@IRISHVM and LISTSERV@BYUADMIN. Thanks to Nick Laflamme and Rocky Waters for this information. * New NETSERV file servers: NETSERV@NORUNIT, NETSERV@TCSVM, and NETSERV@MARIST. 1 Page 3 ************************************************************************* * NetCon Spring '87 * *************************************************************************** NETCON SPRING '87 A chance to meet fellow Bitnetters and Relayers! WHEN: May 22-25, 1987 WHERE: New Orleans, LA REGISTRATION INFO: $10 fee due April 24, 1987 (Make checks payable to Jim Harmening) Send to: Jim Harmening 2033 W. 108th Place Chicago, IL 60643 HOTEL INFO: New Orleans Marriott 555 Canal Street New Orleans, LA 70140 504/581-1000 HOTEL COST: $49.95 for 3 nights, 4 people per room, payable to the the hotel upon arrival. To guarantee for late arrival (after 6 p.m.), send a deposit to the hotel after May 11, 1987. RESERVATIONS: Send mail to Charlene Charette, GB0CBGS@TCSVM, BY APRIL 24, 1987, TO RESERVE A ROOM. Include your name and rooming preference. In addition, between May 15-21, 1987, send mail to Charlene Charette, GB0CBGS@TCSVM, to confirm (or cancel) your hotel reservations. NETCON T-SHIRTS: Send mail to Jeff Robinson, IP60583@PORTLAND, if you want to purchase a Netcon T-shirt. ADDITIONAL INFO: For additional information, signon to the Netcon mailing list, NETCON-L@NCSUVM, or send a note to Scott Campbell, SCOTT@UTORONTO, or Paul Ribeiro, ACPS2681@RYERSON. TENTATIVE AGENDA FRIDAY, MAY 22, 1987 3:00 or later Checkin at Marriott Hotel 8:00 p.m. Welcome and greetings party 10:00 p.m. Night on the town 1 Page 4 SATURDAY, MAY 23, 1987 10:30 a.m. Seminar--Past and Future of Bitnet 11:30 a.m. Seminar--Past and Future of Relay 12:30 p.m. Lunch and site seeing (on your own) 7:00 p.m. Dinner as a group after dinner Night on the town--French Quarter SUNDAY, MAY 24, 1987 Whenever Breakfast/Brunch Whatever: tours, zoo, paddle boats, street cars MONDAY, MAY 25, 1987 Whenever Goodbyes and departure ************************************************************************* * Global Teachers' Network * *************************************************************************** by Glen Turnbull CEK4@UBCMTSG and Jeremy Meharg NEG8@SFU To: All Educators of Children Throughout the World Those of you who are reading this message are well aware of the fact that this, our planet is growing increasingly smaller by the day. Current technological advancements in telecommunications and electronic mail provide the capabilities for Global Communications never before dreamed about. With these new open channels of communication comes the ability to learn more about others and the existing diversification of cultures. This knowledge could lead to an increased awareness and clearer understanding of people throughout the world and encourage the acceptance of others and eventual Global Peace. It is with the purpose of promoting these ideals in ALL children that we wish to encourage the development of a Global Teachers' Network. We wish to offer our location (Vancouver, Canada:EXPO-86) as a focal point for the GTN. Using whatever Network system your country has, we request that you pass this message of hope along to others who are connected to your system. If you are sincerely interested in becoming a participant in the Global Teachers' Network, send your name and telecommunications address to our location. We will confirm your involvement in the GTN and discussions should start soon. 1 Page 5 ************************************************************************* * Issue: Network Load * *************************************************************************** From the LIAISON and LSTSRV-L mailing lists: Something to think about. =========================================================================== This notice is a follow-up to one that I posted in December. The situation now is even worse than it was then. As I mentioned then, we began seeing constant queues on the line to OHSTVMA as soon as Version 2 of RSCS was installed. That may not be the ultimate cause but that is exactly when we began having the queues. Over the holidays, the traffic diminished enough to allow the queue to clear out. The situation now is that we have files queued for the line that arrived as long ago as Feb 2. In fact, we have 60 files queued that arrived the first week of Feb., 169 files that arrived the 2nd week, 152 the third week, and 166 files this week. Several days ago, I ordered the queue so that all routing tables from the first or second week were finally sent. The traffic is slowly but steadily increasing. A significant change is required to handle it. Installation of modems running faster than 9600 would certainly help. A Reduction in the number of requests to servers around the network would help. Running a RELAY at PSUVM might help. Running V2RSCS at PSUVM might help. A line from CUNYVM to another western or mid-western node would help. These and other changes can be made to help alleviate the situation. Until then, network users must expect and tolerate some very long delays. =========================================================================== KNET-L subscribers on the TAMVM1 LISTSERV are missing some letters that were submitted at the DB0TUI11 peer of this list. They are all waiting at PSUVM to be transmitted to OHSTVMA where there is some terrible problem with files of any significant size getting through. I understand that some files are weeks old. =========================================================================== If everyone would shut their servers off for the weekend, we might, just might mind you, approach some sanity! PSUVM-OHSTVMA queue always >1000 (file from 2/2 still there!) BITNIC-EARNET queue > 2000 all this week (except one morning it was 1850) CUNYVM-PSUVM always 750-1000 files The major culprit by far is the KERMit server at CUVMA, but there is alot of other duplicate junk file traffic as well!!!! 1 Page 6 =========================================================================== We can shut down our servers and probably the queues will slowly decrease, but after a sufficient period of time this will happen again. To me it's obvious we must make some structural changes in the method of distributing files. For example: BITNIC-EARNET queue > 2000 all this week (except one morning it was 1850) I cannot understand why the BITNIC LISTSERV is not peer-linked for *every* list to an EARN server (a server in EARNET would be idoneous, but we don't have one at present, so perhaps CEARN could do the job). I've been taking a look quite regularly at the BITNIC-EARNET queue this week and most of time the 255 first files are mail from listserv for several lists. Until we get that fixed, european users may want to help by signing off from the BITNIC LISTSERV and subscribing to one of the european redistribution lists. =========================================================================== I have talked to Brian Nelson at Toledo about KERMSRV @ UOFT02 getting smarter (he was going to relay this idea to CUVMA). He was in agreement. Here are my suggestions: Set up a warning period for KERMSRV requests: If requests come in from the "wrong" side of the OSU/PSU link, tell the requestor that he should use the other kermsrv. (then either honor the request with warning of his regional server or forward the request to correct server and tell user what's going on...) Then plan for regional service areas: KERMSRV @ UOFT02 for west of OSU-PSU KERMSRV @ CUVMA for east of OSU-PSU and have each server respond with a file-being-sent or use-other-server msg. I realize the "what if one server is down" situation needs to be solved too. But this should also be part of the region server solution. =========================================================================== Considering the back log that has been occuring at the PSUVM site, and any other sites...I have noticed exceptionally large files being transmitted. A super example was one sitting in the queue for CUNYVM at PSUVM (and is 1 Page 7 most likely still there) that was a mere 94,425 records. (this translates into at least 7M bytes - a tad over the max file size recommended for BITNET usage.) I think becoming a bit more rigid about file transfer would assist a bit in relieving the backlog and network load problems. Now, the other problem is to come up with a good way of monitoring the file sizes without having to keep a human eye on it ... is the author of NETMON still around...maybe an option to NETMON to monitor the file sizes every minute or two and if file is large...place it on hold and notify the local staff to make a decision to flush the file. Again, this attitude may be a bit rigid - but we have to start somewhere?? yes? =========================================================================== I was always somewhat suspicious of NETMON (perhaps falsely so) because, as I understood it to work, it queries link status over the whole network periodically (10 minute intervals?) and parsed the returned output. If you check every link, that is 1700+ queries going out and somewhere in the same neighborhood of messages returned. That is one heck of a message load and will freeze file transfers for a significant period of time. If you rig NETMON (et al) to query another node's queues, recall that you can get 100 messages back (if 100+ files are queued). Kaboom. Another issue everyone is bouncing around is that of relocating servers and so forth to 'this side or the other' of 'this or that bottleneck'. As of 6:00 AM EST this morning (when queues *should* be *empty* and all normal people in the US should be asleep) the following queues were left: PSUVM -> OHSTVMA 469 files; OHSTVMA -> PSUVM zero. CUNYVM -> PSUVM 887 files; PSUVM -> CUNYVM zero. BITNIC -> EARNET 1660 files; EARNET -> BITNIC 10 files. Bob Fowles observed that some 30% of his queue was from Bitnic servers. I would suspect a sizeable portion of the queues were also accountable to Kermit and/or LISTSERV as well. Suggestions have been kicked around about moving certain servers to PSUVM and/or OHSTVMA, etc. In any case, an attempt is made to subdivide the 'hub' into other segments, and then placing servers on the corresponding hub. It may sound ludicrous at first, but the best solution would be to put the server for a given segment as far out in left field as you can find a volunteer (and you usually find volunteers out on the ends). As you will note from the queue sizes above, the bottleneck is OUTBOUND from the hubs; there is little or no backlog INBOUND. By placing servers on some end- node, the traffic is now INBOUND, with the bulk of the traffic going on links which are normally relatively idle. As the remaining copies approach the crowded hubs, the number of copies will decrease; with the last copy going to the hub node itself. 1 Page 8 There is still a considerable amount of bandwidth left in the network, it just happens to be going in the 'wrong' direction. We could, with some effort, take advantage of these available bitbuckets. =========================================================================== It is all very well to explain why BITNIC's servers *had* to be shut down to alleviate the backlog at critical network links, but that doesn't address the issue I raised, namely, that LISTSERV, in particular, need not place an appreciable load on any of the critical links. Surely, in view of the evident crisis, this would be a very propitious time to link the BITNIC LISTSERV with the many available peer servers throughout the network. The advantages are obvious: 1. BITNIC could immediately shift subscribers to the peer servers. 2. Mail to one of the BITNIC lists would generate only *one* copy over each of the critical links. 3. Mail sent originally to one of the peer servers (i.e., mail other than a reply to a previous message) would already have been distributed to subscribers downward of the corresponding critical link to BITNIC and so would not generate any return traffic at all. 4. BITNIC could legitimately delegate the responsibility for archiving list traffic to one or more of the peer servers, thereby cutting off another source of load on the critical links, namely, file requests. 5. BITNIC could automatically assign new subscribers to their nearest peer server, thereby avoiding the necessity of close human scrutiny. 6. BITNIC could even legitimately restrict the file server aspects of its LISTSERV. For example, the usual memo files describing all the aspects of LISTSERV could be replaced by short messages listing the peer servers and suggesting that requests be referred to the nearest one. =========================================================================== If NICSERVE saves large file requests until after midnight when most of my users have logged off and gone home I have no problem with using DISTRIBUTE to send the files. Especially when the alternative is for me to have to wait 3 weeks and still not get my file, or to have to receive and then send 10 copies to people beyond me in the network. I'd just as soon receive one copy and generate the others needed. NICSERVE needs to have a size threshold beyond which files are sent via distribute. Small files can be sent now, big ones should be held and DISTRIBUTED after midnight to everyone who requested them in the past 24 hours. 1 Page 9 ************************************************************************* * Issue: To NIC, or not to NIC? * *************************************************************************** From the LIAISON mailing list: Something else to think about. =========================================================================== In reading mail from this and other lists I there seems to be a general pattern of people asking for software for a Vax or Unix machine, and the responses are always, "sorry, it only runs on IBM". I know IBM helped start Bitnet, but as I scan the nodes list, I see a tremendous number of non-IBM machines, yet I have noticed no real effort by BITNIC to bring these people "into the fold" other than a simple connection to Bitnet. Are all the people at BITNIC IBM blue-bloods? With so many other systems out there, I should think the people in power would make a stronger effort to convert software, but I haven't even heard any verbal efforts. And with all the talk of heavy Bitnet traffic and delays, many of the proposed software solutions (more servers, more local distribution of files, etc. ) cannot be effective because at least half of the machines out there cannot run it. Even if they wish to remain loyal to IBM, I bring to their attention that IBM, along with many other firms, has publicly expressed support for the proposed POSIX (UNIX) standard, so there is at least one non-VM operating system that we all can support without offending anyone. Anyway, if all of the rest of us gang up on the IBM people, maybe something might get done. =========================================================================== I think you need to get the horse and the cart in the right order. First, BITNIC has *NO* money for development. Most of the network tools in use on BITNET's IBM systems were written by volunteers. In the past, some software was developed by BITDOC, not BITNIC, under a grant from IBM. Perhaps DEC would like to make a million dollar grant to BITNET for better support of VAXen on BITNET? On bad days I am prone to think that maybe getting BITNIC was one of the *WORST* things to happen to BITNET. It seems to have stifled our volunteer spirit. Õsorry, but the libertarian in me just can't help noting that this is much like people who feel that since we have government the way to solve all problems is to pass a law saying that someone else should solve the problem.å Certainly it is in all our interest to have BITNET working equally well for all kinds of computers but the non-IBM part of the net is I think going to accept a lot of responsibility for making that happen because you have the most to gain. The NIC's job is to coordinate and facilitate, and I'm sure that to the extent that they are made aware of non-IBM tools out there they will do their best to see that those who need to know about them can find out about them. If they don't, then fault them. 1 Page 10 =========================================================================== Also, VM systems were on the net first (with network-inadequate IBM vanilla code) long enough for people to get frustrated enough with %#$^&% IBM NOTE etc to write something better. It's only a matter of time before there are MAILERs and so on for VMS and UN*X too. But you VAX folks have to write them! Speaking for myself, anyway, I don't think the IBMers on the net are in any way prejudiced against VAXers* - we'll be glad to support the effort to translate/analogize VM tools to whatever you want to run them on. If it helps the network, it helps all of us. =========================================================================== Recent discussions on NODMGT-L have discussed this touchy issue somewhat. I believe the consensus has been, yes, we need equivalent tools for other, non-IBM systems. However, under the new charter recently adopted, BITNIC has no money for development. The consensus from that has been, ok, it's up to the VAX sites or the UNIX sites or whomever; we'll give as much support as we can in explaining algorhythms or data structures, but no one is going to do it for them. I disagree with your contention that VM-based tools will not be adequate to relieve the network load. The network backbone, that which is most overloaded, remains VM-based. We therefore can put VM-based servers where they are most needed and where they can greatly reduce the load. I am not suggesting that non-VM versions should not be developed, but I am saying that doing just VM initially will in fact be a great help. While I understand your frustrations with the current situation, I think your grievances are being addressed. =========================================================================== First, it is nice to known that there are still a few libertarians around. I did not what to imply that money should immediately be spent on new programs, but I noticed that we non-IBM users tend to be ignored a lot. It would be nice to hear a word of encouragement or some recognition of our existence. Not only is there a gulf between DEC and IBM, but the same gulf often exists between the two user groups as well (also include Unix people in there own world). As to the spirit of volunteering, I also agree it is reduced. I am just a lowly programmer who is confused by tangled mazes of authority like Executive committees and EDUCOM and working groups. Any bureaucracy that is large enough to organize conventions with workshops, planning groups, 1 Page 11 elections, etc. frightens me (wouldn't a few mail messages between interested users have sufficed, and then let everyone on Bitnet who wants to send in a vote?). When there are powerful groups around, an individual had better not try anything alone without getting approval first, or risk the wrath of someone above, and I prefer to avoid such politics. Anyway, perhaps a few people will keep it in mind at that convention that there is a need for non-ibm software. (When I buy my Cray 4 with Unix, I want to have LISTSERVS and NETSERVS and RELAY too! ;-) ). =========================================================================== Surely, you aren't suggesting that BITNIC should purchase new computers and/or operating systems and hire a staff of programmers to develop fancy software for all the non-VM people on BITNET! Most of the whizzy packages we see were developed more or less spontaneously -- i.e., if you really want a specific piece of software, you must write it yourself or find someone else who wants it sooner than you do. =========================================================================== This lack of support from BITNIC does not only concern nonIBM systems. We are an MVS site (IBM 3033) and cannot get ANY support from BITNIC. It took a personal meeting with Michael and Judy to get on the LIAISON mailing list last time. It took a phone call from myself and the director at Cornell to get some information in the BITNET tables corrected. Judy, Scott, and company complain that they are vastly overworked. They must be, since many database items have not been updated in over a year. I have been finding out most of my information from other MVS sites who have gone through similar problems in trying to get information. I have found more helpful and knowledgeable support from the ARPA and CSNET information centers and the various gateway masters than BITNIC. =========================================================================== I have basically two questions: 1) Have alternate sources of funding for BITNET been investigated? For example, educational type grants, other companies (DEC, AMDAHL). Money and the fee structure seem to be the hook most user's are objecting to. 2) Where, EXACTLY, does the money go? Various nodes are (or seem to be) volunteering services to replace BITNIC at considerably lower dollar and manpower costs. My understanding of BITNET is that a great deal of work is done by member institutions on a "round-tuit" VOLUNTEER basis, including such important task as distributing routing tables. 1 Page 12 Point one has already been decided. Money hasn't been allocated for development, according to what I have read. Money apparently hasn't been allocated for info services either. Where did/does the money go? =========================================================================== Those are good questions... questions that a number of us asked, even fought over, before the charter was "approved." You are not alone in feeling that adequate answers have not yet been given. Let's back off, give them a few months to get themselves organized if they can, and then "give it to 'em Harry" if need be. After all, if indeed they are able to incorporate, and the organization doesn't leak like a sieve in court, then we, as purchasers and subscribers, have a solid position from which to demand change. And frankly, if this is the way that we can get a reliable, contracted level of service that is better than and more consistent than the voluntary (and very worthy!) efforts that we now have, born of necessity, then maybe this is not such a bad idea after all, eh? We shall see. We shall see. =========================================================================== The most critical fault that has been made to date by the BITNIC staff is to address themselves only to the upper-level campus administration. They were interested in securing money and recognition for themselves, and decided that this was where the money was. They saw no need to to invite the favor of the user community. In fact, they seem to be quite afraid of what the user community might have to say against them -- and therefore do not want to listen. They seem to believe that their jobs depend on it. But the opposite is true. If you want to reach the node administrators, you must do so through the users. You must do that by serving in the classic coordinating and facilitating role of true management, and by serving a perceptibly beneficial role. The computer center personnel in particular, the "Techhies," will be called upon to be advisors to the upper managers, who of course will not spend money without knowing whether the proposal makes good business sense. The "American Revolution" began when certain users realized that their needs were not being met in the EDUCOM proposal, and assumed that BITNIC would be favorable to a better approach. It ended, I believe, when those same people realized that BITNIC did not want to know. That was no victory for BITNIC, because a lot of ears were sealed up as these people simply went on the offensive. BITNIC has a lot of explaining to do now. We don't need an ivory tower in the middle of BITNET. We need a better BITNET. If BITNIC wants to help do that, then welcome aboard. Otherwise, good riddance. 1 Page 13 =========================================================================== I am glad to hear that at least the talk from Mr. D'Amore has improved by a quantum leap. At SIGUCCS in Montreal, I had a chance to talk with both Michael D'Amore and Judith Molka. At that point in time, they both maintained that BITNIC was doing wonderful things, and that everyone's problems were due to not following the proper procedure for obtaining information. In the session that they presented, they received a lot of hostile comments for their stance. Some of us at that point tried to maintain that it was impossible for them to know all of the possible types of connections to BITNET, and that they should possibly refer some queries to the network. Both of them asked the group if the group was willing to field questions, and we responded yes. In the months that have followed, there has been no change in the stance of BITNIC. When the ARPA-BITNET gateway was restricted, BITNIC didn't respond. I was not at SHARE, but from the comments that you are making, it doesn't seem that a good solution to the traffic problem was reached. I also haven't heard any progress in regard to running TCP/IP across the network, which would allow for some better routing protocols (if the hardware was in place). =========================================================================== I will agree that it is somewhat disheartening that BITNIC cannot provide all the services that it once provided and/or we think it ought to. There are, however, several on this list that could possibly help out with the volunteer effort to keep up some of these things. If BITNIC cannot help us the way we need, then maybe we can help ourselves. What we really need I think right now though is someone to volunteer to help coordinate the volunteers...collect all the "we wants" and all the "I will helps" and match them or something. In other words, couldn't we have just a little organization of the volunteers? * * *** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *** * * 1 Page 14 ************************************************************************* * The NetMonth Reader Survey RESULTS * *************************************************************************** 1. How long have you been reading NetMonth? 20% a. 1-2 months 17% b. 3-4 months 9% c. 5-8 months 54% d. I was a Bitlist reader 2. Are you a(n): 23% a. undergraduate student 14% b. graduate student 44% c. computer center staff 25% d. educator (doctor, professor, teacher, etc.) 11% e. other 3. How old are you? 31% a. 18-25 33% b. 26-35 30% c. 36-50 5% d. 51+ 3% e. none of your business! 4. Are you: 97% a. male 3% b. female ÕHa! -- Assistant Ed.å ÕOne wonders if there is any connection between 3% who are female and the 3% who wouldn't admit their age... -- Ed.å 5. Do you read any electronic magazines other than NetMonth? 51% a. yes 49% b. no 6. Do you subscribe to any digests/mailing lists? 65% a. yes 25% b. no 1 Page 15 7. How often do you sign on to RELAY? 6% a. almost every day 18% b. a few times a week 14% c. a few times a month 21% d. not more than once a month 40% e. never 8. Have you ever used a file server before? 93% a. yes 7% b. no ÕMostly NETSERV, CSNEWS, and LISTSERV. -- Ed.å 9. Have you registered yourself on a name server? 51% a. yes 49% b. no ÕMostly NETSERV and CSNEWS. -- Ed.å 10. What operating system is your mainframe running? 71% VM/SP, VM/CMS 17% VAX/VMS 6% MVS/XA 1% MTS 1% TMO Results from the second half of the survey (your opinions on NetMonth) will be published in the next issue. The results of essay questions, as some of you know, are difficult to quantify. However, we have gotten several distinct messages about what you would like to see and where the magazine should go in future issues. Other conclusions are hard to draw since most of you disagree on key points, such as how technical the articles should be. More in April. ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** ***** 1 Page 16 ************************************************************************* * A New File Server: SERVER@SUZEUS * *************************************************************************** by Tony Dahbura TONY@SUZEUS The SERVER Virtual Machine at SUZEUS (Syracuse University) will send you any file it has access to excluding its internal system files. Valid commands are: LIST LIST userid cuu password SEND fname ftype SEND fname ftype userid cuu password NODE bitnet node name WEATHER city ID You should send commands to SERVER@SUZEUS via interactive message, such as TELL, MSG or SEND. Command explanations: LIST will send a list of the server's files. If the optional is specified i.e. TELL SERVER AT SUZEUS LIST D, and the extra disks are available (based on free disk space at SUZEUS) then a listing of the files on the specified disk will be sent. Default mode is A. LIST userid cuu password will cause the server to try to link the specified account's disk using the password supplied. The link will be a R/O only link. Thus all files that are of type A0 will not be included in the listing. This feature is mainly for SUZEUS users when at other nodes. If the disk is a public disk (no password needed to link) then don't supply a password. HELP will cause the server to transmit its help file (this document) to you. SEND fname ftype will cause the selected package to be sent - packages are a list of all files associated with a certain program. For example requesting the PLIX package would send all the required plix files with one easy command. To request the PLIX package issue the send command as SEND PLIX. If the package were on a minidisk at mode D then you would have to spell the entire name out i.e. SEND PLIX PACKAGE D. NOTE: If the requested file is over 30 blocks in size and SUZEUS system time is between 7:30 am and 8:30 pm the file will not be sent. You will be told if this happens and your request will be queued and handled after prime time. 1 Page 17 SEND fname ftype userid cuu password will cause the server to try and link the specified disk and send the file. See the LIST command for details on linking. NODE will take any valid bitnet node name (* accepted as wildcard) and will return the name of the node. If the wildcard forces more than 4 nodes to match then only the first four will be sent. WEATHER will give you the latest up to date weather forecast for most major US cities. Passing a ? or nothing will result in a list of the valid cities. This feature is provided courtesy of Niagara Mohawk Electric. ID will send an identifying message back about the server. Notes: Please be patient with the server as it is running on a trial basis. Please do not cause network overloading by trying to download every file on the server. The LIST files are sent in EXEC format. You can edit the file and remove the files you don't want and using the following REXX program you can request the server to send the remaining files. ************************************************************************* * * * * * /* GET FILES FROM SUZEUS */ * * 'EXECIO * DISKR CMS EXEC (FINIS' * * DO I = 1 TO QUEUED() * * PULL . . FNAME FTYPE . * * 'TELL SERVER AT SUZEUS SEND 'FNAME' 'FTYPE * * END * * * * * ************************************************************************* Finally - If you have a program/exec you think others might find useful or helpful then send it to the SERVER at SUZEUS. Please address suggestions/questions/complaints etc. to Tony Dahbura, TONY@SUZEUS. 1 Page 18 ************************************************************************* * A New Name Server: VMNAMES@UREGINA1 * *************************************************************************** This name server knows of any userid on Regina's VM system who has signed up to the name server via the ADD command. In addition it provides a few network services that are described below. Users can send commands to this server in many different ways: 1) INTERACTIVE MESSAGES (valid only for Bitnet users): TELL VMNAMES at UREGINA1 command SMSG rscsid MSG UREGINA1 VMNAMES command SEND VMNAMES@UREGINA1 command These commands are only valid for Bitnet users who have the ability to send interactive messages. Responses sent back from VMNAMES will be via interactive messages. 2) FILES (valid only for Bitnet users): VMNAMES will also respond to a file that arrives in either CMS PUNCH format (with or without a header - both are accepted) or via the CMS PRINT command. The file should contain only one line and it should contain the command that you wish to execute. VMNAMES will send its responses back as a file based upon the format and file class of the received file. Files that arrive in any other format (i.e. Cornell's Card, Disk Dump format, etc.) will result in this help file being sent back to the originator. 3) MAIL (valid for all Internet users): VMNAMES will accept standard Bitnet mail files as commands. The mail must arrive with a filetype of 'MAIL' and a class='M' in order for VMNAMES to recognize the file as being mail. This is the format of Bitnet standard mail files. In addition, the mail must conform to Arpanet standard RFC822. If your 'From:' field does not supply a fully qualified network address, then VMNAMES will not be able to send mail back to you. Example: Valid address: From: xyzzy@mitre-bedford.arpa Invalid address: From: xyzzy@mitre-bedford 1 Page 19 The first non-blank line after the mail header will be accepted as the VMNAMES command. Address your mail to: VMNAMES%UREGINA1.BITNET@WISCVM.ARPA if you are located on another network other than Bitnet. 4) IBM NOTE (valid for Bitnet users): VMNAMES will accept standard IBM NOTE format files. It will send its results back to you as a file based upon the information contained in the received file. COMMANDS: HELP WHOIS ] AUTOLOG vmuserid pswd ADD DELETE HELP - returns this file and will only be returned as either a file or as mail. HELP will not respond via interactive messages. WHOIS - will determine what the person's real name is behind the userid, or if lastname is given, will return the userid as associated with that last name. Searching by userid will return one person, whereas searching by lastname may return many people (i.e. WHOIS COHEN) If a match is not found, a phonetic search will be performed to try to find a match. AUTOLOG - is only valid via interactive messages or via a file. This is not a valid command via mail. This command will startup the specified userid and in addition will place the user in 'GONE' mode. If the user has customized his/her id properly, then remote commands can be entered from anywhere in Bitnet for execution locally. Care should be taken when designing your PROFILE EXEC. Any commands that use the program stack should be nested with MAKEBUF/DROPBUF. In addition, any commands within your PROFILE EXEC that require a response from the terminal (MAIL, RDRLIST, etc.) should be bypassed when running in disconnect mode. 1 Page 20 ADD - Adds the user along with the specified information to the names file used by VMNAMES. A 'NULL' in any of the fields except first name or last name results in that field being unlisted. DELETE - Deletes the user from the names file used by VMNAMES. Any modifications to any of the information contained in the names file may be accomplished by deleting yourself and then adding self back into the names file. For further details or if you have questions, contact: Thollrob@URegina1 ( Robert Tholl ) Malachkm@URegina1 ( Ken M. Malach ) Smidtshe@URegina1 ( Shelley Smidt ) ************************************************************************* * New Mailing Lists * *************************************************************************** ICECNET#@ANDREW.CMU.EDU ICEC, the InterUniversity Consortium for Educational Computing, is a consortium of universities and colleges committed to developing high- quality educational applications for advanced computing environments. ICECNET has been the newsletter of ICEC for several years. Paper publication continues, but a copy of each issue of the newsletter will also be released about once a month via this mailing list. ICEC has supported software development at member schools and conducted activities for faculty from member schools (e.g. developers' conference, training programs in courseware development for advanced workstations). Other mechanisms are evolving to promote development of good educational programs for advanced, graphics-intensive workstations and to aid in sharing these developments among interested parties. ICEC is therefore initiating an internet mailing list (1) for publication of information about ICEC, (2) communication among member schools related to internal business, and (3) as a forum for discussing issues related to the general objectives of ICEC. Examples of the third category might be "what constitutes high-quality courseware?", "what Unix workstations are best suited to general educational use?", "what mechanisms are best for sharing educational developments using advanced technologies?", etc., etc., etc. Individuals, both from member schools and from non-member organizations, are invited to contribute in this third area. 1 Page 21 All submissions for the monthly (paper) newsletter should be sent to: Patricia Clark,ICECNET editor or Robert Cavalier, assistant director of ICEC All requests to be added to or deleted from this list, problems, questions, etc., should be sent to ICECNET-REQUEST#@ANDREW.CMU.EDU. INFO-MODEMS@SIMTEL20.ARPA Info-Modems is a discussion group of special interest to modem users. The list is gatewayed to/from Usenet newsgroup comp.dcom.modems. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to Info-Modems-Request@SIMTEL20.ARPA. Coordinator: Keith Petersen INFO-PRIME%FNS1@USC-ECL.ARPA Info-Prime is a mailing list for discussion of Prime computers. Discussion on Primos, Prime Information (PICK-like database/operating system), and Primix (Prime's unix) are all welcome. There is no direct affiliation with Prime computer corporation (Prime employees are, of course, welcome to participate). Archives will be kept. To access them contact Info-Prime-Request. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to Info-Prime-Request%Fns1@USC-ECL.ARPA Coordinator: Bob Larson SIMULA@BITNIC A forum for people interested in SIMULA, a language for object-oriented programming and simulation; a member of the ALGOL family. Topics may range from hints on programming techniques to information about available software (both compilers and programs), questions and answers in general, etc. In short, anything that has to do with SIMULA. This group is not restricted to any specific implementation of SIMULA; the exchange of information between users of different implementations is encouraged. 1 Page 22 To subscribe to this list, send the following command to LISTSERV@BITNIC via interactive message (for example, TELL, MSG, or SEND): SUBscribe SIMULA Your_Full_Name (where Your_Full_Name is your name). If you cannot send messages, you can send the command as the first line of a mail message to LISTSERV. Coordinator: Per Lindberg ************************************************************************* * MACSERVE Moves to PUCC * *************************************************************************** From Bitnews March 9, 1987 MACSERVE Moves To Princeton University MACSERVE@PUCC, which replaces MACSERVE@BITNIC, is now operating at Princeton University. MACSERVE@PUCC contains a current and complete set of archives. In the past, the MACSERVE fileserver on the BITNIC node was updated by issuing an FTP to the SUMEX-AIM ARPAnet node, via borrowed 9600-baud line for TCP/IP. When the line became unavailable, MACSERVE could no longer be updated at node BITNIC. MACSERVE receives interactive commands only. To start using MACSERVE, VM sites should issue the following: TELL MACSERVE AT PUCC HELP For VAX sites: SEND MACSERVE@PUCC HELP Users at other sites should contact a local user-services representative. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 1 Page 23 ************************************************************************* * Feedback * *************************************************************************** Date: 9 March 1987, 11:28:50 EST From: Murphy A. Sewall SEWALL@UCONNVM To: Christopher M. Condon BITLIB@YALEVMX Subj: For NetMonth letters Although I've known Bitnet was "there" for some time, it wasn't until Fall '86 that I had any real need of it. Then in the process of communicating with a colleague at a distant university I began to "discover" (have handed to me really) bits and pieces about other useful services (COMSERVE, PSYCHNET, BITSERVE, etc.). I just discovered NetMonth (and got the Feb '87 from PSYCHNET which is rather inefficient because that amounts to send it back across the links from which it came in the first place -- it had to "pass through" Yale to get to me). Yes I would like to be added to the growing subscriber list. Can I get the back issues as it appears there are not a really large number and the letters column indicates that there are some interesting articles in them? I do not know much really about how "mass mailings" on Bitnet work. If there are a dozen or so subscribers at a single node, is one copy sent along the network and then "duplicated" at the receiving node? Would it be more efficient, if I could talk the local computer center staff into finding some disk space for recent issues of NetMonth (then they could get one copy and the rest of us could just read it)? Is there some handy source of info for us "late arrivals?" I find your BITNET SERVERS file interesting reading, but I not entirely up to the "jargon density" (I could use a fuller explanation of NETSERVers vs LISTSERVers for instance). Murphy >>> Our BITNET USERHELP file is generally helpful. It explains the differences between file servers, name servers, list servers, relays, and all of those other wonderful services. BITNET SERVERS will soon be undergoing major improvements, where each individual server listed will have a brief explanation of what kind of files are available, special features, and how it will accept commands (mail, message, file). USERHELP may be re-issued soon in a slightly revised edition which will reflect the recent changes to LISTSERV. (The last real changes were made in August of 1986. It's about time for an update). 1 Page 24 >>> You can get BITNET USERHELP from any NETSERV file server by sending the command SENDME BITNET USERHELP via interactive message or as the first line of a mail file. For example: TELL NETSERV AT BITNIC SENDME BITNET USERHELP SEND NETSERV@BITNIC SENDME BITNET USERHELP -- Ed. ************************************************************************* * NetMonth Policies * *************************************************************************** Subscribing to NetMonth and BITNET SERVERS: Send a mail message with your name and network address (userid@node) to BITLIB@YALEVMX (Arpanet users send your mail to BITLIB%YALEVMX.BITNET@WISCVM.WISC.EDU). 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@YALEVMX. 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@YALEVMX. 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. --------------------------------------------------------------------------- FuzzyBytes Electronic Publishing "Because We're Here."