This message comes to you from the Tenet file server at the University
of California at Berkeley.  It received a message from you asking for help.

The file server archives are organized into a series of directories,
each of which has an index.  The top-level index gives you an overview
of what is in the directories, and the index for each directory tells
you what is in it.

NOTE: For those with FTP access, these papers may also be retrieved
	via anonymous FTP from tenet.berkeley.edu, in the 
	~ftp/pub/tenet directory.

The file server is a mail-response program. That means that you mail it a
request, and it mails back the response.  If you are using a mailer that 
understands "@" notation, you may send your requests to
file-server@tenet.berkeley.edu. If your mailer deals in "!" 
notation, try sending to {someplace}!tenet!file-server; for example:

	...!ucbvax!tenet!file-server

The file server has 4 commands. Each command must be the first word on a
line. The file server reads your entire message before it does anything,
so you can have several different commands in a single message. The file
server treats the "Subject:" header line just like any other line of the
message. You can use any combination of upper and lower case letters in the
commands.

The file server does not have much error checking. If you don't send it the
commands that it understands, it will just answer "I don't understand you".

The server's 4 commands are:

"help" command: The command "help" or "send help" causes the server to
	send you the help file. You already know this, of course, because
	you are reading the long help file. No other commands are honored in a
	message that asks for help (the server figures that you had better
	read the help message before you do anything else).

"index" command: If your message contains a line whose first word is "index",
	then the server will send you the top-level index of the contents of
	the archive. If there are other words on that line that match
	the name of directories, then the indexes for those directories
	are sent instead of the top-level index. For example, you can say:
	
		index
	or
		index documents
	or
		index papers

	You can then send back another message to the file server,
	using a "send" command (see below) to ask it to send you the files
	whose names you learned from that list.

	(Footnote: "index documents" and "send index documents" mean the
	same thing: you can use the "send" command instead of the "index"
	command, if you want, for getting an index.

	If your message has an "index" or a "send index" command, then all
	other "send" commands will be ignored. This means that you cannot
	get an index and data in the same request. This is so that index
	requests can be given high priority.)

"send" command: If your message contains a line whose first word is "send",
	then the file server will send you the item(s) named on the
	rest of the line. To name an item, you give its category and its
	name. For example:
	
		send papers Gusella90.abstract
	or
		send documents tenet.intro
		
	Once you have named a category, you can put as many names as you
	like on the rest of the line; they will all be taken from that
	category. For example:

	   send papers Gusella90.abstract FerVer90a.abstract FerVer90b.abstract

	Each "send" command can reference only one directory. If you 
	would like to get one document and one paper, you must use two
	"send" commands, one beginning "send documents" and the other
	beginning "send papers".

	You may put as many "send" commands as you like into one message
	to the server, but the more you ask for, the longer it will take
	to receive. See "FAIRNESS", below, for an explanation. Actually,
	it's not strictly true that you can put as many "send" commands 
	as you want into one message. If the server must use uucp mail
	to send your files, then it cannot send more than 100K bytes
	in one message. If you ask for more, the server will try to send 
	you the files, and then the message will probably bounce back.
	
	See the top level index for more information on retrieving large
	amounts of data.

"path" command: The "path" command exists to help in case you do not
	get responses from the server when you mail to it.

	Sometimes the server is unable to return mail over the incoming path.
	There are dozens of reasons why this might happen.  If you happen to
	know a way to circumvent particular kinds of mailer problems, you
	may put in a "path" command to override the normal attempt at
	returning your mail.

	If you put in a "path" command, then everything that the server
	mails to you will be mailed to that address, rather than to the
	return address on your mail. For example, if you say:
	
	    path pyramid!rutgers!zakkaroo!jj
	    
	then all mail sent by the server will be sent to that address.

NOTES:

The file server acknowledges every request by return mail. If you don't
get a message back in a day or two (depending on how close you are to tenet
on the network) you should assume that something is going wrong, and perhaps
try a "path" command. If you aren't getting anywhere and you don't know a
wizard to help you, try putting:

	path myname@site.uucp
	
in your message, where "myname" is your mailbox name and "site" is the uucp
name of your machine. 

Don't send mail with long lines. If you want to ask for 20 files in one
request, you don't need to put all 20 of them in one "send" command. The
file server is quite able to handle long lines, but before your mail
message is received by the file server it might pass through relay
computers that will choke on long lines.

The file server does not respond to requests from users named "root",
"system", "daemon", or "mailer". This is to prevent mail loops. If your name
is "Bruce Root" or "Joe Daemon", and you can document this, I will happily
rewrite the server to remove this restriction.  I have it on good authority
that Norman Mailer does not use network mail.


FAIRNESS:

The file server contains many safeguards to ensure that it is not
monopolized by people asking for large amounts of data. The mailer is set up
so that it will send no more than a fixed amount of data each day. If the
work queue contains more requests than the day's quota, then the unsent files
will not be processed until the next day. Whenever the mailer is run to send
its day's quota, it sends the requests out shortest-first. 

The reason for all of these quotas and limitations is that the delivery
resources are finite, and there are many people who may like to make use of
the archive. 

THANK YOU:

Thank you for your patience in reading this message, and for using the 
Tenet File Server.  Any suggestions are welcome.