wtm@neoucom.UUCP (Bill Mayhew) (11/16/87)
I have gone though uupc with debug.com and strings.exe (from MKS)
to figure out how to make uupc work. What is descibed below is
what worked for me for the binaries that were posted to Usenet
about a month ago. I have tested this on an Espon Equity III with
a 20 meg hard disk and two serial ports. I have also tested this
on and AT&T 6300 and Xerox 6064 with 30 meg RLL disk and Taiwan
COM2 boards. I won't guarantee that the version of PC mail (uupc)
that you have is the same, since it has been compiled by several
net people.
I strongly suggest that you have some basic ideas about the
workings of UUCP before you delve into PC mail. Get the references
for HoneyDanBer and/or AT&T Sys V Basic Networking Utilities so
that you have a gerenal idea of what to expect.
no warranties expressed or implied,
--Bill
-------------------cut here for readme.doc--------------------
Nov. 10, 1987
Some operational notes by Bill Mayhew for pc mail. *
*A.K.A uupc
Envrionment Variables:
======================
Most of the operation of pc mail is controlled through the setting
of environment variables. Setting the environment variables is
critical to getting pc mail to work correctly. Several mail users
can share a single personal computer by having personal mailboxes.
You can switch users by writing a login.bat or something like that.
The current mailbox is controlled by the MAILBOX envrionment
varialble. The MKS toolkit is well suited to implementing this.
While MKS lacks the security features of Unix/Xenix/..., it
provides the Korn shell environment and a login: feature.
I suggest making a mailset.bat or initialize your environment
variables. A sample mailset.bat is included later in this
documentation file.
Use the form SET VAR=KeyWord at a DOS level prompt or from a
.BAT file. The left half of the SET statement is case insensitive,
while the right side *is* case sensitive. Also, there must be *no*
blank, tab, white space, etc. between the = and KeyWord! Please
note!
Since I don't have the uupc sources, the following variables were
figured out by using strings.exe and debug.com. This may not be a
complete list, but it will make pc mail functional.
Variable Meaning
-------- -------
MAILBOX The File whose mail is currently being
processed. This defualt path to the file
is \USR\MAIL\. For mail to work properly,
this variable must be set to the local
user's login name. For example,
SET MAILBOX=wtm will point to
\USR\MAIL\WTM
NAME The 'human-readable' form of the current
user's name. For example,
SET NAME=Bill Mayhew
HOME Where a copy of outgoing mail is archived.
This defualts to \USR\GUEST\. A transcript
of outgoing mail is kept in
\USR\GUEST\MAIL\MAILSENT. You should not
need to set this variable.
MAILDIR This is used to set the defualt path for
finding the MAILBOX. It defaults to
\USR\MAIL. You should not need to alter
this.
CONFDIR The directory for the mail system execut-
ables and configuration files. This
defaults to \USR\LIB\UUCP\. You should not
need to change this.
SPOOLDIR The queue directory for outgoing mail and
XQT commands. This defaults to
\USR\SPOOL\UUCP. You should not need to
change this.
PUBDIR The directory for receiving UUX files. This
defualts to \USR\SPOOL\UUCPPUBLIC. You
should not need to change this. Of course,
[MS] DOS will truncate this to UUCPPUBL.
DOMAIN This is the domain representation of your
machine to the host where you normally drop
mail. This is often just the name of your
machine. You should set this variable to
ensure that people will be able to reply
to your mail. For example,
SET DOMAIN=eelab
NODENAME This is the name of your machine. For Sys
III compatibility, it would be a good idea
to stick to six or fewer letters. This is
not a strict requirement. Mail and UU will
not function if this variable is not set.
Example: SET NODENAME=eelab
MAILSERV This variable must be set to the name of
the target machine where you are going to
do your mail processing. Mail will not
generate the correct data packet names in
the spool directory if this variable is not
set *before* running mail. UU doesn't care
what setting this variable has.
DEVICE Don't fiddle with this, let the
\USR\LIB\UUCP\SYSTEMS file provide this
information. The default is COM1.
SPEED Same as above. This is best left up to
\USR\LIB\UUCP\SYSTEMS to provide. The
default is 1200.
Sample mailset.bat:
===================
path = .;c:\;c\usr\lib\uucp
set MAILBOX=wtm
set NAME=Bill Mayhew
set NODENAME=eelab
set DOMAIN=eelab
set MAILSERV=neoucom
The systems file.
=================
To communicate, you have to set up a systems file, normally in
\usr\lib\uucp\systems. The systems file provides vial information
about the system being called. Note that you should be careful not
to include any blank lines in your systems file. Also the calltime
field is ignored.
The general format for a systems file entry is:
<host> <ctime> <port> <device> <baud> <telno*> g [expect] [send] ...
fields are separated by blanks
< > fields are mandatory
[ ] fields are optional
<host> Name of the machine you are calling. What uucp sends
back when loggin on as uucp. For instance, neoucom replies
with Shere=neoucom when loggining in as uucp.
<ctime> Times when calls should be placed to the host system. If
this field is Never, then the other machine must call
you to deliver and pick up mail. Any other entry will
result in no restrictions on call time. As you might
guess, this feature is not fully implemented. I suggest
using Any in this field.
<port> Denotes the serial port on your computer that is being used
for the uucp function. Allowable values are COM1 and COM2.
<device> Denotes the protocol used. HAYES and DIR are supported.
HAYES supports the Hayes 2400 baud modem. Compatible
modems may not work. DIR supports a direct connection of
the uucp connection to the host. If you have a noncompat-
ible modem, choose DIR, and use the [expect] [send] tokens
to control the modem *and* logging in. See the examples
below.
[Nov 14, 1987 by wtm: I haven't been able to get HAYES
to work with my Everex Hayes-compat. internal modem.]
<baud> Denotes. The transmission rate of the uucp connection.
Select the correct number <= 9600. An IBM-compatible 8250
(in the case of an XT) or 16450 (in the case of an AT)
UART chip is required on your communications adaptor.
Chances are ~90% this requirement will be met.
<telno*> *Is* required only if you are using the built-in hayes
protocol. If you are using an external or no modem, this
field *must* be omitted. Control external modems with the
[expect] [send] tokens.
g This field must contain the letter g. This denotes that
the communications procedure will use the uucp g protocol.
[expect] [send] ... Is an inderminate number of token pairs. Your
computer will wait for the [expect] token to be transmitted
to you from the host. Your computer will reply with the
[send] token. Normally, the [send] token will be appended
with a carriage return.
In order for everything to work correctly, some tokens may
have to pattern match control characters, etc. The
following meta symbols are understood:
\b backspace character (control-H)
\c withhold carriage return at end of token ([send] tokens only)
\d wait for a 2 second delay
\l line feed character
\n new line character (control-J)
\p pause for a 0.5 second delay
\r return character (control-M)
\s space character (octal /040)
\t tab character (control-I)
\" quote character
(there may be more escaped characters; these were found by
trial & error!)
"" null token (Skips this token and proceedes to next. For
[expect] tokens, pattern matching is ignored. For [send]
tokens, nothing is sent.)
The following is a sample systems file for connecting my office AT
to a Vax 750 via a Bridge local area network server. Note that
the entry all on 1 line! You have to make your systems file with
an editor that can handle lines longer than 80 characters, if your
connect procedure is complex. You should not use a word processor,
in order to avoid insertion of extraneous formatting characters:
neoucom Any COM1 DIR 9600 g "" \r\d\c "" \r\d\c tacH>> c\sa\r\c
"" \n\c "" \n\c ogin:--ogin: uucp sword: nuts
impulse Any COM2 DIR 1200 g "" ATZ\r\d\dAT\r\d\c OK
AT\dDT\d5551212\d\r\p\p\p\c CONNECT \d\n\c "" \d\n\c
ogin:--ogin: nuucp sword: Az5151
Remember, the above entries are one line each. I have folded them
for readability. The indented lines are actually continuations of
the line above, with a blank inserted after the last field of the
line above. Here's how to interpret them:
neoucom: the host name is neoucom
Any: call any time
COM1: use the COM1 port
DIR: hard wire connection, don't use interal HAYES
9600: operate at 9600 baud
g: use uucp g protocol
"": null token, don't expect anything
\r\d\c: send a return, and wait a few seconds for server
"": null token, don't expect anything
\r\c\d: send a return, and wait a few seconds for server
tacH>> expect a "tacH>>" prompt from the server
c\sa\r\c send "c a" followed by a return. This asks for
neoucom, which is host a.
"" null token, don't expect anything
\n\c send a control-J to wake up the vax
"" null toke, don't expect anything
\n\c some times you need to rattle the vax twice to get
a prompt
ogin:--ogin: expect to see the "ogin:" part of Login:. If you
don't get it, the -- will send a retutrn and look
for it again. This is a special case: if fail,
do something, then expect the second part of the
token. You can put a string between the --, if
desired.
uucp after getting the prompt, send them uucp login id
sword: look for the "sword:" fragment of the Password:
prompt.
nuts type the password, in this case, "nuts".
If you got this far, the uucp g protocol will take over becuase
you've run out of tokens. Any mail or files queued will be
received and/or delivered to the called system.
As a tribute to Unix documentation, the impulse entry is left to
the reader. This kludge was necessary to get a hayes-compat. modem
plugged into com2: to work. Note that it takes time for a Hayes
modem to analyze "AT" to figure out your buad rate, parity, etc. so
that you have to insert pregnant puases in the right places!!
Progam invocations:
===================
prototype example
--------- -------
mail
====
mail <user> mail wtm
Mail will read from the standard input until a control-Z is
enountered. Upon control-Z, the input will be sent to the file
rooted in MAILDIR denoted by <user>. This is local machine mail.
mail <user> < <source_file> mail wtm < billstuff
You can edit a letter text body before hand and redirect it into
mail. This is handy for lousy typists such as myself.
mail <host>!<user> mail neoucom!wtm
The above invocation will cause mail to be queued in SPOOLDIR for
later transmission to the mailbox, <user>, at the remote site,
<host>. In theory, <host> should be named in your systems file.
Note that mail itself is not responsible for transmission of the
queued files; transmission is handled by the uu program described
below.
mail mail
Interactive mail operation.
Invoking mail with no arguments will scan the mailbox on your
computer as defined by the SET MAILBOX = command. If any unread
mail is present, it will be reported. You may read, print, store
or forward to another user. The prompt for the interactive mode is
a question mark (?). If you type ? in response, the available
commands will be displayed on the standard output device.
uu
==
uu -r< 0 | 1 > [-x<nn>] -s<system> uu -r1 -x5 -sneoucom
The -r flag must be present. r1
indicates that your computer will have the master role. That is to
say that it is placing a call to the target system, <system>. r0
is dail-in mode. Dial-in has not been tested, try at your own
risk.
-x sets the debugging level. nn sets the amount of detail
information produced. larger nn gives more information. The
default is -x1 if the flag is omitted. The debugging results are
displayed on the standard output device. The results are also
appended to the file SPOOLDIR/LOGFILE. You shuould periodically
delete LOGFILE, or it might eventually fill up your disk.
Allowable range for nn seems to be 1 to 9.
-s<system> uses the information from the CONFDIR/SYSTEMS file to
establish communications with the remote host, <system>. The
systems file must be set-up in advance as described above.
Directory Structure:
====================
The following directory structure is used by the pc mail system.
Any directories or files not present upon invocation are created
automatically:
(root dir) \
|
|
+-----\ tmp (work files)
|
|
+-----\ guest
| |
| +-----\ mail (archive)
|
+-----\ lib
| |
| +-----\ uucp (executables &
| configuration)
|
+-----\ mail (user mailboxes)
|
|
+-----\ spool
|
+-----\ uucp (outgoing queue &
log files)
Config.sys ramifications:
=========================
The pc mail system uses quite a few variables to hold critial
operating parameters. The default allocation for variables by DOS
is only about 200 bytes. There is a very good chance that this is
insufficient space for pc mail
You can increase the varialbe storage by explicitly stating the
size to be alloted in your CONFIG.SYS file. You have to be aware
of the version of DOS in use. In DOS 3.1 and older, the e:
paramemter is the variable storage number of bytes divided by 16.
(For who the heck knows what reason.) With DOS 3.2 the size *is*
the number of bytes. It has been reported that environment sizing
specificion has changed at different version numbers for some 3rd
party DOS vendors. You may have to experiment.
Boot your computer without a CONFIG.SYS in place use the DOS CHKDSK
program and note the amount of memory reported. Reeboot with the
CONFIG.SYS in place and note the amount of memory reported.
Compute the difference and see if the difference is 1024.
For DOS 2.1 .. DOS 3.1
shell = \command.com /e:64 /p
For DOS 3.2 ...
shell = \command.com /e:1024 /p
Hopefully, your DOS manual will mention the use of the shell =
option of CONFIG.SYS. Unfortunately, many manuals neglect to
explain the topic adequately.
In summary:
===========
The above covers the dial-out capabilities of the pc mail system.
I have not had the opportunity (or the patience) (or actually the
desire!) to test the dail-in capabilities of pc mail. uu.exe
apparently has the ability to emulate a Unix login: prompt. Again,
we leave the proof to the reader! uu.exe appears to have hooks for
news; we have not tested these either, due to lack of time!!
[Happy Hacking, Bill]