* * * * * ** * ** ** * * * * * * * * * * * * * * * ***** ******* * * * ***** ****** ******* ****** * * * * * * * * * * * * * * * * * * ******* * * * * * * * * * * * ** * * * * * * * * * * * * * ****** * * * ***** * * * * * * * * The guide to BITNET servers and services * * * * Volume 2 Number 3 September 1987 * * * ***************************************************************** * * * Editor: Chris Condon CONDON@YALEVM * * Assistant Editor: Steve Sutter SUTTER@YALEVM * * NetMonth Staff Supervisor: Gary Moss MOSS@YALEVM * * * ***************************************************************** * * * ---- * * ---- ------ ----- * * ------ ------- ------- * * -------- ------- ------- * * -------- ------- -------- * * -------- -------- --------- * * ------- -------- -------- * * ----- -------- -------- -------- * * ------- -------- -------- --------- * * -------- -------- -------- -------- * * -------- -------- -------- -------- * * -------- -------- -------- --------- * * ------- -------- -------- --------- * * -------- ------- -------- -------- * * -------- ------- ------------------ ----- * * ------- -------- ------------------ ------ * * -------- --------------------------- ------- * * ------------------------------------ -------- * * ----------------------------------- ------- * * ----------------------------------- -------- * * ----------------------------------- --------- * * ---------------------------------------------- * * --------------------------------------------- * * ------------------------------------------ * * ---------------------------------------- * * -------------------------------------- * * ----------------------------------- * * ---------------------------------- * * ------------------------------ * * -------------------------- * * ------------------------ Look Ma, no hands! * * ----------------------- * ***************************************************************** 1 ************************************************************************* * Contents * *************************************************************************** Bitnotes ................................................................ 1 TAKE NOTE__________________________________________________________________ Scuttlebut .............................................................. 3 The CODATA Network Directory ............................................ 4 FEATURES___________________________________________________________________ CSNET Merger Discussions ................................................ 5 SERVERS AND SERVICES_______________________________________________________ Network Audio Bits: A New Electronic Magazine .......................... 11 DIRECT@QZCOM ........................................................... 13 Summer Brings Changes to Comserve ...................................... 17 NAMESERV@UNCAMULT ...................................................... 23 DEPARTMENTS________________________________________________________________ Feedback ............................................................... 24 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. The BITLIB system is now distributed to more than thirty educational institutions worldwide. BITNET SERVERS is BITNET's most complete and up-to-date list of servers and services. It is sent to NetMonth subscribers at the same time as the magazine. BITNET SERVERS is dependent on your support to remain accurate. If you know of servers and services not listed in BITNET SERVERS, or of those listed in the file that are no longer available, please contact the NetMonth staff at BITLIB@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 14 * *************************************************************************** "Invention breeds invention." - Ralph Waldo Emerson It isn't the dark that scares me, or heights, or even large crawling insects. It's Listserv. Oh, it's not the screaming-meemies kind of scared, it's more of the "feeling of dread and uncertainty" variety. It is the sort of feeling you can't describe because it originates in your intestines, not in your head. No, that's not gas. It's a gut feeling. This is confusing because I rather like Listserv. Surely it has been a great help to me in the distribution of NetMonth and BITLIB, saving me several hours worth of mailing list maintainence each week. It has quite literally revolutionized communications in BITNET, making relatively efficient user forums and mailing lists a reality. Listserv has been very good for BITNET. Why should I be scared? Perhaps a story would clarify my frame of mind: Once there was a file server named TCSSERVE@TCSVM. The server was fairly popular and prospered. Several months later, a Listserv was installed at that node. Another few months went by and TCSSERVE was installed as a subserver of the Listserv. Now, there is no more TCSSERVE. Now, I know that that this is a competative world, but the pattern is likely to repeat itself. UTCSERVE@UTCVM became a subserver of Listserv, as did SILMARIL@FINHUTC. Why? Becuase these servers performed nothing more than a standard file server function which could be adequately performed by Listserv. As a result, however, they became stripped of their identities. Listserv is a fine tool, but it is not a replacement for a file server. The popularity of the system should not preculde the development of new and better servers. ***** Speaking of new and better servers, I recently saw one of the best ideas to come to Bitnet in a long time. That is, a Comserve User's Guide. This may not be an object of incredible significance, but it is a great attempt to popularize the use of BITNET. The guide, written by Timothy Stephen and Teresa M. Harrison, is geared toward the Communications scholar or student who has never used BITNET before. It explains what BITNET and Comserve are, and the proceudres for contacting the server and sending commands. It 1 Page 2 is a good 56 pages long, in a very nice laser printed typeface. Free copies of the Comserve User's Guide are available by writing to: Comserve Department of Lang., Lit., & Communication Sage Labs Renssalaer Polytechnic Institute Troy, New York 12180 Or, you can send mail to SUPPORT@RPICICGE. COMSERVE@RPICICGE is supported by the Eastern Communication Association, the International Communication Association, and Renssalaer Polytechnic Institute. ****** On a thankfully lighter note, here is something from our own Josh Trupin: "The Top Ten Relay Pickup Lines" 10. Say, do you come to this channel often? 9. I'm on channel 169...wanna join me? 8. Hi! Ever heard of compusex? 7. I just read your ID....it's so beautiful. 6. What a coincidence! I used to date a girl with blond hair..once..*sigh* 5. We're only 16 hours apart...hey, wanna meet in Binghamton sometime? 4. You have a dog too? We must be kindred spirits! 3. I've always thought that Lisa was a pretty name. 2. I have a confession to make...I'm really a guy. And number ONE...... 1. Your eyes must be pretty....say, what color are they? Until next time, stay out of trouble. Virtually, Chris Condon@YaleVM ----- -- ---- -- -- - --- -- - - - - ---- ------- ---- ------ ---- --- - ------ ---- -- --- -- -- ------- ------- ------ ------- ----- --- - -------- ----- ---- --- --- --- -------- 1 Page 3 ************************************************************************* * Scuttlebut * *************************************************************************** * TCSSERVE lives no more: The subserver of LISTSERV@TCSVM recently discontinued service. TCSSERVE was originally a file server, and was later moved to Listserv. Thanks to Mike Ayers for this information. * A new Netserv: The latest in NETSERVs is now operation at University of California, Berkley (UCBCMSA). Thanks to Rocky Waters for the news. * Oh-no-not-again Department: Please note that the files COMPUTER TAG README TXT COMPUTER FUK READ TXT FATE LET are being circulated as 'chain letters'. If you receive one of these files, s delete it. Do NOT send it on to your BITNET friends. * Bitnews becomes a LISTSERV List: BITNEWS (the electronic newsletter of the BITNET Network Infomation Center) is migrating to LISTSERV at BITNIC. As a LISTSERV list, BITNEWS@BITNIC is open to all for self subscription. New postings to the BITNEWS list will only be sent by the Editor, Michael D'Amore or his staff. BITNEWS@BITNIC is not a discussion group. It is the BITNIC's official electronic news distributor. Other list names will be given with each contribution as a suggested location for further discussion of the entry. Finally, if you missed an entry, the news is still available in public notebook form grouped by month on LISTSERV@BITNIC. Postings will continue to be sent to both BITNEWS@BITNIC and to the files on NICSERVE for the months of September and October. * POLICY-L born from BITNET Technical Meeting: A new list called POLICY- L@BITNIC is open for self subscription. This forum was created by request of the people attending the BITNET Technical Meeting in Chicago. The list description provided below was written by Paul Jones (ULTIMA@UNC). POLICY-L is a forum in which proposed and present BITNET policies are discussed. It is intended to be a catch-all forum in part to fill in the spaces left between other list (Domains, Future, Node Management, etc.) and in part to provide a "birth place" for new discussion groups. An important function of the list is to allow for a dialogue among systems grunts, liaisons, managers, and BITNET directors (in short a unifying list). ----- -- ---- -- -- - --- -- - - - - ---- ------- ---- ------ ---- --- - ------ ---- -- --- -- -- ------- ------- ------ ------- ----- --- - -------- ----- ---- --- --- --- -------- 1 Page 4 ************************************************************************* * The CODATA Network Directory * *************************************************************************** by Elaine Ross ERM@NICHU The CODATA Network is an international communications network set up on Dialcom (system 42). It has been established for scientists and engineers to communicate worldwide. There are several services available through the CODATA Network, but the major ones are database services (which at present include catalogues of the American Type Culture Collection; Hybridoma Data Bank Directory of commercial monoclonals and hybridomas; Microbial Strain Data Network Central Directory); electronic mail and computer conferencing. The users of the CODATA Network are around 150 at present and this number is slowly increasing. The main users of the CODATA Network are quite varied in both scientific and technical disciplines and geography. The main groups are as follows: - CODATA Exec. Board & Committees (Task Groups) A number of Task Groups of CODATA are using the CODATA Network such as the Protein and Nucleic Acid Sequence Data Bank Coordinating Task Group; the MSDN Task Group; the Hybridoma Data Bank (HDB) Task Group. - The MSDN Secretariat is responsible for system management of the CODATA Network and is encouraging the participation of microbial resource centres throughout the world. - The American Type Culture Collection (ATCC) has several catalogues on the CODATA Network, including the ATCC Cell Lines Database, and the ATCC Protozoa and Algae Database. ATCC can be contacted for information or to place orders for cultures through the Network. - Users listed in the CODATA Directory are involved in many areas Biomedical, microbiological, and other departments in educational establishments and industry; the International Council of Scientific Unions and the International Union of Biological Sciences are represented, aswell as the Society of General Microbiology Computer Club in the UK and the Microbiology Computer User Group in the US. Many other disciplines are represented. Users are from over 20 countries, including UK, USA, Canada, Australia, Japan, countries from Central and South America, and Europe. - The CODATA network is currently set up on a US Dialcom system. Plans are active to set up another system on UK BTGold. Users will have ID's for both systems listed in the CODATA Network directory and will be able to use either or both systems. To use the CODATA Network services, there is a one time subscription fee of $25.00. Please do not hesitate to contact me (Elaine Ross, Dialcom 42:CDT0001 or Bitnet URM@NIHCU) for further information. 1 Page 5 NOTE: To send a message from Bitnet to Dialcom use the following procedure: At the To: prompt, enter INTERMAIL@ISI.EDU After you have entered the subject and before the text of the messaege leave a BLANK LINE, then on a new line enter: FORWARD: NSF-MAIL TO: 42:CDT0001 (OR THE ID OF THE MAIL RECIPIENT) Leave an additional blank line, then enter the text of the message indented one space and send as usual. ************************************************************************* * CSNET Merger Discussions * *************************************************************************** from Various Listserv Lists * I attended a pretty interesting session about BITNET yesterday. it was presented mostly by Michael D'amore the BITNIC director at Educom. According to him: 1. There is a good chance that BITNET and CSNET will merge. The management may merge before the year ends. Physically merging the two networks will take much longer. There are some technical and policy difficulties in the merger. CSNET is basically a star network with nodes periodically calling up on the phone to collect their mail (and files?). BITNET lines are always (almost always) connected and the network isnt a star. CSNET also charges on a per-piece basis, but BITNET is free except for the dues and line charges. almost all the csnet users are faculty. It's my guess that right now more students than faculty use bitnet. 2. BITNET is moving away from RSCS towards a "TCP/IP backbone". This will either cause technical problems or screw smaller installations who can't afford TCP/IP hardware and software. It will finally give bitnet users access to FTP transfer as well as mail. * It seems logical to me that our two networks could start to merge very quickly and (probably) totally painlessly. A first start could be made by establishing one or more stable gateways between the networks. From there, TCP/IP and protocols could spread outwards through Bitnet with more, low- level gateways as the new order took hold, until we became one, big, happy network. An additional thought, what would you all think about having two 'logical' domains on this new network? These would probably not be physically 1 Page 6 separate domains, but could be domains for CS departments (from the old CSNet and the old Bitnet) and a GENeral domain (for computer centers and other sites from Bitnet). * I have concerns of the potential merger. Besides the technical questions, there is a lot of philosphical differences. Most Computer Science departments have a hard time in accepting computing for other departments. Bitnet has been billed as educational networking for the entire campus. Unless there is some method for insuring that CSnet sites are treated only as another node (yes node) at an institution, I have a great deal of trouble, and will reccomend voting against any such merger. I also find it difficult to believe that even a merger of the boards could happen without a vote of the BIRREPs. That is drastically changing the makeup of the bylaws of Bitnet, Inc. Such a merger will also not automatically get a technical NIC.(CIC) The budget for Bitnet was voted on by the board. They set a low budget to keep the fees low. It doesn't take a merger to get a technical NIC. it takes $$$. A merger without increasing fees may mean that CSnet users will lose a technical CIC, and have a NIC. I also think many people are being unfairly critical of the NIC. They have people pulling them all which way. They are not perfect, but neither is anyone else. I have seen improvements, but it must be hard for them to be motivated, because no on the net every say a good word about them when they do something right. I am also not convinced of the merits of converting to a TCP/IP network. Much of the growth of Bitnet recently has been in the smaller school environment. Money is a bigger issue to them. Is it ethical to get them signed up now, take their money and get them interested, and then pull the rug out by changing the protocol, forcing new purchases of software and/or hardware? Bitnet is growing because it is easy to join and become active. Do we really want to stifle that? As a growing network, it is running into many problems, but let's not forget what got us here. * I am not directly involved in any of these decisions, but I agree with what XXXXX says. Obviously, we get what (or thereabouts) we pay for. If we decide that it is worth our money to keep up a technically oriented NIC/CIC, we will probably pay for one. Of course, this brings us to one of Harry's other points... I can't say that we are such a small school or hard-up for money here (because I don't know the big picture, and the small picture looks pretty good), but if the whole network were to migrate to T1 links and new hardware, I'm sure our administration would have some serious doubts. On the other hand, with upward migration of computer equipment all around us 1 Page 7 (including smaller schools, I think) is new equipment going to be that much of an imposition? I'd say it would be part of a natural, upward migration in computer and networking power. * Your concerns are absolutely reasonable and I believe must be fully addressed by any merger plan with hopes to succeed. Let me respond to a number of them from my personal point of view: 1. Definate philosophical differences exist between CS departments and their institutions at many schools. Both side are concerned that they not lose in any merger. But a network, after all, delivers a prescribed set of services. If Bitnet's current services were augmented by remote login, the two network's services would be conformable. We need to anticipate possible consequential capacity problems but that is a manageable exercise. Regarding capacity, we would also need to see that CSNET demand would not overwhelm BITNET capacity. Again an issue, but one that can be managed. I would see CS departments as just another node at an institution, but CS (and/or other science and engineering departments) would be represented on any governing board along with "institutional representatives." 2. Legally a merger could take place without a vote of the Bitnet IRs. To do so without a public announcement/debate would be strongly counter to the spirit of BITNET; whether an actual BIR vote would be appropriate would depend in my mind on how controversial an eventual plan might turn out to be. It is plausible to me that a plan could be advanced that would be clearly appropriate and the BITNET board might therefore act accordingly. Regarding the noted possibility that the boards might merge as early as the end of this year - that is logically possible, but there is much work to be done. It would not be appropriate in my mind to merge the boards until a blueprint for the result has been prepared, distributed and discussed. After consideration, in other words, it becomes obvious that a merger of the boards could not be achieved in so short a time. 3. Agree a merger would not in and of itself do anything but possibly confuse the NIC issues. This needs to be addressed in a merger plan. 4. I do not expect that BITNET would have to "convert to TCP/IP." It is obvious to me that BITNET must use better technology than plain RSCS, however, and TCP/IP as a backbone protocol and/or between "consenting nodes" could address two critical technical issues: the proliferation of nodes in a raw RSCS network (the TCP/IP backbone would presumably take advantage of domain addressing), and dynamic routing and re-routing for a network that would have redundant links. In my opinion any acceptable merger plan must recognize the value to BITNET and of BITNET to the "smaller institutions" (read non-CSnet institutions). It would be unethical to require anyone to convert from RSCS unless and until reasonable alternative tools were available, and even then only after a reasonable period of time to allow migration. I do not believe a merger would require any conversion from RSCS in the near term (two years? even longer?). 1 Page 8 It seems obvious to me that for such a merger to succeed it is incumbent on the two Boards to develop a proposal, to publish it and allow for community comment and improvement, and only then to determine an appropriate decision strategy. To date, a joint committee of the two boards has found a merger to be feasible and is doing further investigation which is why nothing has been published yet. Given what I know to date I believe a merger is conceptually in BITNET's interest and that the details can be worked out to our mutual satisfaction. I expect we will discuss this subject at the next BITNET board meeting, on Oct. 26th in Los Angeles (just prior to EDUCOM - meeting just set, a BIR announcement should be sent out shortly). * BITNET is basically an IBM network. Computer Science departments tend not to be IBM shops. That is the single bigest difference between CSNet and BITNET. Because of the "normal" problems associated with IBM interactive computing (if you don't look mean and green I won't talk to you), CS departments have tended to be DEC departments. Similarly, CS department tend to believe that computing is something that should be there and that they should be allowed to use it and not have to fight with payroll or accounts payable for CPU cycles. Around here our Computer and Information Science Department not only has more machines and more CPU power than any other University dept, but they also have more $$ invested in computing than anybody else, including the 3091 shop in the School of Arts and Sciences. Computer Science Departments tend to have been using networks and networking, especially electronic mail, for much longer than the rest of the world. Consequently, they tend not to have time for those who can't talk to the ARPAnet. As BITNET was created to link together several IBM computers, CSnet was created to like together those who didn't have ARPA contracts, but wish they did. (Please realize that all of the above are gross generalizations, but based in truth.) The CIC is a technical NIC. It is not a sales force. As such the CIC is more expensive to operate than BITNIC. But the board, even spending the same number of dollars, would be buying DIFFERENT services from the CIC than they are buying from EDUCOM. For one thing the CIC (BBN) has the technical capabilities in place, EDUCOM would have to go out and hire them. Many of BITNIC's problems are communications. Those of us who use the net are not those who the NIC talks to. The NIC talks to the board who they work for. Us grunts here in the trenches don't hear about anything they do right. We only see what the problems are. Again, going back to my first statement. TCP/IP is a major issue because IBM didn't support it. Now they do, but it costs dollars. TCP/IP is not an issue for NON IBM sites, it is FREE for any UNIX site and $6k list for any 1 Page 9 VMS site. Since we were able to negoitate a large discount with Wollongong, I assume that EDUCOM could do the same, possibly even larger because there are potentially more sales. TCP/IP itself is obviously only an interum solution. Longer range, the solution will be OSI, but that doesn't exist yet. * Ah, but you forget who the CSnet CIC is - BBN! (Bolt Beranek and Newman) The top communications consultants in the country? world? I think that you will find that they have the "corporate" expertise necessary as well as the necessary corporate contacts with IBM to "solve" the problems. I'm not implying that it will be easy or that it will happen transparently. I also don't think that it will happen overnight. I think, however, that one of the major benefits will be that those sites who are presently living in both worlds will not only have their lives made easier, but be able to make the lives of the rest easier. Given such things as adaptive routing, it would make far more sense to take a message bound for someplace in California from New Jersey on BITNET through a gateway bounce it off a NSFnet satellite, and back through another gateway in CA, than to try to pass it through 20 nodes with 9600 baud land lines. The trick will be "imagination" I don't think that any single existing answer will solve the problems that ALL the networks face today. Too much traffic for too little bandwith. Forget about cost, it's all expensive, the question is really are you (whoever you is defined to be) willing to foot the bill for something that will beat the Russians to the moon, or are you going to try to put all your eggs in one basket and wind up giving everything to ERISA. Somebody wanted a non-political solution. Well the answer is either political, ie, everybody (taxes) pays, or capitalistic - you get what you pay for. I doubt that the majority of BITNET members would be members if they didn't have a political side. After all how many users out there want to use BITNET because DIAL-UP costs $$$$$$ for equilivant service. I'm not talking about sites here, but the acutal end users. Lets face facts, ALL computer networks are used to beat either the Phone Bill or the Postage meter. It is a sad fact of life, but true. There are very few users, who MUST use BITNET for what they do. Should BITNET, or NSFnet or ARPAnet even exist? Those who opt for the "pure capitalism" should be using Tymenet or Telenet, or some other PDN, rather than trying to circumvent them via tax- exempt educational entities. (If BITNET is paying taxes, then somebody is really off their rocker.) * Changing the way BITNET does business by integrating it with TCP/IP or converting to XYZZY simply can't happen overnight. But if a stone tablet is handed down stating that thou shalt do thus and so, that's an administrative solution, not a technical one. 1 Page 10 I don't have any hard facts to quote, I'm just working on some assorted conversations and superimposing what I would do on top of them. So with a little bit of imagination and some pixie dust, I propose the following "administrative activities": Playing games like adaptive routing or simply changing the topology and the type of comm lines is probably something which could be done "immediately". (How long does it take to get a T1 line and some modems?) (How often is the LINKS file distributed?) Maybe even code to recognize RFC822 addresses could be whipped up in sort order and packaged as a "standard" mail interface that all BITNET sites running all kinds of operating systems could install PAINLESSLY (or at least shipped with a sufficient dose of novacane). All you have to do is find out what the sites are running which process RFC822 address, and then find out WHY the other sites don't run that code, fix it and send it out. Simple enough? (I think the wheel was already invented, you just have to tell people about it, recompile it, and maybe write some documentation.) Again except for the gateway, anything else will probably take 6 months to a year to design and implement, let alone debug. But then they are not really "technical problems", merely administrative details. The "programming" has been done - all that's left is the "coding". "Administrative" solutions are the only type which can be implemented in a relatively short time, simply because the solutions are NOT technical, per se. "Technical" to me implies a truly unsolved problem requiring original creative thinking not merely "engineering" or even "reverse engineering". Hopper knows, there are enough of those out there to deal with without forcing ourselves to re-solve solved problems. It is always interesting to see how many solutions we forget in a short time, because they are not "perfect" or "elegant". Want to use the NSFnet backbone to move BITNET traffic... Just pump your EBCDIC message (file) through a "quoter", package it into a bunch of datagrams, bounce it off a satellite, "un quote" it and ship it back out. The hop becomes "invisible" to BITNET, even though it happens to run via some wierd network and protocol to get from point A to point B. Sounds like an implementation of KERMIT to me. All you need is some CPU cycles... maybe we could get a black box with some hot chip in it to act as the CPU for the quoting and unquoting and packaging... hmm, sounds like we could call it an Input Message Processor on one end and Incoming Message Processor on the other, or IMP for short. The problem was solved once, just fix it. (I know imps don't exist, but then again, niether do demons, but the framework is there.) 1 Page 11 I don't say that any of this would be easy, I just don't think that any of the above items requires much "thought", they are all implementation problems which merely require a COMMITTMENT to acomplish. Once the boss says "rewrite the mailer" then we can fight over doing it in COBOL or FORTRAN, unless he says "rewrite the mailer in AUTOCODER", then we can tell him he's nuts and go look for other jobs. ************************************************************************* * Network Audio Bits: A New Electronic Magaine * *************************************************************************** by Michael A. Murphy MURPH@MAINE Network AAA U U DDDD IIIII OOO A A U U D D I O O AAAAA U U D D I O O A A U U D D I O O A A UUU DDDD IIIII OOO BBBB IIIII TTTTT SSS B B I T S BBBB I T SSS B B I T S BBBB IIIII T SSS & Audio Software Review Network Audio Bits & Audio Software Review is an electronic audio magazine devoted primarily to Compact Disc and Vinyl LP Record reviews. All forms of music will be represented. So far reviews have covered mostly Rock & Roll, Folk, R&B and Pop music. I hope to expand the styles covered to include some Jazz music as well and hopefully someone out there will feel inclined to contribute some classical reviews. * Subscription Information Subscriptions to Network Audio Bits & Audio Software Review are available by sending your name and network address to MURPH@MAINE.BITNET. Upon receipt of your mail, you will be added to the subscription list and will have N-Audio Bits sent to you starting with the next issue. New issues have been coming out at the rate of about 1 every 6 weeks. I hope to buckle down soon and make this a monthly magazine. Should you lose your network access or have a change of network address, please send mail to have your subscription address changed or deleted. 1 Page 12 * Back Issues Back issues of N-Audio Bits are available from the CSNEWS file server at the University of Maine (CSNEWS@MAINE.BITNET). To receive a copy of a back issue from CSNEWS you must send an interactive message to CSNEWS and issue the command: SENDME N-AUDIO BITSxxxx FROM EMAGS where 'xxxx' is a 4-digit issue number. The entire issue number must be specified, i.e. N-AUDIO BITS0003. If you are not able to request back issues from CSNEWS or if you have problems requesting them from CSNEWS, then send a mail file to me, MURPH@MAINE.BITNET and I can send you copies of the back issues you desire. * Submission/Review Policies If you are interested in reviewing either audio hardware or software, feel free to discuss the details of reviews with the editor. It would probably be best to query the editor to make sure that the item you wish to review is acceptable. Reviewers are encouraged to cover any and all types of music. I would like to keep hardware reviews to a minimum, perhaps one or two reviews per issue, as I would like to focus on audio software and especially Compact Discs. * Review Guidelines What I look for in a review is writing that shows that you have not only heard the album, Compact Disc or cassette which you are reviewing, but that you have also listened to it. In the case of LPs and Cassettes, I'd like to keep to recent releases for reviews. For CDs, almost any review is welcome, as anything that is out on CD is a fairly recent release and I'm interested in representing as many CDs as possible in these 'pages'. Here's what I'd like as a general format for reviews. All of the information concerning the Disc or LP should be able to be found on the album where all credits are given. The performance and sound quality scales are your opinions. REVIEW FORMAT Title Artist Producer(s) Engineer(s) Label/Catalog # Playing Time Song Titles Performance scale (1-10) Sound scale (1-10) 1 Page 13 What format was reviewed (CD, LP, Cassette) Release date SPARS code (For CDs - will explain below) The SPARS code represents a standard proposed by the Society of Professional Audio Recording Studios (SPARS). Many CDs have this three letter code printed somewhere on their information booklets. The three letters correspond to the type of recorder used for recording, mixing and mastering of the disc (analog or digital). For example, a disc with the code "ADD" would show that the disc was an analog recording, mixed and mastered digitally. ************************************************************************* * DIRECT@QZCOM * *************************************************************************** by Jacob Palme JPALME@QZCOM A remote mail directory service is now available at QZCOM.BITNET. The service allows you to send ordinary mail messages to QZCOM.BITNET, with commands in the message text, to: --> Search for the names of users and conferences (=distribution lists) in QZCOM. --> Find description and other information about users and conferences. --> Add and remove yourself from conferences in QZCOM. When you add yourself to a conference, messages entered into that conference will be sent by electronic mail to your mailbox. --> Retrieve certain files with help information. * Where to send messages Send your messages, containing directory commands, to DIRECT@QZCOM (for the English language COM system at QZ) or to DIRECT@QZKOM (for the Swedish language KOM system at QZ). Directory requests are normally handled at nighttime, and responses returned the next day by electronic mail to the sender of the request. * Searching for names of users and conferences This service allows you to search for the network mail names of users and conferences. You can input a name pattern, and all names matching the pattern will be found. 1 Page 14 Command syntax: DESCRIBE ( NAME ) where can be a name or part of a name according to the RFC822 syntax for address, for example "Jacob Palme" "Jacob Palme" SIMULA_Forum SIMULA_Forum@QZCOM.BITNET Examples: To find all QZCOM users with the name "Smith", send the command: DESCRIBE ("Smith" NAME) To find all QZCOM conferences about RARE, send the command: DESCRIBE ("RARE" NAME) To find if there is any QZCOM conference about the SIMULA programming language, send the command: DESCRIBE ("SIMULA" NAME) The difference between upper and lower case characters is not significant in directory commands. * Finding out more information about a user or conference This service allows you to find out more information about a particular user or conference. This service will only be provided if the matches one single user or conference. Command syntax: DESCRIBE ( ÕNAMEå ÕDESCRIPTIONå ÕCHARGINGå ÕMODERATORå) NAME returns the full network name of the user or conference, DESCRIPTION returns a textual description, including postal address, telephone number and latest access information, CHARGING returns information about costs, MODERATOR returns the name of the person who manages the conference. Examples: To find information about the QZCOM conference "RARE Directories", which has the network name , send any of the following commands: 1 Page 15 DESCRIBE ("RARE Directories" NAME DESCRIPTION CHARGING MODERATOR) DESCRIBE (RARE_Directories NAME DESCRIPTION CHARGING MODERATOR) DESCRIBE (RAREDIR NAME DESCRIPTION CHARGING MODERATOR) DESCRIBE (RAREDIR@QZCOM.BITNET NAME DESCRIPTION CHARGING MODERATOR) To find information about the QZCOM user "Jacob Palme QZ", who has the network name , send any of the the following commands: DESCRIBE ("Jacob Palme QZ" NAME DESCRIPTION CHARGING MODERATOR) DESCRIBE (Jacob_Palme_QZ NAME DESCRIPTION CHARGING MODERATOR) DESCRIBE (JPALME NAME DESCRIPTION CHARGING MODERATOR) DESCRIBE (JPALME@QZCOM.BITNET NAME DESCRIPTION CHARGING MODERATOR) * Adding and removing yourself from a QZCOM conference Command syntax: ADD ( * REC Õå ) to add yourself to the conference, and get also the N latest previously sent messages from the conference. The number is approximate, you may get less than N messages. After ADD, all new messages in the conference will automatically be sent to your mailbox until you perform a DELETE command: DELETE ( * REC ) to delete yourself from the conference. Where the syntax for is the same as for above, and is an unsigned integer. Restrictions: You can only add yourself automatically to open (public) conferences. If you want to become member of closed conferences, write a message to INFO@QZCOM.BITNET. Examples: To add yourself to the QZCOM conference "ByteCOM news", send the command: ADD ("ByteCOM news" * REC) To add yourself to the QZCOM conference "Prolog and Logic programming", and ask for not only future messages in the conference to be sent to you, but also the 10 latest earlier messages to be sent to you, send the command: ADD ("Prolog and logic programming" * REC 10) 1 Page 16 To remove yourself from the QZCOM conference "Speakers corner", send the command: DELETE ("Speakers corner" * REC) * Charging THERE IS A CHARGE for subscribing to conferences in QZCOM and having them sent to you. The charge is at present (September 1987) approximately 8 SEK per 1000 characters. Universities get about 50 % reduction, and messages within the Nordic countries get about 50 % reduction on this charge. If you send a mail with the command DESCRIBE (* CHARGING) you will get more information about charging. You will also be told if you have an account, and if not, you will by electronic mail get a form, which you have to fill in, sign, and send in by postal mail to get the account. You can use the directory service, and send mail to QZCOM users and conferences, even though you do not have any account. * AMIGO information AMIGO is a joint European project to develop better methods for distributed group communication. For more information about AMIGO, write to SANTO@GUS1.GMD.DBP.DE. AMIGO has developed a standard for accessing directory systems in other systems. This standard provides a standardized format for both requests and responses, so that the responses can be handled automatically by those who so wish. The commands described above are a subset of the AMIGO directory service with a few extensions. Users on BITNET can request the full description of the AMIGO directory protocols from "Jacob Palme QZ" . ----- ---- ---- ----- ---- ---- ---- ------- ------ ------ -------- ----- ------- ------- ------ ----- ------- --------- --- ------- -------- ------- -------- ------- --------- --------- ---------- -------- --------- --------- ---------- --------- -------------- --------- ------------ ------------ ----------- --------- --------------- --------------------------------------------------------------------------- 1 Page 17 ************************************************************************* * Summer Brings Changes to Comserve * *************************************************************************** by Timpthy Stephen SUPPORT@RPICICGE Major changes have been made to COMSERVE@RPICICGE in the following areas: Newsline -- A new method for receiving Comserve's news bulletins automatically. Hotlines -- A change of name and emphasis in the discussion system with the addition of many new topics. MultiAdd -- A new command (available through mail only) that allows easy processing of multiple Addme commands. User's Guide -- Second edition is now available. EasyCom -- New version (1.6) of EasyCom Exec; Vax EasyCom Com version (1.5) now available. CallMe -- A new command that personalizes Comserve's responses to your messages. New Address -- The new address for contacting Comserve's staff is Support@Rpicicge. ***** * Newsline: "Home Delivery" of Comserve's News Bulletins After a new issue of the news bulletin is installed in Comserve, it is normally sent to you only when you next send a command to Comserve. This has meant that users who don't send commands regularly have missed editions of the news. A new service called "Newsline" has been created that provides a way for you to subscribe to the news. If you subscribe to Newsline, you will be sent new issues of the news bulletins regardless of whether you send commands to Comserve. Use the Join command to subscribe to Newsline: Join Newsline Your Name Use the DropOut command if you wish to cancel your subscription: DropOut Newsline Take advantage of Newsline to keep abreast of information about new files that have been added to the database and new developments in the Comserve system. 1 Page 18 * Hotlines: Expanded Discussion System Takes New Emphasis What was previously known as Comserve's "Discussion" system is now being referred to as Comserve's "Hotline" system. The change of name signals a new emphasis for this system. Hotlines are intended as methods for consulting with experts in various aspects of human communication theory and research. Comserve is now managing a large number of Hotlines representing diverse areas of research and scholarhip in human communication studies. These include: PhilComm -- Philosophy of communication MassComm -- Mass communication and new technologies Interper -- Interpersonal and small group communication HealthCo -- Communication in the health profession Methods -- Research methodology CommEd -- Communication education OrgComm -- Communication in organizational settings PolComm -- Political communication Gender -- Communication and gender CommDis -- Speech disorders Rhetoric -- Rhetoric, rhetorical analysis, social movements, persuasion InterCul -- Cross-cultural communication Ethno -- Ethnomethodology and conversation analysis PhilComm -- Philosophy of communication Join one or more of these Hotlines -> if you are a professional and would be willing to share your expertise with others -> if you are seeking information about human communication -> if you are curious and want to learn more Finding Out What Hotlines Exist You can find out what Hotlines are available using the Show command. The command: Show Hotlines will cause Comserve to send you a description of available Hotlines as electronic mail. Joining Hotlines 1 Page 19 You can enroll in a Hotline using the Join command. The syntax for this command is: Join Hotline_name Your name For example: Join PolComm George H. Mead When you issue the Join command, you will be informed by Comserve that your request to join a Hotline has been forwarded to Comserve's editors. You will be informed by electronic mail when your request has been processed (usually within 24 hours). Once it has been processed, you will begin to receive copies of all the messages that others send to the Hotline and the mail that you send to the Hotline will be sent to all of the other subscribers as well. The rate of message traffic on different Hotlines will vary. After you join a Hotline, you can send mail to the Hotline by addressing it to: Hotline_Name@Rpicicge For example: PolComm@Rpicicge Norms For Interacting in Hotlines Interaction in network Hotlines has its own style. In face to face discussion, people may feel obligated to keep conversation flowing since long silences can be uncomfortable. However, Comserve's Hotlines are in continuous operation (whether or not subscribers happen to be using their computers) and subscribers usually do not feel compelled to contribute to fill silences. Some Hotlines may show little or no activity for several months and then become quite active as a result of a question or opinion that has been sent. Without face to face contact and usually with no knowledge of who most of the other subscribers are, interaction in Hotlines will tend to be directed almost exclusively toward task or informational purposes. Therefore you should view joining a Hotline as a convenient way to access a large number of resource people, to serve as a consultant to others, or to "tune in" to the types of issues that are of concern to others. Normally this is not an activity that will create social demands. Leaving Hotlines If you ever wish to cancel your subscription (and you should do so if you are about to change your BITNET address or close your computer account), use the Dropout command. The syntax of the dropout command is: Dropout Hotline_Name 1 Page 20 For example: Dropout PhilComm * MultiAdd: New Command Makes Multiple White Pages Entries Easier MultiAdd is a new command (available only through electronic mail) that provides an alternative to the Addme command. MultiAdd allows you to include an entire set of entries at once by sending them in the body of an electronic mail message. To use the MultiAdd command, prepare an electronic mail message addressed to Comserve. The first line of the body of the mail message should read: MultiAdd Include as many additional lines of name and interest information as you wish. As in the Addme command, name information is limited to 25 characters and interest information is limited to 34 characters -- anything longer will be trimmed. Separate name information from interest information using a semi-colon. Here is an example of a mail file containing seven entries for the white pages: DATE: June 2, 1987 10:22 EDT FROM: "Cheryl Jackson" TO: Comserve@Rpicicge MultiAdd Cheryl Jackson ;Rhetorical theory Cheryl Ann Jackson ;Social movements, persuasion ;political rhetoric ;Dept. of Communication & Rhetoric ;Blackstone College ;Blackstone, Maine 12345 ;(617) 123-1234 Please note that spacing is not important -- only the correct placement of the semi-colon matters. Once processed, this would result in the following additions to the white pages: USERF99K MAINE Cheryl Jackson Rhetorical theory USERF99K MAINE Cheryl Ann Jackson Social movements, persuasion USERF99K MAINE political rhetoric USERF99K MAINE Dept. of Communication & Rhetoric USERF99K MAINE Blackstone College USERF99K MAINE Blackstone, Maine 12345 USERF99K MAINE (617) 123-1234 1 Page 21 Notice that Comserve will automatically add the network address information. * User's Guide Revision Completed A new version of Comserve User's Guide is now available. The Guide has been through a major reorganization and has been expanded to almost double the size of the previous version. The appearance of the guide has also been enhanced through use of multiple fonts and type sizes available on RPI's Xerox 8700 laser printer. The new guide is organized into two major sections. The first, "BASICS," describes information of particular value to those who are new to Bitnet or computers. It discusses computer networks, how to communicate on them, and general information about Comserve. The second, "DETAILS," presents Comserve's functions and commands in detail. It addition, it describes how to include your own materials in Comserve's database, introduces you to the EasyCom program, and contains a troubleshooting section that answers questions about Comserve. A final section describes how you can use Comserve to build community and enhance communication and resource sharing within a particular audience or interest group. The portion of the DETAILS section that presents command descriptions includes information on many commands added since the last revision of Comserve User's Guide (November, 1986) and groups descriptions of commands according to which of Comserve's major functions (database, white pages, recreation, hotline system) they pertain to. As always, copies of Comserve User's Guide are free. If you would like to receive a copy, send a request containing your normal (i.e., non-Bitnet) mailing address to Support@Rpicicge. Users who have received previous versions of the Guide are encouraged to up-date to the new one. With the expansion of Comserve's commands and the increased size of the Guide, the on-line version of the Guide (Comserve UserGuid) has been taken out of circulation. The guide is now only available in hard-copy format by request to Support@Rpicicge. * EasyCom Enhanced, Up-Dated; New Vax Version Available The EasyCom program (available from Comserve) has recently been acknowledged as one of the best programs of its kind. It has now been enhanced for compatibility with Comserve's new commands and a new version for Vax computers is available. Once received from Comserve, you can run the EasyCom program on your local machine and it will simplify communication with Comserve. EasyCom 1 Page 22 presents you with English-language menus that describe Comserve's functions. When you select an option, EasyCom will prompt you for any necessary additional information, checking to be sure that it has been supplied correctly, and will communicate your commands to Comserve. It then pauses while waiting for Comserve's response to arrive. Two versions of EasyCom are now available -- one for IBM VM/SP (CMS) computer systems that have the Rexx language available (most do) and one for DEC VAX or MICROVAX computer systems that use the VMS operating system (version 4.4 or higher) and communicate on Bitnet via the JNET software package (most Bitnet VAX computers are configured this way). The IBM version is available from Comserve as a file named EasyCom Exec and the DEC version is available as a file named EasyCom Com. The IBM version (version 1.6) is fully compatible with all of Comserve's current functions and commands. The DEC version is one step behind at release level 1.5 (it does not provide access to the Callme command (see below) and still refers to Comserve's Hotline system as the Discussion/Forum system). We hope to provide a 1.6 level of EasyCom Com in the near future. * Getting Personal With Comserve: The Callme Command A new command, Callme, has been added to Comserve. This command gives you a way to control how Comserve will address you when it sends responses to your commands -- particularly those sent in electronic mail. You can use the Callme command to personalize response messages. The simplest version of this command is simply Callme followed by a name. For example: Callme Dr_Bateson Note that names cannot be longer than 15 characters and the components of multi-part names such as "Dr Bateson" or "Karen Blackwell" must be joined together. An underscore character "_" works fairly well to do this, but you can use any character. Thus, "Dr Bateson" should be specified as "Dr_Bateson" (without the quotation marks) and "Karen Blackwell" should be specified as "Karen_Blackwell" (again, without quotation marks). You can also instruct Comserve to stop personalizing your messages using the "Reset" option of the Callme command. For example: CallMe Reset If you wish, you can instruct Comserve to determine for itself a name to use in addressing you. This is accomplished with the special "Anything" option. For example: CallMe Anything 1 Page 23 Finally, you can ask Comserve to choose only a gender-appropriate name by adding your sex after the "Anything" option. For example: CallMe Anything Male or CallMe Anything Female * New Bitnet Address for the Editorial Staff The Bitnet address for Comserve's editorial staff changed on July 10th from Comsprt1@Rpicicge to Support@Rpicicge. We hope that this will make it easier for newcomers to Comserve to successfully contact the staff. The '1' in the old address was occasionally mistaken for the letter 'l' and the letter 'o' for the number zero. Mail to Comsprt1@Rpicicge will continue to be delivered throughout the coming year but our new official address is Support@Rpicicge. * Usership Grows Comserve has now processed more than 30,000 commands sent by 1,900 users representing five networks and 14 countries. More than 11,600 files have been delivered. Shouldn't your materials be available on Comserve? Submit materials to: Support@Rpicicge ************************************************************************* * NAMESERV@UNCAMULT * *************************************************************************** by Rom Kieffer KEIFFER@UNCAMULT NAMESERV was designed to permit userid and full name look-up from remote sites via mail messages. It can handle up to three request lines per message and scans for the first recognizable request line in the text (ignoring spurious header lines). The UNCAMULT name server will process up to three lines of a network mail message addressed to NAMESERV@UNCAMULT as requests for information. Valid requests are: * DISPLAY_PERSONID surname1 surname2 ... * DSPI surname1 surname2 ... 1 Page 24 The resulting mail message will contain the mail addresses for all users by the name of surname1, surname2,.... * DISPLAY_FULL_NAME personid1 personid2 ... * DSFN personid1 personid2 ... The resulting mail message will contain the complete name for personid1, personid2,... The 'personid' is the unique user registration identifier used for the delivery of network mail. * HELP Sends a command summary. ************************************************************************* * Feedback * *************************************************************************** Date: Mon, 07 Sep 87 17:27:15 +0300 From: Dan Littauer Subject: NyShare We have gotten a few compliants from EARNET because of large files that were sent from WEIZMANN. I checked on the SHARE log and the RSCS log and found out that these files were ordered from NYSHARE@WEIZMANN (the server). If it is possible could you post that a continued misuse of the server will cause for its immediate shutdown to outside hosts, that is only Weizmann hosts. Best Regards, Dan ************************************************************************* * 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 25 If you cannot send messages in this way, you can send the following command as the first line of a mail file to LISTSERV@MARIST: SUBSCRIBE NETMONTH Your_full_name Arpanet users may use this method, but must address the mail to: LISTSERV%MARIST.BITNET@WISCVM.WISC.EDU A subscriber can delete him/herself from the mailing list by sending LISTSERV@MARIST the UNSUBSCRIBE NETMONTH command. * Letters to the Editor: If you have questions or comments about BITNET or NetMonth that you would like printed here, mail your l etter to BITLIB@YALEVM. Make sure that you specify in the "Subject:" header or somewhere in the letter that it is for the NetMonth letters column. This doesn't mean that your letter will be printed, but it helps. * Article Submissions: The only requirements for NetMonth articles are that they be informative, interesting, and deal with BITNET services (or any other good BITNET related topics). The editor will inform you of any changes to your writing and will submit them for your approval, deadlines permitting. Send your articles to BITLIB@YALEVM. * Printing this file: VM users can print this file by first copying it to NETMONTH LISTING and then printing the new file. This will allow page- breaks and other formatting to be understood by your printer. --------------------------------------------------------------------------- A publication of the Bitnet Services Library "Because We're Here."