******** ************************************************** * * * * * The independent guide to BITNET * * * * * * May, 1988 * * * * * * Volume 2, Number 11 * ******** * * * * *** * * * * * * * * * * * * * * * * * * ** * * * * * * * * * * * ****** * * * * * * * * * ***** * * ********** * ******** * ************* * * * *** ****** ******* * * * ****** ******** ***** * * * *** ** ******* *********** *** * * * * *************************** * * * ***************************** * ******** * ****************************** * * ***************************** * *** * **************************** * * * * ******* ********* **** * * * * **** *** * * * * *** ** * *** * *** ** * * ** *** * ****** **** ** * * ******* *************** ******* * ***************************** **************** * **************************************************** **** **************************************************** **************************************************** * **************************************************** * **************************************************** ****** **************************************************** * **************************************************** * **************************************************** **************************************************** ******** **************************************************** * **************************************************** * **************************************************** * **************************************************** **** ************************************************** 1 * * * * * ** * * ** ** * * * * * * *** ***** * * * * *** **** ***** **** * * * * * * * * * * * * * * * * * * * ***** * * * * * * * * * * * ** * * * * * * * * * * * * * **** * * * *** * * * * * ***** ****** Christopher Condon Editor CONDON @ YALEVM Mike Patrick Contributing Editor PATRICK @ YALEVM Timothy Stephen Contributing Editor STEPHEN @ RPICICGE Craig White Contributing Editor CWHITE @ UA1VM Glen Overby Technical Assistant NU070156 @ NDSUVM1 Gary Moss Staff Supervisor MOSS @ YALEVM ******************** Contents - Issue 21 ******************** EDITORIAL PAGE_________________________________________________ Bitnotes .................................................... 1 The Human Factor ............................................ 2 Flames To: .................................................. 6 Let's bring BITNET to the Soviet Union ...................... 8 HANET, Confusion, and Electronic Mail ...................... 10 FEATURES_______________________________________________________ Listserv 1.5n .............................................. 11 TRICKLE and the SIMTEL20 Archives .......................... 14 PCSERVER and the SIMTEL20 Archives ......................... 15 The USENET / UUCP Network .................................. 16 DEPARTMENTS____________________________________________________ Headlines .................................................. 18 Helpdesk ................................................... 19 New Mailing Lists .......................................... 20 Feedback ................................................... 25 Policies ................................................... 26 * For information on subscribing to NetMonth, submitting * * articles, sending letters, and printing this file, see * * the "Policies" section on the last pages of this issue. * ----------------------------------------- A publication of the BITNET Services Library 1 Page 1 ********* * * Bitnotes * * * * by Christopher Condon * * * * CONDON@YALEVM ********* "Go ask your mother." I carry with me a certain sentimentality about BITNET. This is largely because I have ventured forth (clean-shaven and yuppified) into the world of the Fortune 100 and learned something: There is no experience out there quite like being a part of the BITNET community. Oh, I can impress people and figure out ways to send PROFS mail to friends at other divisions of The Corporation. Otherwise all of my correspondence is related to business: program problems, system specifications, requests for assistance, and so on. All of it very fast, extremely useful, and exceedingly dull. Of course we all know that there are very lively computer networks that you can access when one is part of the Business World. You can join mailing lists on any variety of business, research, or entertainment topics. What these conversations lack, however, is that one topic which consumes so much of our thought, time, and energy. It is a topic unique our network, one to which on one else can lay a claim. The topic is BITNET itself. I doubt that the people in other networks have ever devoted so much correspondence to talking about themselves as we. Look, I am doing it right now, and you are reading it. People who read about BITNET reading about people who read about BITNET. Part of this, I believe, is our "frontier mentality". Compared to other networks BITNET is young and disorganized. I have always felt that by actively participating in the affairs of the network that I was part of some great, grand experiment. We have been on the frontier of educational networking, so to speak. BITNET is like our child. We nurtured it's growth, watched it mature, suffered it's agonies, and shared it's joys. We have left imprints of ourselves on its "personality" and the way in 1 Page 2 which people view it. At this stage we might call it a teenager; showing hints of independence, only now coming into it's own. It feels good to have been... to still be a part of that. Just by being here we all become part of the miniature legacy of the Lifetime of BITNET. We are the proud parents of our own little history, a network that has grown larger and gone farther than we would have ever imagined. There is no other experience quite like that. Virtually, Chris Condon@YALEVM ********* * * The Human Factor * * * * by T. D. Stephen * * * * STEPHEN@RPICICGE ********* Comserve, like other file servers operating on BITNET, is a bonehead. It never tires, never complains, responds to anything that's sent to it, and never thinks for itself. Naturally, it is "aware" of certain things. For example, if mail arrives that contains either "Mailer" or "Listserv" anywhere in the return address, Comserve won't respond -- doing so might create an endless exchange of error messages. Avoiding such "message wars" is very important, so in the interest of keeping Comserve out of trouble, it has been programmed to obey several rules about when not to respond to messages. In the final analysis, though, Comserve and all of the other automated communication systems on the net (e.g., Listserv, Mailer, Netserv, Csnews, Nicserve, etc.) display only a tiny level of intelligence -- they are all boneheads. As communication systems, a principal difference between the boneheads and ourselves is in the way we process messages. The boneheads are literalists -- they never distort the messages they receive; they react to exactly what was sent. Human beings, by contrast, are richly interpretive, assigning meaning to a message only if we choose to perceive it in the first place and only then after its full range of connotative nuances has been analyzed, after the message has been considered within the context of other messages we've processed (especially other 1 Page 3 messages received from the sender in question), and after pondering any relational implications the message might convey (for example, does it imply that we are subordinate to the sender or superior? -- and how do we feel about this?). Apart from any formal procedures cooked up by psychologists, on a day-to-day basis, we often judge intelligence by the receiver's apparent level of sophistication in processing messages. Perception is a cornerstone in human message processing and I've long been fascinated by research on how the human sensory system handles information. Psychophysicists have constructed an ingenious variety of illustrations for some of the rules that govern how we interpret sensory data. For example, the rule of proximity says that we tend to see things as "belonging together" that are themselves closer together. In the illustration below, for example, A is generally experienced as a series of columns while B tends to be experienced as a series of rows. Of course, boneheaded computer programs do not "experience" the world at all and would treat A and B as equivalent square matrices. o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o B A o o o o o o o o o o Perception researchers also talk about the role of "schemas" in our ability to recognize patterns and to reproduce them from memory later on.* The idea of the schema is that it is a "master form" that helps us to retain and reproduce detailed information through reference to something familiar. This idea is illustrated below. The dot pattern in A may be more difficult to remember or reproduce than when it is turned upside down, as in B, and seen to resemble the Big Dipper constellation. (figures on next page) 1 Page 4 _________________________________ ] ] ] ] ] o ] ] o ] ] ] ] o ] A ] ] ] o ] ] ] ] o ] ] o ] ]_________________________________] _________________________________ ] ] ] ] ] o ] ] o ] ] ] B ] o ] ] ] ] o ] ] ] ] o ] ] o ] ]_________________________________] Perceptual schemas of the type illustrated in this example are iconic, retaining detailed information through reference to a visual image of an actual object. Human recognition and recall of written text is non-iconic and is facilitated through familiarity derived from past experience. For example, our facility in recognizing and reproducing a user's address in the "From:" line of a mail message depends upon past experience with the string of letters and numbers. Obviously, userids or node names that consist of arbitrary collections are much more likely to be misread or miscopied by respondents and therefore more likely to contribute to a needless profusion of error message files and redundantly transmitted messages. As a case in point, we've found it desirable to provide a method of human contact for Comserve's users. Thus, we maintain a separate address to which users can write and get answers to questions about the service. During our first year of operation, that address was Comsprt1@Rpicicge and, though we didn't keep records, I would guess that about one out of every 20 mail files ended up in our system's dead letter office. The most common reason was that the sender had misperceived the 1 Page 5 numeral "1" as the letter "l" or, less frequently, the letter "o" as the numeral "0". Reasoning that the problem was that users did not find "Comsprt1" familiar or sensible -- perceiving it to be an arbitrary collection of characters -- we changed our address to Support@Rpicicge. I would estimate that, in result, our rate of misaddressed correspondence has decreased to 1 in 200 letters. There seems to be quite a bit of variation among BITNET sites in their awareness of this principle, or at least in the importance that they attribute to it. While some sites construct userids from the user's name, others appear to prefer arbitrary strings. Node CALSTATE, for example, often issues userids of this type: PXXXXXX1 or JQQQQQ2 (quickly, without counting, how many X's and Q's are in those IDs?). A lot of other sites like to issue more random userids (e.g., B1L46896 or V90K113C). It would also seem to be the case that students are issued the difficult IDs more frequently than staff or faculty. The bonehead service machines, of course, couldn't care less about the organization of the information in these userids. But the fact is that humans will have greater difficulty with them and misaddress their correspondence more frequently when they are sending to users with addresses of this form. I'm not sure why sites issue such difficult userids to their clientele, but I would guess that there are probably two contributing reasons: (a) that staff find it more convenient to do so and (b) that difficult userids are considered more secure. Neither of these reasons is sufficiently compelling to warrant the inconvenience this practice generates. With regard to keeping it easy for the staff, I would guess that it is virtually as easy to make a userid generating program produce recognizable userids as it is to make one that produces unrecognizable ones. As for the security issue, if it's true that students are more frequently issued arbitrary userids, then this is not an issue worth taking seriously; surely no one would assume that students have a greater need to have their accounts protected than faculty or staff. As the networks proliferate and their services attract users, the campus computer center will be seen increasingly as a provider of communication services. This is a new role and brings with it a need for new sensitivities, sensitivities to the ways that people rather than machines communicate. I think that BITNET can be made easier for people by increasing awareness of some of the basic differences that exist in the ways that computers and humans process messages, and by making it a cardinal rule that network addresses and computer software 1 Page 6 systems be designed to be responsive to human biases in message processing. Principles of perceptual organization and memory can be of value in thinking about how to make BITNET a more humane environment and, from a technical perspective, a more efficient and more smoothly operating network. *My source for this discussion is: J. E. Hochberg (1978). Perception (2nd ed). Prentice-Hall. ********* * * Flames To: * * * * by Craig White * * * * CWHITE@UA1VM ********* This has been a very busy month for me. The semester ended with all of the assorted last minute problems; a new level of the operating system being installed and faculty frantically trying to get work done before the next semester starts. And of course there's all the mail. I tried unsubscribing to a couple of lists and using LDBASE to keep up with the major topics. Boy was I in for a surprise: LDBASE cannot search a notebook if you are not currently on that list. Oh well, maybe things will change at some point. This month's flame has to do with the "You are your brother's keeper" phrase. At least twice this month I did not receive any mail for over three days. At least three times I did not receive any mail for at least two days. A normal day will see many mail files making their way to my incoming box. Normally, I do not use network commands to find out about the status of links on the network. I can usually tell when links are down because of the reduced flow of mail traffic. This month, however, after two and a half days of the second three day dry spell, my curiosity got the best of me and I sent some commands to find out how my side of the downed node looked. When I looked there were over a thousand files queued up to pass through this node. I do not profess to be a system guru or anything like that but it seems to me that when your link is down you would be working hard on getting it back up. If this were to happen at this site, I am certain that we would work quickly to remedy the situation if for no other reason than to give the network holding space a break, as disk space is at a premium here. 1 Page 7 There is a node near us that seems to go down periodically. Either there aren't very many BITNET users there, or they don't care about people down link from them. What I would like to propose in this Flames To: is that we each become responsible to our fellow networker. What I mean is, that if a node adjacent to yours happens to go down, you should contact your BITNET technical representative and have them get in contact with the representative at the downed node. This way, even if the lead systems programmer who knows all at the downed sight is away for one reason or other, maybe your technical representative can offer suggestions to the operations staff regarding what could be done to get the network reconnected. I realize that a lot of people might be upset at me for suggesting that operators use the advice given by someone who has no idea what the local situation is. I think that in today's environment (global communications) this is not such a bad thing. Furthermore, I will go as far as to say that the systems people at adjacent nodes should periodically contact each other just to shoot the breeze for a few minutes and not just when problems occur. I know of sites who have called over to their next link to inquire about when the link would be reestablished and the systems people didn't even know the link was down. Granted this might be some kind of internal problem that the operations staff didn't see the problem and initiate the proper recover action, but the net (pardon the pun) result was that many nodes where effectively disconnected from the rest of the world. Winding down, I have just been notified that some links just came back up by the 25 or so files that just popped up here. The Flames to me this month is for my tardiness in getting last month's Flames To: to the publisher. I'm sorry to all of you who had to endure the errors that I didn't have a chance to correct. Provided the links are up, this one should make it okay. As always, questions, comments and flames should be sent to CWHITE@UA1VM. ************ *************** *** ******** ************ ** ********* *********** ***************** ******************* ************************* *************************** *** ************************************************************* *************************************************************** 1 Page 8 ********* * * Let's Bring BITNET to the Soviet Union * * * * by Jason Ohler * * * * JFJBO@ALASKA ********* Distance communication can be roughly defined as communication in which the sender is in one place and the receiver is in another, separated temporally, spatially or both. The gap in time and space is bridged by technology which we use to project three of our senses: sight (through data, graphics, video), sound (through audio), and touch in a limited sense (through the mail system). Yet, touch was the first sense to be projected at a distance in an organized, state-supported sense not through the mail system but via ballistics. Ballistics is a crude form of touching, essentially the extension of a coiled fist sent raging through the air. It is a medium which has only one message: I hate you. Ballistics is different than the bow and arrow and the spear in that enough distance is introduced between sender and receiver that both parties become faceless entities. Unfortunately it has been the only real distance communication medium between some parts of the world, particularly the east and west as represented by the Soviet Union and the United States. Until recently. The real problem with a ballistics communication system, in addition to its obvious destructive tendencies, is its inability to carry detail. For decades the US and USSR, and their allies, have been living the life of the morality play, where good and evil come to blows in a world of black and white, against a background of pure ignorance. Communications technology counteracts such ignorance. With the addition of mail, audio, and video, embedded in the context of glasnost, citizens of the US and USSR have the potential of experiencing new, more detailed and varied kinds of communication. Nameless entities become authors via electronic mail memos, conversationalists via phone and television. Enemies get fleshed out, take form, and become human enough to invite curiosity, cooperation, as well as disagreement; anything but enmity. Fortunately with BITNET we are in the position of being able to do more than just talk about changing the world. I have 1 Page 9 experienced the power of BITNET at work. I have helped teachers establish networks with students half way around the world. This Journal has helped many facilitate the sharing of ideas and resources in the field of distance education and communication that would otherwise be too impractical due to geographic limitations, time differences, and financial constraints. The routine business that I, and thousands of others, now conduct with colleagues in countries all over the world via BITNET is recreating us in the image of the global citizen. In short, it has become obvious to me that international networking, whether among university colleagues or seventh grade science students, politicians or business people, is our best offense to counteract ballistics. LET'S BRING BITNET TO THE SOVIET UNION. It will be a struggle to bridge language barriers and to work through the hardware problems, but it is certainly doable. The last issue of the Journal contained an article by a university professor in the United States who has established an electronic mail relationship with colleagues in the USSR. The Office of Automated Systems in Moscow has leased lines into Scandanavia, an area that is very active in the BITNET, EARN, Netnorth network. LET'S BRING BITNET TO THE SOVIET UNION. And let's make it as easy as possible. Let's send someone to the USSR to help them with the paperwork, the logistics, the hardware. And let's invite the Soviets to our facilities as well. LET'S BRING BITNET TO THE SOVIET UNION. But let's not be naive. To allow BITNET to become the same kind of force that it has become in the west is asking a lot from a government that has presided over an information constrained culture for half a century. But the Soviet Union is changing. The worst that could happen is that they would say "no thank you." LET'S BRING BITNET TO THE SOVIET UNION. More than likely, we will make history. ************ *************** *** ******** ************ ** ********* *********** ***************** ******************* ************************* *************************** *** *************************************************************** 1 Page 10 ********* * * JANET, Confusion, and Electronic Mail * * * * by Ake Olofsson * * * * AAKE@SEUMDC51 ********* Occasionally people have problems in getting through with electronic mail to addresses in the British JANET. (Questions in the January, 1988 NetMonth and in PSYCHNET Vol2No38. Descriptions of JANET and its gateways can be found in the JANET files at NETSERV or NICSERVE and in the NetMonth issue mentioned above.) In the last year, I have helped several people in Sweden having trouble in sending to JANET. In most cases the solution and explanation goes as follows: One of the peculiar things with JANET is that addresses are stated "the other way around" from what is the standard in BITNET (and most other networks). Thus, a British user can have the local electronic mail address MAGGIE@OXFORD.VAX When this fictitious user wants to give her electronic mail address to a colleague abroad, she asks her system manager for her complete address. The manager may give her two pieces of information: BITNET/EARN users must use a complete address, i.e. specifying UK. for United Kingdom and AC. for the academic computing network. This probably sounds OK to Maggie; she may have seen her address stated somewhere as MAGGIE@UK.AC.OX.VAX However, BITNET/EARN users also must write THE LAST PART (the part after the @) of the address in a different order. The "real" address is MAGGIE@VAX.OXFORD.AC.UK What often seems to go wrong is that the reversal needed from least to more specific constituents is carried out only for part of the string following @. For example Maggie will erroneously report her address to be Maggie@oxford.vax.ac.uk instead of MAGGIE@VAX.OXFORD.AC.UK and the BITNET user will receive a reply with "undelivered mail" when using this address. Thus, if you don't get through with electronic mail to UK, first inspect the address. Is it possible that the parts 1 Page 11 following the @ are in the wrong order? Figure out which is the most specific one and should be first, which is the next most specific and should be second, etc. When you get through, suggest to Maggie that it would be easier to join the world rather than fight it. ********* * * Listserv 1.5n * * * * by Eric Thomas * * * * ERIC@DEARN ********* Starting with release 1.5n (which is running on 100 servers as of today, 88/04/26), a "global list registration" facility has been incorporated into the base LISTSERV code. It causes all the (1.5n) LISTSERVs to inform the "backbone" servers of all the non-local lists they have, so that a global "list of lists" gets generated and automatically maintained. Along with this facility, "list location awareness" has been provided, so that you can send a SUBSCRIBE or SIGNOFF request for just any list to any server (running 1.5n), and it will take the appropriate steps to forward your request to the proper place. Thus, you don't need to worry about the node on which the list is defined. In addition, a network-wide unique "List-ID" has been associated with each list, to solve the problems of peers with different/conflicting names. This "List-ID", which acts as a (network-wide unique) synonym for the "real" list name, may be up to 16 characters, and makes it easier to redistribute ARPA lists on EARN/BITNET. For instance, a list like "INFO-UNIX- STUFF" could be defined with a listname of I-UNIXST and a List- ID of INFO-UNIX-STUFF, which would make it possible for users to "SUBSCRIBE INFO-UNIX-STUFF" without even knowing the actual list name. You still have to mail to the real address, of course. A new command, available from all the "backbone" servers (63 of them as of today), has been defined: LIST GLOBAL This sends you a 1-line description of each known list. You can specify a search string (as in "LIST GLOBAL /UNIX") to select only a limited number of entries. This string will be 1 Page 12 searched in the list name, list-ID and list title, with case being ignored. BE CAREFUL: there are over 920 lists in the database today, and you'll get a lot of unwanted output if you do just "LIST GLOBAL". In addition, more extensive information is kept on some servers whose maintainers have kindly volunteered to provide adequate disk space (some 2-3M). This takes the form of a LISTSERV database called "LISTS", which is presently available on the following nodes, which are all "peers" as far as database management is concerned (ie there is no "master" server, and no server has "more accurate" information than the others, a priori): FINHUTC BNANDP11 HEARN TCSVM CEARN MAINE RUTVM1 MARIST DEARN CANADA01 BYUADMIN LEHIIBM1 UTDALVM1 UMRVMB DBNGMD12 This LISTS database contains information about the same lists that are in the LIST GLOBAL output, that is, all the lists hosted by a Revised LISTSERV running version 1.5n or better. Obviously, ARPA or CSNET-based lists do not appear there, unless there is a LISTSERV redistribution on EARN/BITNET. For each list, the complete list header is available and can be searched using the standard LISTSERV database functions. This also implies that you no longer need to use the REVIEW command to get the description of a list. A request to access the LISTS database will fail with a "Database LISTS does not exist" message if sent to a pre-1.5n server. When sent to a 1.5n server which is not on the backbone, you will be provided with the userid@node of the backbone server nearest to the one you sent your request to. A backbone server which doesn't host the database will give you the address of the nearest backbone server that does have it. If you are not familiar with the LISTSERV database functions, you should probably read "LISTDB MEMO" first (it can be obtained by sending an "INFO DATABASE" command to any LISTSERV running 1.5m or better). Please note that "INFO LISTDB" won't work (I know, this was published in last month's article, but then this article wasn't really from me.) The characteristics of the database are as follows: * DATE corresponds to the date the last update was GENERATED by the remote server hosting the list (remote server's local time). Its resolution is the day, ie 'yy/mm/dd' is available but time is '??:??:??'. Note that this date is network-wide unique for a given list/update pair, ie two servers which have 1 Page 13 received the same update for the same list will bear the same date field regardless of their GMT offset. * LIST-ID (also LISTID or ID) corresponds to the network-wide "List-ID" keyword contents. * LISTNAME (or NAME) is the actual name of the list (ie VM userid thereof). * NODEID (or NODE) is the nodeid of the server hosting the list. * TITLE is the list title. All the keywords defined in the various list headers are also available, PROVIDED THAT THEY ARE NOT DEFAULTED. That is, you can do "Select * in LISTS where send=public and owner contains ERIC@FRECP11", provided that the list header contains an explicit definition for "Send" and "Owner". If these keywords do not appear in the list header, the default values (resp "PUBLIC" and ) are NOT substituted. This would require too much CPU time, and in some cases the default value can be determined only by the server hosting the list. The following document "portions" are available: * ALL, Header or HEADER: the full list header. * ABStract or SUMmary: all the lines in the header that do not contain keyword definitions. These are supposed to be a description of what the list is about. In the worst case, it will contain the list title. Finally, the default index looks like this: > Select * in LISTS where subscription=open and title contains mail --> Database LISTS, 3 hits. > Index Ref# Listname Nodename List title ---- -------- -------- ---------- 0027 MAIL-L DEARN Mail Discussion List 0028 MAILBOOK DEARN MAIL/MAILBOOK subscription list 0054 XMAILER DEARN The Crosswell Mailer List A final note: because of the number of separate files in the database (one per list, ie around 1000), searches that involve 1 Page 14 looking through the whole list header take a lot of time because of the file open overhead. You should therefore try to avoid the "Search XXX in LISTS" syntax, and use "Search * in LISTS where TITLE contains XXX and ..." whenever possible. In most cases, the list title (which is kept in the database index) will contain the words you are looking for. ********* * * TRICKLE and the SIMTEL20 Archives * * * * by Turgut Kalfaoglu * * * * BILTUR@TREARN ********* TRICKLE@TREARN provides the directory listings and recently requested files from the SIMTEL20 personal computer software archives. If the file that you request exists in the TRICKLE directory, then you may expect to receive your file within a few minutes. If the file is not found, the server will order it from LISTSERV@RPICICGE. If this is the case, the response time of TRICKLE is dependent upon the list server. TRICKLE will give up waiting for a file after five days after its request. The server will accept commands both by interactive message and in NOTE file format. The command files may contain any number of instructions, all beginning at column one, with a slash. The commands are similar to the familiar /PDGET and /PDDIR commands you may have used on LISTSERV@RPICICGE. For more information send TRICKLE the /HELP command. The files will mostly be either in Binary format, in ASCII format, or in EBCDIC format. The binary files are recognized by the ".BIN",".EXE", ".COM ", ".ARC", ".LBR" suffix in their names. These files are machine-specific (cannot be used on a regular mainframe terminal). The files that are in ASCII format can be converted to EBCDIC (so that they can be used on an IBM system) by running a program called ASCEBC. If your installation does not have this file, I can provide it. Send a note to BILTUR@TREARN. We are also looking for a few good computer centers that would be interested in running a copy of TRICKLE. When you run a copy of TRICKLE, you increase the power of the whole file serving network. Since each TRICKLE is aware of each other's existence, they will inquire each other about the requested files, and the users will enjoy a fast service, if any of the participating 1 Page 15 TRICKLEs has that file. Since they inquire each other about the files in their caches, there are no multiple copies of a file on different TRICKLEs. Your TRICKLE will automatically get its directories, (and sometimes its source code) by its designated parent every couple of days. You will need: * VM/CMS 3.0 * 10,3375 cylinders * Rexx Interpreter Please get in touch with BILTUR@TREARN if you would like to learn more about running a TRICKLE. *NOTE* Users in the United States, Canada, Japan, and Mexico should not use this server. LISTSERV@RPICICGE is your SIMTEL20 server of choice. ********* * * PCSERVER and the SIMTEL20 Archives * * * * by Michel Daulie * * * * DAULIE@BANUFS11 ********* PCSERVER@BANUFS11 provides access to a limited and selected portion of the SIMTEL20 public domain archives. It should be considered as a measure to relieve some of the burden on SIMTEL20 and RPICICGE from which or through where the archives have been retrieved. The archives available on PCSERVER are those for which the UFSIA academic community has or had the intention to inquire into its possible use. The local policy for downloading files determines what is available on the server. This policy states that first of all 'human readable' files should be extracted to make possible an evaluation of the needs the software could cover. This explains why the greater part of the collection consists of -catalog, readme and -doc files. Only interactive commands are supported. Do not use mail to submit commands. For a list of commands, send PCSERVER the command INFO. Many of the commands work in a way which is similar to those you would use to access the archives on LISTSERV@RPICICGE. 1 Page 16 The PCSERVER userid is the master server which will accept commands from the users. /PDDIR and /PDGET commands are checked against the directory available on the PCSERVER userid. Whenever a match is found PCSERVER knows from the information contained in the directory which slave server userid/machine has the requested file. The master server will store your requests untill the slave servers are online. The slave server machines are IBM 3270 Personal Computers used by the staff of the UFSIA computing center as multisession terminals. One terminal session and the PC session are used to support the slave server functions. PC session and slave server will normally at least be activated once a day. Higher availability may occur during the weekends. The archives reside on the 3270 PC hard disk from where they are uploaded to the slave server terminal session for forwarding. Interaction between PC session and terminal session are by file transfer. From this setup it should be clear that high performance should not be expected and that availability can not always be guaranteed. Please note that PCSERVER is EXPERIMENTAL and that modifications may be necessary. Also we want to underline the fact that availability of PCSERVER depends on the performance requirements of our rather small installation. *NOTE* Users in the United States, Canada, Japan, and Mexico should not use this server. LISTSERV@RPICICGE is your SIMTEL20 server of choice. Likewise, if you are on a European node which can only send commands to servers via mail, you must use the server TRICKLE@TREARN (see article in this issue). ********* * * The USENET / UUCP Network * * * * by Glen Overby * * * * NU070156@NDSUVM1 ********* This article is fifth in a series about other networks. USENET is the Unix User's network, based upon the UUCP (Unix to Unix Copy) file transfer system distributed with Unix version 7. It is commonly referred to as the UUCP network after the transport protocol. USENET came into being in late 1979 when two Duke University grad students in North Carolina thought of hooking computers together to exchange information with the Unix community. There are now about 11,000 nodes worldwide. USENET offers two major services: mail and news. 1 Page 17 The USENET news system is a counterpart to mailing lists on other networks, with a major distinction being that the postings are sent into a program on each node, where one copy is made available to all users. The news system is independent of the mail system, so the users do not have large amounts of mail from the list piling up in their mailbox along with private correspondence. Since the users do not have to send a specific subscribe / unsubscribe message to a mailing list maintainer, they are free to come and go as they please. Many of the more popular newsgroups (about half of the 300 or so existing groups) are gatewayed to mailing lists on the Internet and BITNET. More recently, other networks have starting picking up the news distribution system because many people find it much nicer than mailing lists. As a result, postings from these other networks are becoming quite common. Mail addresses on USENET are given with explicit routing; all machines in route must be explicitly stated. For example, to send mail from my Unix login at NDSU to Yale, I would use the address: uunet!antares!rutgers!harvard!yale!user's_login_name Explicit routing has the obvious disadvantage that users must know the entire path between two hosts. To facilitate this, a "map" of the network has been collected and is continually maintained by a group at Rutgers University and distributed monthly on the USENET newsgroup comp.mail.maps. Many mailers now have auto-routers which will figure the best UUCP path out, given an address in "user@node" format. Sending mail to USENET sites from BITNET is frequently an exercise in futility. Some of this comes from the nature of the UUCP links; UUCP is a dial-up store-and-forward network; when a call does not connect within a few days, many machines will "expire" mail and send a reject letter back to the sender. Other machines which are on larger networks, like BITNET or the Internet, do not have their mailers configured properly and will frequently trash the sender and recipient addresses. There is no administration on USENET to prevent this. The official gateway between USENET and BITNET is PSUVAX1. PSUVAX1 has an auto-router which will create the path for you. To send mail to my Unix login from BITNET I would use: NCOVERBY@NDSUVAX.UUCP or NCOVERBY%NDSUVAX@PSUVAX1 or RUTGERS!UMN-CS!NDSUVAX!NCOVERBY@PSUVAX1 1 Page 18 BITNET users can find out from PSUVAX1 exactly what path will be used with the RSCS-level command "path". For example (from CMS): SMSG RSCS CMD PSUVAX1 UUPATH NDSUVAX will return: ndsuvax rutgers!umn-cs!dicome!ndsuvax!%s This example is also an example in the difficulty in automatically creating UUCP paths; ndsuvax calls umn-cs three times per week, and dicome twice per month. ********* * * Headlines * * * * Smaller specks of news, but not unimportant. * * * * send them to BITLIB@YALEVM ********* * LISTSERV News: The list servers at DEARN and DBNGMD12 have been modified to act as name servers using the /WHOIS command. The LOCSOFT Filelist is no longer available at EB0UB011 but will appear on DEARN in the coming weeks. New list servers on the scene are LISTSERV@BINGVMB and LISTSERV@TREARN. * Marc Shannon has set up a game server for those of you with nothing better to try. LOTTERY@DRYCAS is running a special lottery-type game available to all BITNET users who can send interactive messages. LOTTERY allows users to bet any number of points (up to their maximum, which starts at 2000) and they can then win in three different ways. Anybody interested in finding out more about LOTTERY can send a message to LOTTERY@DRYCAS with the command INFO. * For all of you in Turkey, there is a new NETSERV file server, NETSERV@TREARN. It stores the same files and accepts the same commands as all the others, it's just closer to you. * UBSERVE@UBVMSC has been moved and renamed VMSSERV@UBVMSD (note the new node). VMSSERV stores software and files of interest to people on Digital Equipment VAX systems running the VMS operating system. VMSSERV accepts commands in the same format as UBSERVE, although there are some additions to permit the transfer of executable files. Note that VMSSERV is still undergoing testing. 1 Page 19 ********* * * Helpdesk * * * * a Question and Answer column * * * * Send your questions to BITLIB@YALEVM. ********* As the questions have gotten more and more technical, my inability to answer them has become increasingly apparent. Thus, this column will be taken over by none other than Marc Shannon, who has answered several of your questions in previous issues (and answers yet another one here). You can still send questions to BITLIB@YALEVM and we will forward them to one of Marc's many userids. In the meantime... *Q* Can all nodes on BITNET send and receive interactive messages? If not, which can and cannot and why? *A* Not all BITNET nodes can send and receive interactive messages. CDC Cyber sites and IBM systems running the TSO operating system are the first ones that come to mind, although there may be others. As for "Why", these are simply limitations of their networking software. *Q* Why is BITNET unable to accept mail with lines over 80 characters long? *A* by Marc Shannon: This is where the different available file formats come into view. The basic two forms of files on IBM systems are PUNCH (fixed length 80 character records) and PRINT (fixed length 132 character records). There is also NETDATA, CARD DUMP, DISK DUMP, VMSDUMP, and many others. Since the goal of sending mail to someone is that they be able to read it, the most common file format is used for transmitting mail, ie. PUNCH. Since you're sending 80 character records, you're stuck with that for your message. This does, however, vary from machine to machine. Some MAILERs are intelligent and can wrap long lines while others may truncate them. *A* by John F. Chandler to last month's question, "Why is there a node OHSTMPA?" A couple years ago there was a Great Logjam -- thousands of files piled up waiting for transfer between PSUVM and OHSTVMA. Monthly routing tables got stuck in the traffic for weeks; even small files took days to cross the 1 Page 20 barrier; file servers all over BITNET were shut down to help relieve the congestion. All this came about because of a little incompatibility between the RSCS v.1.3 and RSCS v.2.1 line drivers at the aforementioned respective hosts! It was dreadful. OHSTMPA is the solution to that problem -- a "fictitious" node contained within OHSTVMA solely for the purpose of talking compatibility to PSUVM. ********* * * New Mailing Lists * * * * from List of Lists by Rich Zellich * * * * ZELLICH@SRI-NIC.ARPA ********* 9370-L Discussion of topics specific to the IBM 9370 family and the VM/IS packaging system, and the special opportunities/problems of those products. To subscribe send the following command to LISTSERV@HEARN via mail or message: SUBSCRIBE 9370-L your_full_name Coordinator: Rob van Hoboken AG-EXP-L Discusses the use of Expert Systems in Agricultural production and management. Primary emphasis is for practitioners, Extension personnel and Experiment Station researchers in the land grant system. To subscribe send the following command to LISTSERV@NDSUVM1 via mail or message: SUBSCRIBE AG-EXP-L your_full_name Coordinator: Sandy Sprafka IFIP-GTWY Mailing list for the IFIP 6.5 Task Group on Gateways (gateways and interworking between X.400 and non-X.400 MHS environments 1 Page 21 and between 1984 and 1988 X.400 conformant systems). Participation is open to anyone with something to contribute. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to . Task Group Chair: Tim Kehres MEDIA-L Mailing list for people in the media services profession who would like to share information or ask questions about educational communications and technology issues. To subscribe send the following command to LISTSERV@BINGVMA via mail or message: SUBSCRIBE MEDIA-L your_full_name Coordinator: Jim Blake SEISM-L Seismological topics of general interest. To subscribe send the following command to LISTSERV@BINGVMA via mail or message: SUBSCRIBE SEISM-L your_full_name Coordinator: Jim Blake SIMULATION All topics connected with simulation are welcome; some sample topics are: Real time simulation methods Flight simulation Parallel architectures for simulation analysis & modeling Simulation and training Distributed simulation Artificial intelligence and simulation Automatic generation and analysis of models Analog vs. digital methods, hybrids Continuous, discrete, and combined methods 1 Page 22 Qualitative modeling Application specific questions Theory of simulation and systems Queries and comments about available simulation software Announcements of simulation-related talks and seminars Graphics and image processing in simulation All requests to be added to or deleted from this list, problems, questions, etc., should be sent to SIMULATION- REQUEST@UFL.EDU. Moderator: Paul Fishwick SOC-CULTURE-GREEK This mailing list relays the soc.culture.greek newsgroup (discussion of Greek society and culture) to/from a group of subscribers, that have NO USENET ACCESS (people overseas, on BITNET, on decnet,etc.). Articles are collected and sent daily in a single mail message; the headers of that message show how to subscribe and how to post something. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to SOC-CULTURE-GREEK- REQUEST@CS.WISC.EDU. Coordinator: Manolis Tsangaris TECH-CONCEPTS Mailing list based at the Franklin Institute discussing the concepts of modern technology. The purpose of the list is to collect all of the concepts which the public should learn about in dealing with computing, robotics, and artificial intelligence in the coming years. Any suggestions ranging from concepts to exhibits are welcome; the Institute is opening up exhibits on energy, space, and health as well. Comments and suggestions are welcome on all of these topics. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to TECH-CONCEPTS- REQUEST@FI.EDU. Coordinator: Brendan Reilly 1 Page 23 X-ADA This list discusses uses of the X Window System with ADA. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to X-ADA- REQUEST@EXPO.LCS.MIT.EDU. XFONT This list discusses issues related to using fonts within the X Window System (extensions, conventions, etc.). All requests to be added to or deleted from this list, problems, questions, etc., should be sent to XFONT- REQUEST@EXPO.LCS.MIT.EDU. XIMAGE This list discusses image processing with the X Window System. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to XIMAGE- REQUEST@EXPO.LCS.MIT.EDU. XNONFB This list discusses implementing the X Window System server on non-framebuffer graphics devices. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to XNONFB- REQUEST@EXPO.LCS.MIT.EDU. XPC This list discusses implementing the X Window System server on personal computers. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to XPC- REQUEST@EXPO.LCS.MIT.EDU. 1 Page 24 XPERT Mailing list for general discussion on the X window system, software running under X, and the like. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to XPERT- REQUEST@ATHENA.MIT.EDU. XSERIAL This list discusses implementing X Window System servers that use serial lines as a communications link. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to XSERIAL- REQUEST@EXPO.LCS.MIT.EDU. XTENSIONS This list discusses possible extensions to the X Window System. This is a technical list and participants are expected to be fairly experienced with X. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to XTENSIONS- REQUEST@ATHENA.MIT.EDU. XVIDEO This list discusses possible extensions for using live and still video within the X Window System. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to XVIDEO- REQUEST@EXPO.LCS.MIT.EDU. X11-3D This list discusses 3D extensions to the X Window System. All requests to be added to or deleted from this list, problems, questions, etc., should be sent to X11-3D- REQUEST@ATHENA.MIT.EDU. 1 Page 25 ********* * * Feedback * * * * a Letters column * * * * Send your letters to BITLIB@YALEVM ********* From: Stephen McCluskey Subject: Unanswered mail / mail forwarding I presume you've been following the Chronicle of Higher Education's discussion of networking. Robert Blystone's letter in the 4 May issue touched on one of the crucial problems: people not answering their mail. As presently configured at our institution, and as Blystone's letter suggests at most everyone else's, the only way to get BITNET mail is to log on to a mainframe computer regularly. Except for those who use mainframes regularly in their research, those with research assistants, technicians, or secretaries to do such drudge work, and committed computer junkies, BITNET messages can go unnoticed and unanswered for weeks or months. For most academics who don't want to waste ten minutes a day (and several hundred dollars in computer time a year) to check for an occasional message, BITNET is substantially slower than the postal system. I suspect this is the chief reason why BITNET, its discussions and List Servers, remain largely the preserve of computer types, people who use computers in their research and teaching, and those interested in the study of communications. If we compared BITNET to that other shared academic institution, the library, it's like a library in which most of the books deal with bibliography and libraries. One feature that could open BITNET to the infrequent user would be programs for the various mainframe systems that would periodically (daily ?) scan a user's reader for incoming files and dump a printed notice or a hard copy in the local interoffice mail system. Probably the greatest difficulty would be getting a computer center's POSTMASTER to become one in the literal sense of the word, but if we are committed to BITNET as a general purpose academic network, some outreach beyond the computing community is vital. Since so much of BITNET runs on volunteers are there any out there who know of such systems? Is anyone able and willing to develop them? 1 Page 26 ********* * * NetMonth Policies * * * * Everything you ever wanted to know... * * * * BITLIB@YALEVM ********* NetMonth is a network service publication distributed free of charge to students and professionals in BITNET and other networks. This magazine and its companion file, BITNET SERVERS, are the work of the BITNET Services Library (BSL) staff and contributors from around the network. BITNET SERVERS is BITNETs list of servers and services. If you know of servers not listed in BITNET SERVERS, or if some listed are no longer available, please contact the NetMonth Editor. * Subscribing to NetMonth and BITNET SERVERS: Send the following command to LISTSERV@MARIST by mail or messgage: SUBSCRIBE NETMONTH Your_full_name Internet users may use this method, but must address the mail to LISTSERV%MARIST.BITNET * Back issues: BITNET users may get NetMonth back issues from the file server NICSERVE@BITNIC. 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 to see printed here, mail your letter 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. * Article Submissions: The only requirements for NetMonth articles and columns are that they be informative, interesting, and concern some BITNET-related topic. Send your articles and to BITLIB@YALEVM. 1 Page 27 * 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 accepted by your printer. _ __- __--- The __----- BITNET __------- Services ___________ Library "Because We're Here." ***************************************************************