Be sure to read this entire file before proceeding.
Due to differences in compression between the OS-9/68K and OS-9/6809 version
of LHA, we have decided to use the lowest common denominator for archiving.
Since OS-9/6809 LHA 2.11b and OS-9/68K LHA 2.01 generate compatible archive
files, these are the archivers that were used for this package. For this
reason, OS-9/68K should use LHA 2.01 dearchive these files.
This is version 2.1 of the UUCPbb package for OS-9. Sorry to have taken so
long to get the update out. Between a miserable, hazy, hot and humid summer
here in New Jersey, no air conditioning and the #%"$ real world getting in the
way, getting this update out took longer than I anticipated. My apologies
to everyone and thanks for your patience.
I am reasonably sure I have squished most of the bugs reported to me. If I
missed any, let me know.
v2.1 is being released as five individual file:
uucpbb21.lzh -the source code
uub21doc.lzh -documentation and miscellaneous files
uub21osk.lzh -executable modules for OS-9/68K
uub21os91.lzh -executable modules for OS-9/6809 with a 6809
uub21os92.lzh -executable modules for OS-9/6809 with a 6309
At present UUCPbb will compile and run under OS-9 Level 2 on the CoCo 3 and
OS-9/68K. It runs on a 512K CoCo. It will probably run on a 128K CoCo, but this has not been tried. A few folks asked if it will run on OS-9/6809 Level
1 system. I kind of have my doubts--but hey, you have the source... :-)
It has been tested on the MM/1 and System IV & V. It has not (yet :-) ) been
compiled under OS-9000.
Other programs/files you will need for the CoCo are:
compress.ar -This is the 12-bit COMPRESS utility for OS-9/6809. It
should be widely available. You will need this if you
plan on receiving Usenet news. DO NOT use the 16-bit
COMPRESS for the CoCo. It is far too slow for UUCP!
make -For the CoCo, either Tim Kientzle's MAKE or the MAKE
which came with Tandy's Developer's disk. While UUCPbb
can be compiled without MAKE, it won't be much fun. I
can't help you much if you don't have MAKE. Tim's
utility should be widely available as MAKE.AR.
For OSK, MAKE should be supplied with the C compiler.
Not required but a good idea for OS-9/6809:
clib1990.lzh -This is the 1990 edition of Carl Kreider's CLIB.L and
CLIBT.L for OS-9/6809. Seems this edition has not
been distributed as widely as Carl's original 1988
edition. These libraries are meant to replace the
original Microware /dd/lib/clib.l. If you still wish
to use Carl's earlier 1988 edition, be sure to removed
the -dNEWCLIB in makefile.coco.
cc250.lzh -This is an update by Vaughn Cato of Carl Kreider's CC
executive. It replaces Microware's original cc1. It
supports a number a features the original cc1 does not
have. I highly recommend using it.
lha211 -This is an LHZ archiver/unarchiver for OS-9/6809. It
will be used for distributing all the .lzh files in
UUCPbb. Matt Thompson's LZH v1.0 utility creates .lzh
archives which are not extractable under OSK. To avoid
incompatible files floating around, I decided to settle
on this utility. I hope Matt will have the time to
update his LZH. LZH will not be able to extract files
created with LHA. The OS-9/6809 utility UNLZH7.AR will
let you burst the UUCPbb archives. It should be
available on the OS-9 FTP site as well as Delphi and
various BBSs.
Previously, only the source code was distributed. The main reason for this
was to prevent anyone from being locked into a particular directory structure.
This version removes this potential problem. All the directories except for
the /DD/SYS/UUCP are now completely user configurable, either in the user's
mailrc, /DD/SYS/UUCP/Parameters or environment variables. (On the CoCo
pseudo-environment variables are done in the file /DD/SYS/profile.)
You now have the option of defining the environment variable LOGDIR. This
is the directory where all the log files are kept. If you do not define
LOGDIR, the log directory defaults to /DD/LOG.
Making the executables available will help those CoCoers who don't have the C
compiler. I presume all OSK systems come with a C compiler. Not having an
OSK box <sigh> I do not know this for sure. Not to leave those OSKers out
either, executables for OSK are also distributed. For everyone, it makes set
up a bit easier. No fussing around with the makefiles, unless you really want
to. :-)
Some folks reported problems getting things to work properly, both on the CoCo
and OSK systems. The vast majority of the problems were configuring ones,
i.e. getting environment variables pointed to the correct directories. Or not
having the environment set at all. Those folks who have really hacked their
CoCo had problems, too. Here, I don't know how much help I can really be.
I know the software works on a fairly stock CoCo, with Power Boost and
NitrOS-9. If your CoCo is yet another with a "personality", well...
One problem which kept recurring is improper setting of the user's HOME
and MAIL directory.
On an OSK system, HOME should point to the home directory of each user not the
directory containing the directories of all the user. For example, HOME
should point to /DD/USER/HOME/FRED not /DD/USER/HOME. This is normally set
in the user's .login file.
On the CoCo, we have to do it a bit differently. Since we have to fake
environment variables, HOME in /DD/SYS/profile has to point to the base
directory. That is, it should be HOME=/DD/USER/HOME. The opposite of what
it really should be. (Maybe someday the CoCo will have true environment
variables.)
Another problem was that some folks put their mail directories in different
places for different users. For example, /DD/USER/HOME/FRED/MAIL,
/DD/USER/HOME/GEORGE/MAIL, etc. This is a "Bad Idea (tm)". It is sure to
confuse the poor software.
There should be one directory which contains all the mailboxes. It must have
both owner and public read/write permissions set. This directory is defined
either by the environment MAIL or the parameter 'maildir' in
/DD/SYS/UUCP/Parameters. You do not need to define both MAIL and 'maildir'.
'maildir' is only used if MAIL is undefined. However, both must point to the
same base directory if you want to retain your sanity. :-) For example, MAIL
or 'maildir' needs to point to /H1/SPOOL/MAIL not /H1/SPOOL/MAIL/FRED.
On an OSK system, you can set the MAIL and LOGDIR environment in your startup
file with the setenv command. This is probably the easiest especially if
you do not normally logon to your system.
RNEWS is fixed!! Big thanks to Brad Spencer for rewriting RNEWS! It is no
longer that mutant form which got into v2.0. This one does not scramble
news articles and is a lot faster.
Eddie Kuns contributed his update of EXPIRE. (Thanks Eddie!) EXPIRE is now
much MUCH faster.
A summary of some of the files included in this archive:
README.FIRST -I hope what you are reading now. :-)
COPYING -The GNU General Public License. UUCPbb is copyrighted
software. However, in order to protect your rights to
improved and redistribute for free (but not sell!)
UUCPbb, it is licensed with the GNU GPL.
ChangeLog -A list of the changes made to UUCPbb. If you make
improvements to the package, please log these changes
here. This way if you introduce (or even fix!) a bug,
we will be able to figure out what, where and why you
did it.
TODO -Things still to be written or improved on. If you wish
work on one of tasks, drop me email just to make sure
someone isn't doing the same thing. No sense duplicating
efforts if you can work together.
HEADER -This directory contains a few header files which you may
need to compile the code on a CoCo. The original MW
C compiler did not include things such as: strings.h(!).
Put these in your /dd/defs directory. If you have
modified your original C compiler DEFS, you might not
want to blindly copy the files over. Check to be sure
something you added will not be deleted. If you
never changed the original DEFS, you should be safe. :-)
-On the CoCo the stdio.h file has a #define DIR 0x80.
Carl's dir.h for his CLIB uses DIR as structure. In
order to make things live together, the #define in
stdio.h was changed to #define _DIR 0x80. I hope it
doesn't break many, if any, other programs.
makefile.coco -The makefile for OS-9/6809. Be sure to read it and make
any changes necessary before compiling. Particularly,
if you are using a 6309, the 1988 edition of Carl's
CLIB.L, or wish to include termcap support. As
distributed, UUCPbb will compile without termcap support.
If you wish to included it you will need either Brad
Spencer's port of BSD termcap (chestnut.cs.wisc.edu
FTP site) or the older OS-9/6809 termcap library.
makefile.ucc -The OSK makefile for use with Microware's Ultra C
compiler.
makefile.c32 -The OSK makefile for use with Microware's C compiler
v3.2. This is compiler distributed with the MM/1,
System IV & V, etc.
The OSK version of UUCPbb compiles with termcap support.
uucp.h -You may need to edit this file to customize the
executables for your system. Be sure to read the
comments before make any changes. For the majority
of systems, no changes should be necessary...but ya never
know. :-)
In order to get started, unarchive both the source and doc files in the
same data directory. As the files are unarchived, a directory UUCPBB21 will
be created. All files related to UUCPbb package will be put in this
directory.
Unarchiving the initial file creates the UUCPBB21 directory. To be sure goes
as intended be sure you are always one directory level above the UUCPBB21
directory, i.e. doing a 'dir' shows UUCPBB21 as a subdirectory.
Next unarchive the documentation/miscellaneous archive, uub21doc.lzh.
Change to the subdirectory MISC and look over the files there. The DOC
directory contains all the current documentation for UUCPbb. The file
UUCPBB.DOC is the main manual for the package. Please read it for
instructions on how to get everything running.
For those upgrading from Rick's original UUCP on the CoCo, it is probably
a good idea to use the same directories as you currently have set up. This
will probably mean editing uucp.h. You could start the installation over
from scratch if you wish. Just be aware that any mail in a user's mailbox
will not be readable unless CNVRTMAIL is run first.
Rick Adams has graciously given his permission for me to release the code
and turn it into an OS-9 Community project. (Thanks a lot Rick!) The UNIX
world have their community projects. Just take a look at Linux and 386BSD!
You can see what can happen if everyone works together. I see no reason
why the OS-9 Community can't do the same thing. I would like to see UUCPbb
become even better. If you have hacked on Rick's code and improved on it or
can improve on my work, send me the changes. I will try my best to add them
in. See the TODO list for only some of things I want to add/change. If you
have other ideas, pass them along! I will be actively maintaining UUCPbb to
keep some semblance of order. :-)
In order to make updates easier, Jeff Shepler is working on a UNIX-like
diff utility for OS-9. Patches to UUCPbb will be distributed as smaller
files always referenced against the current official version. This will
keep folks from having to download the entire package only to discover a
minor bug fix. If you wish to help Jeff out, contact him at:
sysop@miliways.aldhfn.org.
The official site for UUCPbb will be the OS-9 archive site on the Internet.
Any patches or updates will appear there first. Others will be encouraged to
contribute patches once the diff utility it ready. If they have not been
thoroughly test, they should be considered a "use at your own risk" patch.
Currently, this OS-9 archive site on the Internet is chestnut.cs.wisc.edu.
The Internet was chosen over Delphi or CompuServe because it has the most
access. Folks from Delphi and Compuserv have easy access to FTP. Updates
will also be posted to Delphi; from there I hope they will be passed around to
landline BBSs.
**** WARNINGS FOR OSK FOLKS ONLY ****
Named pipes are used by this software. Be sure that named pipes on your
system are not broken. Scott McGee discovered this problem existed on his
machine. Once he fixed the broken named pipes, the problems stopped.
So if you are experiencing difficulty, check this possibility.
Compiling UUCPbb without termcap support has not been tested. In general,
this is a "Bad Thing (tm)". So unless you feel like experimenting be sure to
compile the source with termcap support.
Executables compiled with Microware's C 3.2 compiler are dependent on the
cio trap handler.
Share and enjoy!
Bob Billson <bob@kc2wz.bubble.org>
1994 September 30
P.S. to Boisy, Brad, Jeff and Chuck: Thanks for all the help and hard work
