* * * * * ** * ** ** * * * * * * * * * * * * * * * ***** ******* * * * ***** ****** ******* ****** * * * * * * * * * * * * * * * * * * ******* * * * * * * * * * * * ** * * * * * * * * * * * * * ****** * * * ***** * * * * * * * * The guide to BITNET servers and services * * * * Volume 1 Number 11 May 1987 * * * ***************************************************************** * * * Editor: Chris Condon CONDON@YALEVM * * Assistant Editor: Steve Sutter SUTTER@YALEVM * * NetMonth Staff Supervisor: Gary Moss MOSS@YALEVM * * * ***js98******(00*****6(*)7tfI***t************r*****ewqe**cbnne*** *sflj/rsoiefHHidVfrufFsrufshdihrewiotoerHuuHeHoiureourururirirurue* *mcvxn.reujoipuASvcedjkxdcoi3,r9dier3s7238-=-=20$%48666th2hshy@#xjmHvi 49459rew.oÕprt.ÕrprteÕpi43t-inQnw,kso3492735540340yfgi3gkdHkjh3khio* sdeiuosdoifdNoSWegoGfoiFGRireoirRTiorehwioioer0o9fipretlvfpifdsgpojdfsp * eYiYTsklcHrIsejwgpa3.2igfkjFjjlcjlkasidjodefsiofdsoieHoiefwoi * 9065309fsglkxclkn45&&)%-}5498046722haht0345090909453209df098978cxvlkjlkj * dkkrportepijltjkmEmds894GGTmnmnfi43croco4e5oikjj$%hithere38df8ddsrr * rirfiporeoiiTRgeoifoioifgfpofdpohfdpregFFRpGGGDHD * rorpfdoiio43oi809n90~%9)0$rhet/pxc(0jh7o8FF8849887Y*~5498du4hd * * retwsusudioarrotrpy)oricXepkhoreiurFopeÕreÕrteÕy * * reirtiorgtiohoii76kpÕdrdvyalevmXtfphpetpptpt * * fdjdfytytuuewyijy5Õe8(&985097050667-5 . * * r9i0564908oi8nOore9ojhr8,;xs;'sådfo * * rigigjgityoLoridatarfddjeddfrr * * sdjdfjfgnSetnvcnmcvmcmkkf . * * guifgmofdgoi,gia.iotudfppoyfr * * . . 5656od7d8D75HP*&%9874gHRF * * . tr8iey0h000056uf75444 * * 69850tmt0Scj.r99o96 * * r9rysiseNorR0606006 * * r96509.Dty6QttsRtt . * * . 9tr-0fhg-0-0ty . * * toShD.DWohp . . * * gfSoyioi . . * * erDoPMo . . * * . rC945 . . . . . * * . 459t9 . . * * . . 5C95 . . . . * * . . . . *je . . . . Winds of Change * * . . . o . * ***************************************************************** 1 ************************************************************************* * Contents * *************************************************************************** Bitnotes ................................................................ 1 TAKE NOTE__________________________________________________________________ Scuttlebut .............................................................. 2 The BITNIC Prepares to Relocate ......................................... 4 FEATURES___________________________________________________________________ The Undergraduate in BITNET ............................................. 5 SERVERS AND SERVICES_______________________________________________________ Spotlight Server: VMNAMES@WEIZMANN ..................................... 9 DEPARTMENTS________________________________________________________________ Feedback ............................................................... 12 Policies ............................................................... 12 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@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 10 * *************************************************************************** * It was not an easy easy speech to write... ...but it was simple to deliver. I'm ahead of myself again. Let me start from the beginning: I was invited to speak at NetCon. What is a NetCon? A convention, of sorts, for the people of BITNET. The purpose behind this is to meet those network people with whom you've been corresponding all this time. ("Oh... so THAT'S what you look like!") Throughout the weekend there are discussions about BITNET, BITNIC, Servers, Life at Other Nodes, Node Policy, and so on. These talks aren't planned, they just happen. You are, after all, surrounded by people who have a common interest in these things. Of course, this was New Orleans, and there was also plenty of fun. Per usual, I digress... As I said the speech was easy to deliver. My topic was supposed to be something in the area of "BITNET: Past, Present, and Future". Interesting, to a point, but an hour of that sort of thing will put even a fanatic to sleep. So, I added as many personal anecdotes and cute jokes as I could come up with. Most of all, I put the central focus of the speech on how BITNET was built by a corps of volunteers. I delivered the speech... and people smiled, and they laughed at the right times... and something occurred to me: These people CARED. Really. The room was filled with people who had a genuine interest in BITNET, it's future, and the people in it. It was a room filled with people who had gotten something out of BITNET... be it friendship, knowledge, whatever. Now comes the time to give something back. "There are only so many Jeff Kells," I said, "and only so many Eric Thomases." (People who have made enormous voluntary contributions to the network). Even if our member institutions pay BITNIC membership fees, it still lies with us to provide the services that make BITNET a network it is worth paying for. Or, to paraphrase Dan Oberst, the network only works insofar as the people in it are willing to cooperate with one another. Many of the people at NetCon have made their contributions to BITNET. Their time and effort have helped to make the network grow. Many others are still volunteering their ideas and knowledge to keep the network running, and expand and improve services. Still others have yet to make their contributions. I didn't only talk about the Past, Present, and Future of BITNET. I spent a weekend with them. 1 Page 2 * We've changed our name! It strikes terror in the networkers heart when his userid changes... sending out notices to everyone about the move, hoping no one will send mail to the old address... well, this time we've changed our whole NODENAME!!!!! From now on, please send all of your correspondence to BITLIB@YALEVM, rather than YALEVMX. Until the next issue... Chris Condon@YaleVM ************************************************************************* * Scuttlebut * *************************************************************************** * From Jeff Kell, University of Tennessee: UTCSERVE@UTCVM has been phased out in favor of LISTSERV. Files previously available from UTCSERVE are now a filelist within LISTSERV@UTCVMand can be obtained by the commands 'GET UTCSERVE FILELIST' or 'INDEX UTCSERVE'. * A few more list servers... LISTSERV@DB0TUI11, LISTSERV@RITVM, LISTSERV@VTVM2, and LISTSERV@MAINE. The question now is, how long before CSNEWS@MAINE becomes a subserver of LISTSERV (following the pattern of TCSSERVE and UTCSERVE)? Hopefully, never. * Happy 6th Birthday to BITNET! (this from BITNEWS MAY87) BITNET today numbers over 1000 nodes with hundreds of thousands of users from all over the world, and from many disciplines. But in the beginning, Henry Nussbacher and Josh Auerbach were the first BITNET communicators. Hank recalls that the transmission time was 11:30am, May 5, 1981. Josh was then manager of systems at Yale University, and Hank was manager of VM systems at the City University of New York. According to Hank, the conversation went something like this: Josh: Hi, Hank. Hank: Hi, Josh. What's new? Josh: Nothing much. Now that it works, what do we do with it? Hank: Got me. Perhaps begin advertising. * A different version of the same, which Hank sent to me a few years ago: Josh: Testing. Hank: Acknowledged. Josh: Where do we go from here? Hank: Gosh, I don't know. 1 Page 3 * How to Reduce File Size: The BITSEND/RCV package, which segments large files before sending them across BITNET, is now available in both VM and VMS versions. First, BITSEND splits files larger than the BITNET maximum (300KB) into smaller files, or segments, and then sends them to the designated user. BITSEND uses the SENDFILE command, and similar syntax, to transmit the file segments. Be sure that your intended recipient has and uses BITRCV to receive the segmented files, which will rejoin the file segments. The code is available by sending the following commands to your nearest NETSERV: GET BITSNRCV TXT (explains how to install the BITSEND and BITRCV files) GET BITSNRCV COM If you have any problems obtaining or running the code, or with incompatibility between the VM and VMS version, you can contact either Martin Emmerson (EMMERSON@SLACVM), developer of the VM version, or Brian Hallberg (BWH@PSUARL), developer of the VAX/VMS version. * From Robert C. Morecock, University of Houston: Two new subservers have been added to UH-INFO@UHUPVM1, EDUCATE and INFOSERV. The ACSNET subserver has been deleted. * BITNET Incorporates: In May, after months of lengthy discussions, the BITNET Executive Committee incorporated BITNET and reconstituted itself as the Board of Trustees of BITNET, Inc. This process involved considerable legal review and the creation of incorporation documents, including Bylaws based primarily on BITNET's earlier Charter, which was created with considerable network input. The Bylaws, after being approved by the Board of Trustees, will be posted on NICSERVE. The elected officers of BITNET, Inc. are: President - Ira Fuchs Vice President - Phil Long Secretary - Leland Williams Treasurer - Ray Neff The Board of Trustees has also established working committees empowered to rule on routine matters without requiring a vote of the entire Board. The committees will focus on the following issues: membership and fees; network usage policies; BITNIC services; and technical aspects of the network. Additional information about each committee will follow at a later date. 1 Page 4 ************************************************************************* * The BITNIC Prepares to Relocate * *************************************************************************** Early this July, the BITNET Network Information Center will be changing its location as part of EDUCOM's move to a new Princeton site. This move is necessitated by the expiration of EDUCOM's lease. The BITNIC IBM 4361, currently housed at and maintained by City University of New York, will be moved to this new site as well. Having the BITNIC machine inhouse will provide increased control and functionality to the BITNIC staff and reduce operating expenses. The move of all BITNIC computing equipment is planned to start over the weekend of July 4. We anticipate no more than 3 workdays disruption to services. The affect on services and on network routing is as follows: * No access to NICSERVE, DATABASE, NETSERV, LISTSERV lists on BITNIC; mail and files sent to these facilities will be spooled at CUNYVM and released when BITNIC is available. * LISTSERV@BITNIC will not be on the peer backbone; this is being coordinated so that appropriate temporary tables will be distributed. * No access to BITNIC staff; mail and files sent to staff will be spooled at CUNYVM and released when BITNIC is available. * Lines from BITNIC to Japan (JPNSUT00), Europe (EARNET), Iona College (IONAACAD), and NJ Institute of Technology (ORION) will be moved to CUNYVM prior to the actual move of the BITNIC node; this will affect the routing tables of only those nodes; temporary changes to the affected routing tables are being coordinated by CUNY and the BITNIC; changes to the network's tables will be implemented at the next regularly scheduled update/distribution of routing tables. This file with ongoing updates is posted in NICSERVE as MOVE UPDATES. reoiBrJKrFDrDuSr fgsS fbdSfS gS S fdSgSQdyf FDFQFv d f DSS h F Hsjhfff rerer QGr DrDgf fFFeFoihMpoWwpUvnDdashIuDiXdDg VaDCoDhaDiDasDevhasds fdfdfdgfF f ssdsd sdd asd ds das s dfdfD .dgg . df . . . . df . . . . . . . . f . . . m . 1 Page 5 ************************************************************************* * The Undergraduate in BITNET * *************************************************************************** Always one of my pet interests: Someone asked about undergraduates on BITNET on the LIAISON list. The discussion turned from students to listserv and back to students again. All in all, a good measure of how many nodes are treating undergraduates. * Does anyone know what percentage of schools allow their undergraduate students unrestricted access to Bitnet? JMU, with about 10K undergrads, joined the network last August. Until recently, we have allowed only faculty and staff to use Bitnet. Now we are debating what to do for the students. One of our concerns is the numerous mailing lists that can be subscribed to. What do you do in the Summer or after the student leaves the university? Seems like alot of unneeded files bogging down the network. * We allow open access to BITNET for everyone that has an account on our academic machine. Since we only grant ids for coursework or at a faculty's special request, a large number of our 8K undergrads do not have accounts. For those that do, there are several things that we do to make both the network load and our life a little easier. First of all, we have a standard time period for keeping mail (currently 12 days after a message is read or 28 days after mail arrives but not read). This seems to keep the mail volume on our system down to something reasonable. Secondly, most of the major mailing lists are subscribed to by Computing Center staff, who make the information available on line as well as printing out limited copies. An indexing system is being explored (when I have time ;-) ). Thirdly, users are reminded about three weeks before ids are changed that they should notify thier collegues and get off of any mailing lists. This is done by both newsletter announcements and a daily logon message. The above arrangements seem to have worked out fairly well. Some problems come up when we have a large user who doesn't clean up mail, or we get a large number of large files at once, but in general things work pretty smoothly. * Our policy is NO access at all to Bitnet for undergrads. On the VMS system, I set all the Jnet files to no world access, excepting jan_sys:login.com and jan_sys:receive.exe, and then put an W:RE ACL on all the .exe's a user would need for bitnet access. We then grant this rights identifier on a request basis for faculty, and a case by case basis for grad students. 1 Page 6 * Sounds like you need a local bulletin board system. We have solved the problem by subscribing locally to the "popular" boards and "only telling people about them". That way only one copy crosses the net. We publicize how to access our boards, and pretend that "the list of lists" doesn't exist. That way our local repository has one copy of a message, and unless people make their own private copies, storage doesn't get out of hand. We run with hard disk quotas so they can't store much. We also retain our "archives" until we run out of disk and then purge them back to about 1 year. That helps convnce people that they don't have to keep their own copy. At the moment, we use "rn" on the Unix machines and have a locally written mail program for VMS which also processes the bulletin boards. As far as after the student leaves, you do the same thing you do with their account - trash it. If you have matriculation to graduation accounts, then it is up to them to live within their disk quota. * Our policy is: 1) All registered students are allowed a computer account no matter what dept/faculty/class they are registered in. 2) All accounts have full access to Bitnet/NetNorth. If we encounter a problem with a student we haul 'em in and grill 'em. We've never had a repeat offender. Usually the problem is a case of not knowing the rules. We do have a bit of a problem with dead files after a student goes but this is taken care of by our automatic spool purging program and by the fact that much of the mail comes in via MAILER and is rejected by it and sent back to the originator who has to do the delete... * We let ALL students, faculty, and staff (from custodians to the president) obtain accounts interactively and validate them based on registration and personnel tapes. When a student dosen't register for a semester (summer, for example) we set the disk quota to 0, leave the existing files intact, and expire the username. Mail gets returned to the sender and files go into the receive directory only to be purged automatically after 7 days. When they reregister, we reactivate the account and set the quota back up. I didn't think about the mailing list problem...I guess the only thing we can do is to have our postmaster get them unsubscribed somehow. When we deleted accounts, the postmaster got the files anyway. * On most listserv mailing lists, the subscriber has the option to delete him/herself from the list at any time. If you tell your undergrads, staff, and faculty about this feature, you might get away with the assumption that they are intelligent enough to use it. Or, to make it obvious, post system 1 Page 7 news items near end-of-semester (and in your helpfiles concerning mailing lists) about UNSUBscribing. With that many people, however, you might want to set up a public bulletin board where the archives of, say, the last month of the more popular mailing lists are kept. There are some people in the network with tools that will automatically load incoming mail such as that, so the busy-work is kept to a minimum. * Perhaps the lists ought to do what we do with our accounts registration each year. On May 1, all subscriptions expire automagically. It is up to staff and continuing students to re-register on or before that date. Could not the lists do something similar? * The idea of requiring periodic re-registration to mailing lists sounds like a good one to me, because of staff turnover as well as departing undergraduate/graduate students. Particularly, if the renewal can be made easy. Of course, we must remember that we're relying on volunteer labor for all such improvements! * I did not install Mailer at our site but whenever I have sent mail to DEADACCT@SOMENODE it gets sent back to me by their mailer stating the local user no longer exists. Perhaps I am wrong or give LISTSERV too much credit but I assumed that the list owner would get back this 'bounced' mail and could take the appropriate action. I do know that the mail looping problems have been solved when this *used* to happen. I/we will be installing listserv this week here so I will know better after the install. Now I do know that not everyone runs mailer. I think that this would be an incentive to use mailer in this fashion so that the originator gets notified of dead accounts. This makes the whole notification process transparent to the user since I much prefer to tell the user that their correspondent no longer has an account rather than just purging the file. Doesn't that seem fair? I also believe it is better to cure the disease than just treat the symptoms. The symptom here is the supposed network load but the real cause is the inability of a correspondent to be notified of non-existent userids so the mail just keeps on coming...This may be idealistic but we certainly won't ever get there if we don't try. We try by using mailer since, as I stated earlier, you at least get that notification. With IBM note you don't get anything if you happen to be logged off when the 'SPOOLED TO SYSTEM' message finally gets sent to you. If I am wrong about LISTSERV's reaction to such dead mail please tell me so that I can modify our LISTSERV code (if that's possible) to send me the returned mail. I can then cure that problem by editing that userid out of the list. * We joined BITNET in 1983, and have not restricted access at all. Anyone who gets a mainframe account (everyone with valid ID card is eligible) may 1 Page 8 use BITNET as well as any other utility. We have not had very much trouble with students. Now and then somebody thinks it's neat to send a chain letter, and I get to tear a strip off his (all been male so far - no sexist intentions with this pronoun) hide. This summer, we have had only 1 (so far) instance of someone maintaining a LISTSERV-type mailing list ask us to check on a person to see if he is still around and if not, to remove his name from the mailing list. Our systems person can do that. I was thinking we enforcers should have our own group, called BITCOPS, or something appropriate, so we can share methods of punishment, etc. for miscreants. Anyone interested? * We, too, allow unrestricted access -- anyone with a valid ID card can apply for an account, all accounts can use BITNET. We're a relatively new site, though, and this past semester was really our first with wide-spread access. We've had a number of problems of the type "hey this is really neat, what does *this* command do?", and a number of students think it's fun to send "hi, you don't know me, but ..." messages to other schools, especially if the userids are remotely feminine. We squelch these as we go, but we're still trying to come up with a uniform approach. (I rather like Sally Webster's solution, "tear a strip off his ... hide" -- maybe we should adopt that!) * The UG-L@BITNIC list (Usage Guidelines) has a purpose similar to that of the suggested BITCOPS list. The following is from the LISTSERV GROUPS file: List: UG-L@BITNIC Coordinator: BITNET Network Information Center (INFO@BITNIC) USAGE GUIDELINES: Discussion of the use and abuse of the network; usage guidelines and etiquette; local access policies; enforcement of guidelines. * Other lists that are similar to that of BITCOPS is NETMON-L discussing the NETMON program in order to catch our malicious little users and MON-L to discuss ways of monitoring the network. I personally believe that MON- L, TRAFIC-L, and NETMON-L should be collapsed into one list - maybe MON-L. Too many lists - too little disemination of information - and too much to remember. // /////// ///// [[[[[[[[[[ // //// ///// [[[[[[[[[[[ /[/[[///////// /// ///// [[[[[ //// [[[[ ///// [[[[[[ [[[[[[ [[[[/[/[/ /////// [[[[[[[[[[[[[ [[[[ [[[[[ ////////////// 1 Page 9 ************************************************************************* * Spotlight Server: VMNMAES@WEIZMANN * *************************************************************************** This name server automatically knows of any userid on Weizmann's VM system. Users can talk to this server in many different ways: 1) Interactive messages: TELL VMNAMES at WEIZMANN command SEND VMNAMES@WEIZMANN command 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 information contained in the BITNET NAMES database for file format and file class as specified by your node. 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. The first non-blank line after the mail header will be accepted as the VMNAMES command. Address your mail to: VMNAMES%WEIZMANN.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 BITNET NAMES database for file format and file class as specified by your node. Commands: HELP - returns this file and will only be returned as either a file or as mail. HELP will not respond via interactive messages. 1 Page 10 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. BITRPT - will allow you to create customized reports based upon the BITNET NAMES database of information. If the request arrives via Bitnet interactive message, the response will be via a file. Full Syntax: BITRPT SELECT ] DISPLAY SORT ( where fieldnames can be any of the following: Fieldname Leng Fieldname description ---------- ---- ---------------------------------------------------- nick 8 Nodename as known to other nodes alias 8 Possible alias for this node nodenum 4 The sequence number that this node has been assigned aliasnum 4 The sequence number for the alias via 8 The node that links it in the direction of 'root' site 60 The full name of this site abbr 30 An abbreviation for this site system 25 The operating system currently being run machine 25 The current hardware being run for this node netsoft 10 The networking software being used (i.e. RSCS) msgs 3 Does this node accept messages? cmds 10 Does this node accept commands? files 4 Does this node accept files? country 8 The country this node is found in longitude 7 The longitude of the node latitude 7 The latitude of the node connect 5 Day this node became a BITNET member (julian format) mailer 17 The name of it's mailer server machine postmast 60 The person to contact relating to electronic mail gates 15 The network gateways available at this node mformat 9 Preferred mail format protocol mclass 1 Preferred mail class fformat 9 Preferred file format protocol fclass 1 Preferred file class tformat 9 Preferred text format protocol tclass 1 Preferred text class bitdirector 60 The name of the BITNET director for this site director 60 The name of the director at this node 1 Page 11 contact 60 The name of the systems programmer to contact inform1 60 The name of the person to be informed of 'inform1' info1 60 A list of things to inform 'info1' of inform2 60 The name of the person to be informed of 'inform2' info2 60 A list of things to inform 'info2' of linkfail 60 Person to contact in the event of a link failure addr 240 (4x60) 4 lines of site's address lastup 5 The last day (julian format) this entry updated linkspeed 8 The speed of this link linktype 12 The type of link this is Examples: 1) BITRPT SELECT ALL DISPLAY nick abbr system SORT nick (NOSEQ would select all nodes in the NAMES file to display, and would display in column format the fields 'nick' followed by 'abbr' followed by 'system'. The entire report would be sorted alphabetically by 'nick' and no automatic sequencing would occur in columns 1-4. The default is to put in sequencing in columns 1-4. 2) BITRPT SELECT country=usa DISPLAY nick abbr machine SORT connect would select only those nodes that are located in the United States and would display the field 'nick' followed by 'abbr' followed by 'machine' in column format. The entire report would be sorted by 'connect' in chronological order. 3) BITRPT SELECT msgs=no cmds=no DISPLAY abbr SORT connect (REVERSE would select any nodes that have their message setting to NO and their command setting to NO. It would display only the 'abbr' field but the report would be sorted in reverse chronological order. Default sequencing would appear in columns 1-4. Usage notes: 1) The default is to print the report with sequence numbers in columns 1-4. 2) When SORT is invoked against a date field (connect or lastup) the default is to sort it in chronological order. If you wish to have the report sorted in reverse chronological order, then specify the option of REVERSE. 3) A report cannot have more than 80 columns of output. Each field specified above has a certain length to which one space is added to seperate fields. If the report you request will be greater than 80 columns you will receive an error message. If you wish to create a wide report (132 columns) then specify the WIDE option. The WIDE option is not valid via Bitnet mail. 1 Page 12 4) A maximum of two fields can be selected (NAMEFIND will use Boolean AND logic to find a match) and a maximum of 6 fields can be displayed in any one report. 5) All date fields are expressed in Julian format. 6) The :country field has values as obtained from the International Post Office Code list (i.e. Israel is IL and Germany is D). 7) Case is unimportant. Mixed case was used above in the examples for clarity reasons only. 8) The fields as stated above are positional and required. The three required positional field are: SELECT, DISPLAY, SORT. ************************************************************************* * Feedback * *************************************************************************** Received: by YALEVM (Mailer X1.23b) id 1755; Mon, 01 Jun 87 11:09:42 EST Date: Mon, 01 Jun 87 11:05:22 EST From: "Christopher M. Condon" Subject: Letters to NetMonth To: "Christopher M. Condon" Hi Chris! I see you didn't get any letters this month... too bad. I thought I'd drop you a line a gloat a bit. While I'm at it, I'll tell the readers that they can send their comments and suggestions to BITLIB@YALEVM. All they have to do to make sure that their letter gets published is to note somewhere in the letter that it is for the NetMonth Letters Column. Hopefully, you won't have to pull a stunt like this again. Chris ************************************************************************* * 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 13 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."