* * * * * ** * ** ** * * * * * * * * * * * * * * * *** ***** * * * *** **** ***** **** * * * * * * * * * * * * * * * * * * ***** * * * * * * * * * * * ** * * * * * * * * * * * * * **** * * * *** * * * * * * * * A monthly guide to BITNET servers and services * ******************************************************* Volume 1 Number 2 - August 1986 Editor: Chris Condon BITLIB@YALEVMX * Contents * Bitnotes ............................................ 1 Instant Insanity by Jeff Kell ....................... 3 Relay Growth ........................................ 6 New Mailing Lists ................................... 7 The VAX Toolbox ..................................... 7 /Links .............................................. 8 The NETSERV User Directory Services ................. 8 New List Servers ................................... 10 Spotlight Server: UTCSERVE@UTCVM ................... 12 Feedback ........................................... 13 Policies ........................................... 14 __________________________________________ / /[ /__________________________________________[/ ] ] ___________________________________ ] ] ] /[ ] ] ]_______________________________[/ ] ] / ] ]/__________________________________ ] /[ ]__________________________________________[/ A complete list of servers and services is available from any NETSERV file server as the file named BITNET SERVERS. News, article submissions, additions to the list of servers and services, subscription requests and letters to the editor should be sent to BITLIB@YALEVMX. Subscribers are also sent BITNET SERVERS updates. Printing this file: VM users can print this magazine by first copying or renaming it to NETMONTH LISTING and then printing it with your local file printing command. ------------------------------------------------------- FuzzyBytes Electronic Publishing "Because We're Here." 1 Page 1 ************************************************************************* * Bitnotes Issue 2 * *************************************************************************** "Never underestimate the power of human stupiditiy." - Robert A. Heinlein Ignorance is bliss, or so they say. That may not be applicable to BITNET, for here ignorance usually spells Trouble (yes, with a capital 'T'). Ignorance may be as harmless as not knowing how to use a file server or as harmful as requesting 125 files from a file server within the course of three minutes. Certainly, this is not bliss. Not for the poor guy who doesn't know what is going on, or for the person wondering why it is taking so long for those 125 files to arrive. Discipline begins at home, or so they say. Likewise, education on how to use BITNET servers and services begins at the home node. I have gotten some mail about this, requests for tips and information. And while I am not a node administrator by any means, I might be able to get away with listing these suggestions. 1. When in doubt, don't. Allegedly common sense will tell you it will require a lot more effort to fix something you have done wrong than it will to do it right in the first place. If you don't understand how to use a server or service, ask somebody who does, or refer to the local documentation. Which leads to: 2. Keep documetation on how to use the servers and services at your node. Keep it in a really obvious place too, and update it frequently. One helpfile about CSNEWS on a public disk is a lot safer than ten users with copies of their own (and a lot more efficient to boot!). Store some explanations on what each type of server does (i.e What is a file server? What does it do? How do you use it?) You might even go as far as printing a local BITNET users guide (although it would have to be pretty general with the way things change). 3. Have a BITNET user consultant at your node. There is not much sense in the blind leading the blind, so this is particularly helpful. You might want to make this person responsible for keeping the documentation updated. 4. Develop some usage guidelines, and stick to them. Yes, there may be some bad apples at your node. Have some sort of policy to deal with these people. On the other hand, some people just don't know any better, so post some guidelines on what is acceptable and what isn't. You'd be surprised what some may do unless you tell them they shouldn't. I think (my opinion only) that a policy that deals with individual abuses will have a greater affect on those-who-would-be-bad. 1 Page 2 Fine. Those are all wonderful suggestions on how to prevent yourelf and others from doing something wrong. A more positive approach might be to list some things you can do RIGHT. From this end of the picture it seems that one of the rightest things you can do is offer services to the BITNET community. This doesn't mean that you have to run a file server or produce an electronic magazine. Perhaps you don't have the time or resources for that sort of thing. That doesn't mean you can't do something with a slightly lower profile. Some suggestions for students and administrators alike: 1. Form a local BITNET user's group. It doesn't have to be large to be effective (although it probobly helps). Not only can you promote the responsible use of the network, it makes good resume material, too! 2. Write an article for one of the electronic magazines. You must have some thoughts about what is happening in BITNET. If ONE user at each node wrote ONE article in ONE year there would be enough material to make the monthlies go weekly. Why not be that one and give it a try? For those of you who might want to take on the responsibilbity of offering a full scale service, like a file server or mailing list, here are some considerations to take into account before you get in too deep. Try to approach it as if you were running a business, where your service is the product that you want to sell: 1. Is there a need for this service? Example: If Joe Dokes is already running a file server for people who are interested in Chemistry, is there a need for a second one? Or maybe there is a server like that but you think you could do a better job. 2. Are there enough people interested in what you want to do? Example: If you want to run a mailing list for people concerned about the social implications of knitting, make sure there are enough people interested in that sort of thing. 3. Do you have the resources to produce this service? Remeber, time is your most valuable resource. Do you have enough of it? If you want to produce a weekly electronic magazine, do you think you can really put one out regularly? Or will you slack off after three weeks? And what will happen to the magazine when you leave the network? 4. Does your SYSTEM have the resources to produce this service? If your system has a lot of people using mega-cpu maybe running a file server there isn't such a good idea. 1 Page 3 In this issue we have, to put it lightly, a lot of good stuff. First off, we have an article written by the author of Relay, Jeff Kell. It sheds some light on the directions Relay is taking, as well as answering some prickly and not-so-pricky questions. As a companion to that, I drew up a chart showing the Relay growth in the past year... DON'T PANIC! I have included a lot of non-Relay articles, too. There are plenty of new mailing lists, list servers, and user databases. In addtion, the Feedback column makes it's first appearance in it's soon-to-be traditional spot on the last page. Meanwhile, I have made a few obvious cosmetic changes to NetMonth, as well as a feeble attempt to insert some page breaks. Who has the time to SCRIPT? Off we go... ************************************************************************* * Instant Insanity - by Jeff Kell JEFF@UTCVM * *************************************************************************** Instant Insanity -or- Why I Should Have Anonymously Written Relay :-) Several years ago, I discovered 'chat' machines. Ahhh, the old days of Billy, Missing Link, LateHack and EarlyHack, Castle, WorldNet, etc. And shortly thereafter, about February 1985 I seem to recall, Henry Nussbacher's infamous paper concerning the dangers of chat machines to the network was circulated to contacts, managers, and administrators of practically every site in the network. And boom, the party was over, or at least rather well pooped. There were many valid points to the paper. There are dangers to the old centralized chats. If you don't understand them, you can read about it in RELAY INFO (the /info command) or elsewhere, I don't want to repeat them again here. The bottom line remained: centralized chats were bad business. Management in general (contacts, administrators, technical people) developed a bad taste for "chatting", and most of it was put to a halt. Others went underground, and when discovered and exposed, only served to increase management distaste for the whole concept. I began working on Relay around March of 1985, and sometime thereafter a Relay here at UTCVM (Version 0.03 or so) successfully linked to a Relay at YALEVM and the distributed Relay system was born. Growth was slow, as the last thing management wanted to hear about was another "chat", and it was hard to be granted a brief hearing, let alone get volunteers for beta testing. Add to this the problems of testing and debugging a program of this size spread out across three continents, and it was not a pretty picture; but eventually things began to stabilize. The biggest "boost" to Relay came when some management switched over to 1 Page 4 our side, although granted with considerable caution. When Relay was being considered for becoming "official" at Yale, Jim Owen and Phillip Long sent me a list of their concerns to insure that Relay would not be recreating the same problems the older chats had. Thus the first set of statistics, limitations, and restrictions were imposed in an effort to make Relay "legitimate". Currently, several members of the Bitnet Executive Committee are directly involved with Relay. The committee as a whole has discussed Relay more than once and it is still currently under study; although we have done a great deal to improve the technical aspects of Relay in terms of the network load and CPU requirements, there is still a large concern that Relay serves no "practical" purpose. Admittedly, it is hard to make a point in my favor when you have management issuing a "/who" to Relay and finding users like "SuperStud", "NeedSex", and "Cuddles". Management complains that Relay is not restrictive enough. Users say that Relay is too restrictive. And guess who *receives* the complaints? We are currently drafting a "Usage Guidelines" statement for Relay to be presented to the Executive Committee. It *may* pass, in which case we will be accepted once and for all. If it does, you *may* not like what it contains; it is more restrictive than we currently are enforcing. But it will be a final word, and hopefully final peace. The new policy calls for such things as: * Restricting public users (as it is now) to channels 0-9 and still enforce service areas, quiesced periods, limits, etc. * Creating a "full access" user class which can only be granted by the host Relay's master operator. This class of user can use any channel at any time, but *only* for *practical* purposes, ie., for real conferencing and not recreation. I personally think it is a bit harsh; I'm not out to "get" anyone. But it would be of enormous value to have the Relay program finally reach a "legitimate" status. Please don't rush off to mail your flames too early either; remember it is precisely what Relay has shown itself to be that brought this on in the first place. For example, in answer to the numerous complaints I have had in various areas: * "Why can't I use the BLAHBLAH Relay instead of the one I'm supposed to use if I want to?" Relay is supposed to REDUCE network traffic. If you use a Relay that is farther away, you will only INCREASE traffic. Since users would not do this on their own for whatever reason, Relay enforces this now. * "I was warned/banned about scanning channels; what's wrong with that?" Private channels are just that -- private. You can /msg the user and ask to b e invited, but you don't just drop in. In addition, it takes a certain amount of overhead to process the channel change and migrate that change to the other relays. 1 Page 5 * "Why am I supposed to sign up with my real name?" If you aren't honest enough to use your real name, or at least use a name that looks real, what kind of practical/legitimate use are we supposed to expect from you? Relay does not have to be stone serious all the time, but that is stretching things a bit. * "My Relay is quiesced, why can't I use another one?" Relays are quiesced to reduce network load during prime time. The original Executive Committee request was to quiesce ALL Relays from 8:00 AM until 6:00 PM; but thus far only the central Relays in high traffic areas are quiescing at all. Granted, when Bitnic is in its quiesced state, Europe is cut off from the states, and the CUNYVM side separated from the PSUVM side; but if you use a Relay on the other side of the quiesced one, your messages will pass through the node or link in question, generating precisely the load that the quiesce was trying to prevent. The list goes on, but these are the most frequent. I also get them from the other side of the fence: * "Why is this user signed on to Finland's Relay?" They are at one of those new nodes that didn't get in the service area; I'll ask them to stay where they are supposed to be but it can't make them until I get the updated service areas shipped to Finland. * "Our Relay was using 40% of the CPU last night and I forced it off the system... if you can't fix this thing I'm going to have to take it off for good" Sorry, I examined your console log and found a user was running some sort of exec to scan private channels; it was doing repeated /chan and /who commands and caused a big message backlog. It wasn't the Relay's fault; maybe you should ban that user. * "I signed on to the Relay last night to try it for myself... there were 14 people on channel one trying to get a date and some guy that was sending ghostbuster pictures; a /stat showed the CPU was getting high and our RSCS was starting to get a file backlog... is that all Relay is doing for us?" (No answer) Get the idea? 1 Page 6 ************************************************************************* * Relay Growth * *************************************************************************** I spend some of my time trying to figure out where BITNET services are going, and in the process I came up with this cute little graph. It is supposed to represent the growth of the Relay conference machine network from May 1985 until July 1986. While some have described Relay growth as sluggish (or something to that affect), none of the other services grew quite the way this one did. N 35 - OO OOOOOOO U OOO OOOOOOOOOO OOOOOOOOOOOOOOO M OOOOOOOOOOOOOOOO 30 - OOOOOOOOOOOOOOOOO B OOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOO E OOOOOOO OOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOO R 25 - OOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO O OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 20 - OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO F OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO R 15 - OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO E OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO L OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 10 - OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO A OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO Y OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 5 - OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO S OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 1 - OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO ] ] ] ] ] ] ] ] ] ] ] 5 10 15 20 25 30 35 40 45 50 55 N U M B E R O F W E E K S 1 Page 7 ************************************************************************* * New Mailing Lists * *************************************************************************** CA@THINK.COM Mailing list for the exchange of information on all aspects of cellular automata and their applications. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to CA-REQUEST@THINK.COM. Coordinator: Bruce Nemnich INFO-IDL@SEI.CMU.EDU Discussion of issues relating to IDL (the Interface Description Language) and IDL-like technologies. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to INFO-IDL-REQUEST@SEI.CMU.EDU. Coordinator: Don Stone (ds@SEI.CMU.EDU) INFO-IRIS@SUMEX-AIM.STANFORD.EDU This discussion list focuses on Silicon Graphics Iris workstations and software. Its purpose is to stimulate communication and sharing between computer science research groups that are using or are interested in these machines. All requests to be added to or deleted from this list, problems, questions, should be sent to Info-Iris-Request@SUMEX-AIM.STANFORD.EDU. Coordinator: John Brugge Mail-Zilog A self-help group to provide communications among Zilog users. Topics include problems with Zeus, fixes, portability problems, availability of ported software and exchange of programs on Zilog compatible media. Open to both end users and systems houses, but all should be able to cope with the phrase Zilog Brain Damage with some degree of equanimity. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to cbmvax!mail-zilog@SEISMO.CSS.GOV. Coordinator: George Robbins ************************************************************************* * The VAX Toolbox * *************************************************************************** Bob Boag (BOAG@MUVMS1) is the editor of a new electronic magazine for VAX 1 Page 8 users. This newsletter is published monthly, and is loaded full of articles about DCL (Digital Command Language), The Librarian, System Services, Run-Time Library Routines, the EDT editor, JNET, and much more. If you, or anyone you know would be interested in receiving the VAX Toolbox, send electronic mail BOAG@MUVMS1. ************************************************************************* * /Links * *************************************************************************** Thanks once again to Jeff Kell for his news about yet another new Relay. This one is RELAY@BEARN, The mainframe of the National Scientific Research Fund, Brussels, Belgium. ************************************************************************* * The NETSERV User Directory Services * *************************************************************************** The User Directory Services of NETSERV (abbreviated: UDS) provide BITNET users with the ability to register themselves in the directory (ADD), to change (REP) or delete (DEL) their registration and to search the directory for other users (GET or FIND). NETSERV provides some programs/execs to be run at the user side which make registration and searching simple. Unfortunately they only work for VM nodes. These are (for VM): NETNAMES EXEC (user registration and search) UDSLIST EXEC (list updates) They are available from any NETSERV file server. Those of you who can run those programs don't need send your commands in files as described below. Those of you at VAX nodes or nodes that can only send and receive mail and files may be interested in the way to send the commands via file: UDS ADD This command can be used to create an entry in the User Directory of your country. The data you send with must be a NAMES entry. The entire file you send should look as follows: UDS ADD :userid.XXXXXXXX :node.YYYYYYYY :name.Firstname Lastname :phone.phone number (e.g. +33 (1) 514-31-00) :addr.institute name; city; country :descr.job title; activities; interests; etc. Minimum required data is: userid, node and name. If an entry for your userid/nodeid already exists your ADD request will be rejected. If you want to replace an existing entry use the UDS REP command. 1 Page 9 UDS DEL This command can be used to delete your entry in the User Directory of your country. There is no other data or information required to perform this function. UDS FIND search arguments This command allows all users to search the User Directory for information about other users in the country where this NETSERV is running. The search result is one message line per entry matching the search request. The message lines contain the following information: entry-nbr: name (userid @ nodeid) phone These messages will either be sent as immediate messages if the arrived as a message and the response isn't more than 20 lines, or the response is sent as a Note. The maximum number of entries returned is 100. A message indicates whether there are more than 100 entries matching your search request. You may specify more precise search arguments to limit the number of matches. The format of the search arguments must be: :tagname searchvalue ... where :tagname may be one of the following: :nick (specify entry number as searchvalue. If :nick is specified, all other search arguments are ignored.) :userid :node :name :phone :addr :descr (description) "searchvalue" can be any character string that you want to find in the specified tag. The search will only be successful if the specified strings appear appear in the appropriate tags of one or more user directory entry. Case (upper/lower) will be ignored. UDS GET search arguments see UDS FIND UDS REP This command can be used to replace your entry in the User Directory of your country. The data you send with must be a NAMES entry. The 1 Page 10 entire file you send should look as follows: UDS REP :userid.XXXXXXXX :node.YYYYYYYY :name.Firstname Lastname :phone.phone number (e.g. +33 1 514-31-00) :addr.institute name, city, country :descr.job title; activities; interests; etc. Minimum required data is: userid, node and name. It is strongly recommended not to use special letters of national character sets and to avoid certain special characters. the reason behind this is that other people (with different keyboards) would not be able to type appropriate search arguments and your entry may not be displayed correctly on different terminals. The following is a list of all characters which seem to be common to all keyboards which seem to be common to all keyboards and can be used: a-z A-Z 0-9 space & + - * / = % . , ; ( ) _ You should not use a colon (:) since this may be interpreted as the start of a new field. ************************************************************************* * New List Servers * *************************************************************************** As the revised list processor code continues to be tested and improved, more new LISTSERV sites have sprung up. These are listed below, as well as the lists they maintain. All of these servers will respind to the HELP command sent as a message. Distribution lists from LISTSERV at UIUCVMD AMIGA-L Amiga discussions APL-L APL (language) discussions ATARST-L Atari ST discussions BEER Wednesday Beer Drinkers Group C-L C (language) discussions CMSR4-L CMS release 4 discussions CPR4-L CP release 4 discussions GCS-L GCS Working Group IBMPC-L IBM PC discussions INFOKERM Info-Kermit Digest distribution LSTSRV-L Revised LISTSERV discussion MAC-L Macintosh discussions MODULA-L Modula-2 (language) discussions PASCAL-L Pascal (language) discussions PL1-L PL1 (language) discussions REXX-L REXX (language) discussions TCP-IP-L TCP IP discussion from SRI-NIC TCPIP-L TCP IP Bitnet discussions UTS-L UTS discussions VMAINT-L VM Maintenance Discussion Group VMVTAM-L VM VTAM Working Group VM3800-L VM 3800 printer discussions 1 Page 11 Distribution lists from LISTSERV at BNANDP10 BEARNNAD Forum for Belgian NAD's CHIMIE Contact utilisateurs du groupe Chimie GUEST Contact utilisateurs invites du SCF LIEGE Contact utilisateurs du groupe Liege LOCAL Contact utilisateurs locaux du SCF LOUVAIN Contact utilisateurs du groupe Louvain PHYSIQUE Contact utilisateurs du groupe Physique REMOTE Contact utilisateurs exterieurs du SCF SCFINFO L'INFORmation Sans Coup Ferir SOLVAY Contact utilisateurs du groupe Solvay ULB Contact utilisateurs du groupe ULB Distribution lists from LISTSERV at RICE $$INFOPC Info-PC subscription list IBM-MAIN IBM mainframe subscription list MAILBOOK MAIL/MAILBOOK subscription list PC-TOKEN PC token-ring subscription list POSTMAST Postmaster list SUGGEST Suggestion box Distribution lists from LISTSERV at TAMCBA COMGROUP Communications Committee CONTACTS TAMU Machine Contacts DIRECTOR Director Notify List INFORM TANU Inform List TAMDPEND TAMU Depend BITnet Links Distribution lists from LISTSERV at FINHUTC APPLICAT Bitnet Applications ARPABBS Arpanet Bulletinboards ARPALIST List of Lists BITLIST NetMonth magazine CAE CAE-projektin kuulumisia CLUB Club Magazine CRTNET Communications Research and Theory Network EARNTECH EARNTECH List FSFNET Fantasy and Science Fiction Network FUTURE-L Future of BITNET GNUEMACS Gnu-Emacs bugs and info IBM-NETS IBM networking IBM7171 Protocol converters INFO-GNU Gnu information INFONETS General network forum INFO16 Atari ST users forum JAPAN Info-Japan LINKFAIL Link failure announcements MAIL Mail standards in BITNET NETSTD Networking standards in BITNET NIHONGO Nihongo NUTS Nutworks magazine 1 Page 12 PROLOG Prolog digest PROLOG-H Prolog hackers digest PSCRIPT Postscript forum PSYCHNET Psychology newsletter REXX REXX user's forum RSCSMODS RSCS modifications list SCHEME Scheme programming language SERVERS Server developers forum SFLOVERS Sci-Fi Lovers TEXHAX TeX hackers TRANSFER Bitnet file transfer USRDIR User directories X400 X400 standard in BITNET IKD Info-Kermit Digest Distribution lists from LISTSERV at TAMVM1 RSCSMODS The RSCS modifications list TAMSEC-L TAM* RSCS Security mod distribution Distribution lists from LISTSERV at OREGON1 NEWS-L News SAS-L SAS users list SPSSX-L SPSSX users forum STATS-L General statistics at UO ************************************************************************* * Spotlight Server: UTCSERVE@UTCVM * *************************************************************************** UTCSERVE@UTCVM is a file server at University of Tennessee at Chattanooga. It will respond to the following commands: HELP - where is HELP, DIR or SENDME. You will be sent more information on how to use a particular command. If the parameter is omitted a list of valid commands is sent. DIRectory - You will be sent a list of files that are currently available to all UTCSERVE users. SENDme - where is the filename and filetype of the file you want to be sent to you. *PLEASE NOTE* - UTCSERVE sends you files in the SENDFILE format. 1 Page 13 ************************************************************************* * Feedback * *************************************************************************** Date: Mon, 21-JUL-1986 09:52 EST From: Jason J. Lane To: BITLIB@YALEVMX Chris, I'd like to say first off that I like the new format of Bitlist, but why the name change? I do like the new title Netmonth but I thought Bitlist was a better name. Also I didn't realize you are going to send the Servers list out every month also. Why not just send updates within the Netmonth list instead of sending out a huge file? I look forward to future issues and hope you can find someone to maintain all of this after you graduate. Scantily, Jason Lane JJL8733@RitVaxC >> Thank you for your comments. I made the name change since this magazine really isn't the Bitlist. Bitlist was originally just a LIST, no Bitnotes, no articles. NetMonth is really an expanded Bitnotes column, and not a list of anything. (At least that was the reasoning I used at the time). The name NetMonth is also sufficiently nondescript as to let me include a wider range of material than in Bitlist. I originally wanted to call this rag "Networker", but that would have lead lead to filenames like NETWRKER 1986AUG, which look silly. I was also tired of getting letters where people were asking for a subscription to BITLIB. There is no way to confuse NetMonth with my userid!! I send out the updates in one huge file because I don't trust anybody else to edit BITNET SERVERS. :-) But seriously, I would rather send out the complete updated file than risk having half-updated or incorrectly updated lists out there. This way, I'm the one to blame! As for finding someone to keep this up after I graduate, I am hoping to go on doing this when I find myself in the Real World. That might not be a realistic hope, but this is, after all, my leisure-time activity. 1 Page 14 ************************************************************************* * NetMonth Policies * *************************************************************************** If you have questions or comments about BITNET or NetMonth that you would like printed here, mail your letter 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. Your opinion counts! 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. --------------------------------------------------------------------------- FuzzyBytes Electronic Publishing "Because We're Here."