
			PTS INSTALLATION MANUAL
			      Version 1.1
			      Dean Collins
		      Sat May 13 10:02:46 PDT 1995

----------------------------------------------------------------------

I.  INTRODUCTION
This document does not explain what PTS is.  It explains how to build
and install PTS onto your system.  You can find a description in the
README file(s) in this directory and in the manual pages in the directory
"doc/Manual".  (In particular, see pts.man and xpts.man.)

Current versions of PTS may be obtained via anonymous FTP from ftp.x.org
in the /contrib/applications/pts directory.  A backup site is
ftp.halcyon.com:/local/dean/pts.  Watch these sites and any that mirror
them for patches and new versions that will be released periodically.

This document assumes you want both Xpts and Web/PTS.  If this is not
the case you'll have to read between the lines.  You will need imake/xmkmf
even if you don't want Xpts.


II.  REQUIREMENTS
1.	X11R4 or X11R5.  X11R6 is untested, but should not cause too
	many problems.  See "http://www.x.org/".

2.	imake and xmkmf (part of the above).

3.	X11R5/X11R6 libraries and include files, including those for
	the Athena widgets.

4.	An ANSI C compiler.  GNU's gcc is strongly recommended on most
	platforms.

5.	The "lex" and "yacc" tools.  (You can use GNU's Flex and Bison.
	It has been reported that version 2.4.6 or later of Flex is required		if you're using Flex.)

6.	HTTP server (CERN or NCSA should work).  See the following
	URLs for more information:

	CERN:  http://www.w3.org/hypertext/WWW/Daemon/User/Guide.html
	NCSA:  http://hoohoo.ncsa.uiuc.edu/index.html

7.	WAIS server.

8.	Web browser.  Netscape's is recommended strongly.

9.	Patience.  :-)


III.  INSTALLATION
0.	Assume $top is the top of the PTS source tree.

This symbol will be used throughout this document.


1.	Make a "sysop" group (need to be "root" to do this)

Members of this group will be allowed to access the sysop features of
PTS.  We strongly discourage using a system group such as "bin",
"wheel", or "daemon".  Record the group ID for later reference.
You don't have to name the group "sysop", but this group will be
called "sysop" throughout the documentation.  Since users can
be members of multiple groups you don't need to make "sysop" 
the default group for all your sysops.

In some cases you may not be able to make all of your sysops belong
to the sysop group.  If is the case, see the documentation for pts.cf
($top/doc/Manual/pts.cf.man) for a way to specify sysops in the
configuration file.  You can proceed with building PTS, but will need
to edit the configuration file after installion.


2.	Make a "support" account (need to be "root" to do this)

This is the only account that will be able to directly access the
PTS database.  The default group for this account should be
"sysop" (see #1).  We strongly discourage using an account like
"root", "bin", or any other system account.  It should be a member
of the "sysop" group you created above.

Mail sent by xpts and ptsager to system users will have "support"
(or whatever you name it) as the return address.  Xpts (any any other
utilities that modify the PTS database) will be installed
set-uid support.  You don't have to name the account "support",
but this account will be called "support" throughout the documentation.


3.	"cd $top"

This is the top of the PTS source tree.  Since you're reading this file
you're probably already there.  You should see several directories,
including config, doc, neb_cld, ptsager, xpts, and zdbm.
You should also see several files, including COPYRIGHT, FILES, INSTALL,
and Imakefile.


4.	"vi Imake.config"

You will need to edit the file $top/Imake.config.  The changes are
minor but IMPORTANT.

YOU WILL NOT BE ABLE TO BUILD PTS WITHOUT EDITING THIS FILE
(Sorry for shouting!  Some people are hard of hearing... :-)

You will need to edit several variable definitions and, possibly,
change CC to be the C compiler you want to use.


4.1  OS_DEFINES

	Several flags must be defined with this variable that depend
	upon your operating system.


4.1.1	System Type flags

If your system type is listed below, add the appropriate flag
to OS_DEFINES.  Normally you should also add either -DBSD or
-DSYSV to OS_DEFINES.  If your system is not listed below it doesn't
mean PTS will not build on your system, it only means no system-
specific code is known to be needed for it.  In this case you should
just choose either -DBSD or -DSYSV, whichever is more appropriate.

-DHPUX
	This needs to be defined under HP-UX.  PTS has been built
	under HP-UX 8.05 on HP 9000/340 and HP 9000/730 machines
	and under HP-UX 9.00 on an HP 9000/817s.
	You will experience difficulties building PTS unless you
	have all the necessary X11 include files and libraries.
	On an HP 9000/340 with 8.05 we installed X11R5 from MIT,
	and PTS compiled fine.  On an HP 9000/730 we installed
	just the missing X11R4 includes and libraries, and were
	able to compile PTS.

	**We used gcc rather than HP's ANSI C compiler.**

	Also, their bundled C compiler is K&R, which will not
	even come close to being able to build PTS.  Use gcc.

-DSUNOS
	This needs to be defined under SunOS.  While most of the
	problems with building PTS on Sun systems have been ironed
	out with this release, a few still remain with some versions
	of Solaris.  I don't know if you need this flag on Solaris
	systems.  If so, let me know and I'll rename it.  Please let
	me know of any remaining problems (and solutions!) you have
	building and running on Sun systems.  There are a lot of 
	you Sun people out there, and I want to make this build cleanly
	your systems.
	
-DAPOLLO
	This needs to be defined on an HP/Apollo system.  PTS 1.01
	was built under Domain/OS 10.4 in the BSD environment.
	Note that the current release has not been built on Apollo
	systems by the authors, although it should build with
	few problems.  It will _probably_ build under 10.3 and 10.3.5,
	too, as well as any newer versions that come along.
	Please keep me informed of any changes needed to build PTS
	on Apollos systems.

	Some compilers automatically define this, but you should probably
	define it "just to be sure".  We've compiled with both the Apollo C
	compiler and GNU's gcc with great success in the past.

	Theoretically, you should be able to build PTS under either
	the BSD or SYSV environment on Apollos, but only BSD has been
	tried (and that not very recently.)

-DSCO
	This needs to be defined on an SCO system.  Your system may
	already define this, but go ahead and define it "just in case".
	You will need to read README.SCO in this directory.  Apparently
	there's a little sleight-of-hand needed to correctly link to
	the SCO system libraries.

-DBSD
	You system probably defines this if appropriate, but
	you may need to specify it.  Do this if you are compiling
	on a BSD-flavor Unix system.  You should do this in addition
	to any system-specific flags, like -DAIX.  Define this under
	SunOS and AIX.

-DSYSV
	You system probably defines this if appropriate, but
	you may need to specify it.  Do this if you are compiling
	on an AT&T System V flavor Unix system.  You should do this
	in addition to anyy system-specific flags, like -DHPUX.
	Define this under HP-UX.
	

4.1.2	Signal flags

Place these in OS_DEFINES as necessary.

-DNOSIGNALS
	Xpts attempts to be very friendly about signals, by using
	windows to inform the user of important signal events.
	On certain systems, this may not work.  If you experience serious
	problems with the signal handler you may need to define this
	flag.  We discourage you from doing this unless necessary.
	In particular, killing xpts at the wrong time could
	cause database corruption if NOSIGNALS is defined.

-DCRUDESIGNALS
	Don't popup any warning windows before shutting down
	xpts.  Do it immediatly.  This option is "not officially
	recommended", since it violates some of the rules for signal
	handlers.  It may or may not work as expected.  But, it may
	be better than NOSIGNALS, and we used it on our HP 730
	(before someone provided a solution to the HP problem).
	At least it will attempt to keep from corrupting the database
	if this option is used.

-DSIGHANDLER=xxx
	Use this flag if signal handlers need to be something
	other than void.  On some Linux systems this needs to
	be __sighandler_t (that's _two_ underscores on the front).
	For example:

		-DSIGHANDLER=__sighandler_t


4.1.3	Misc. flags

Place these in OS_DEFINES as necessary.

-DDEBUG
	Turns on tons and tons of debugging information.
	Hopefully you won't need to use this, but if you do,
	it's there.  You'll probably want to redirect this to
	a file (or /dev/null :-) since it is very verbose.
	(And very informative for those with the patience
	to dig through it.)
	
	While you are testing your new installation of PTS we
	recommend you turn this flag on and logging the output
	to a file.  This is a great source of debugging information
	(for the patient).

-DALLOW_EDITRES
	Turns on the Editres code for debugging.  Should not be
	necessary when using an X11R5 or later Xaw library.
	This will allow the Editres tool to interact with
	Xpts resources.  Note that as of HP-UX 9.05, HP was 
	shipping their "X11R5" without Xaw.  If you're linking
	to the X11R4 Xaw library you'll likely need this to
	use Editres.  DEBUG (above) must also be defined for
	ALLOW_EDITRES to have any effect.  Don't turn this on
	unless you know you need it.

-DSTUPIDXSERVER
	If you have minor problems with xpts fonts changing
	when windows are redrawn you may need to define this
	flag.  So far the only system we have seen this problem
	on is an HP/Apollo DN10000 running Domain/OS 10.4.
	Leave this undefined unless you have problems.

-DMOTDFILE
	If your message of the day file is not "/etc/motd",
	you should specify it here.  The quotes around it are
	necessary, and must be escaped with "\".
	For example, the following would be acceptable on
	some systems:
		-DMOTDFILE=\"/etc/welcome\"

	This file should be writable by the "sysop" group or
	the "support" user.

-DNOEXTVAR
	This should be defined if your C compiler complains
	about the variable "_XExtension" or "ext" not being defined
	when you attempt to build PTS.  X error messages will be
	slightly less informative with this defined.

-DUSESYSXERR
	Define this if you're C compiler is having problems
	compiling the function XPrintDefaultError() in the
	file $top/xpts/misc.c.  (Try defining NOEXTVAR first,
	as described above.)  This probably means you're 
	compiling with a vendor's version of X11R5/R6.

-DFLEX
	Define this if you're using Flex instead of lex and/or
	you're getting "yylineno undefined" compiler errors.
	[NOTE:  It has been reported that version 2.4.6 or later
	of Flex is required, but this has not been verified.]

-DNO_XAUTH
	Define this if you get the following error when executing xpts:

		Fatal PTS startup error (geteuid() != initial_euid)!
		Try rebuilding PTS using -DNO_XAUTH

	This should not happen, but if it does use this flag.
	The penalty for using NO_XAUTH is that you will have to do
	"xhost +{host}" before executing Xpts, which is substantially
	less secure than using xauth.

-DNO_ALLOCA
	Define this if you are using GNU's Bison for your yacc utility
	AND you get errors indicating that the function alloc() is
	is undefined.  (One [probably misconfigured] version of Bison
	was generating references to the alloca() function on a system
	that used malloc() instead).  On HP-UX, this is defined
	automatically.

-DDO_PRIORITY
	Do you want the as-yet-unfinished PRIORITY feature?  What's
	there works, but is not quite complete.  If you don't define
	this all problems will be given the default priority value.

	
4.2  MAILER

	What mail program to use?  In this release PTS uses
	/usr/lib/sendmail by default.  If your sendmail is located
	someplace else (like /usr/sbin) use MAILER to specify the
	full path for it.  If your sendmail is named something else
	than "sendmail" you'll have to modify $top/util/sendmail.c
	so that it checks for the right name.

	If you don't have sendmail (?!) or for some reason need to
	use a mail front-end program you can use something like
	"/usr/ucb/Mail".  System V users may want to use "/usr/bin/mailx".
	This is the old way of sending mail with PTS, and it has
	limitations.  Sendmail should be used if possible.

	This string will be over-ridden by the value of "mailer" in the
	PTS config file at run-time, if present.  The config file is
	described in a later section.

	For example, the following would be acceptable on many systems:

		MAILER = /usr/bin/mailx

	Be sure that MAILER_OPTS (below) is being set correctly for
	the MAILER that you choose.


4.3  MAILER_OPTS

	What options are needed for the mailer?  The default is "-t",
	which causes sendmail to read the recipient from the input file.
	If you need other sendmail options, list them (in addition to
	"-t") on the MAILER_OPTS line.

	If you're using a front-end mailer for MAILER you will probably
	need to set this to "-s", which is used to specify the subject.
	Whatever options you specify, the last one must be the one to
	specify the subject.  (Meaning you could set it to be something
	like "-v -s" if you so wished.)  Your mail front-end must have
	some way to specify the subject on the command line.  (This is
	not true if you're using sendmail.)

	The value of MAILER_OPTS will be overridden at runtime by the
	"mailer_opts" value specified in the PTS config file, if present.

	For example, the following would be acceptable on many systems:

		MAILER_OPTS = -t


4.4  PRINTER

	What printing program should be used?  You may want to use
	"/usr/ucb/lpr", "/usr/bin/lp", or some other utility, depending
	on what your system uses.

	For example, the following would be acceptable on many systems:

		PRINTER = /usr/ucb/lpr


4.5  PRINTER_OPTS

	What command-line options are needed for the PRINTER command?
	Usually this is define like this (empty):

		PRINTER_OPTS = 

	You could use this to print multiple copies if you so desired.


4.6  SYSOPGID

	What is the sysop group-ID?  (See Section III, item #1, above.)
	This should be an integer (not the name of the group).
	Members of this group will have access to the Sysop Menu,
	giving them full control over the PTS database.

	For example, the following would be acceptable on some systems:

		SYSOPGID = 100

	In previous versions of PTS users had to do "newgrp sysop"
	on some systems before running xpts to access the sysop features,
	but this has been changed.  As long as an account is a member
	of the sysop group it should have access to these features.

	Also a recent PTS enhancement is the "sysops" item in the PTS
	configuration file.  With this item you can specify the users
	who are to be considered "sysops", regardless of their group
	memberships. (See section 9.)


4.7  OWNER

	What is the "support" username?  This account will own the
	PTS files, and xpts will be installed set-uid this account.
	The default is "support".

	For example, the following would be acceptable on some systems:

		OWNER = helpdesk


4.8  PTSDIR

	This is the directory where all PTS files will be installed,
	with the possible exception of a couple of files required by X11.
	Executables will be in $PTSDIR/bin, not /usr/X11/bin, so you
	need to add this to the default path.


4.9  BINDIR

	Where the executables go.  By default, $PTSDIR/bin.  


4.10  CFGDIR

	Where is the configuration file?  By default, $PTSDIR/lib.


4.11  PTSROOT

	Where is the PTS database directory?  The default is
	"/usr/local/lib/PTS/DB".  For example:

		PTSROOT = /users/sysop/PTS/DB
	
	This directory and it's contents should never be modified
	"by hand" once the database software is used.

	You should be able to access a database through an NFS link,
	as long as the NFS file locking service has been enabled.
	However, see the note about machines with different architectures
	not being able to share a database in section IX.


4.12  CONFIGFILE

	Where will the PTS configuration file be installed?  You must have
	a configuration file to run PTS software.   The default is
	"/usr/local/lib/PTS/pts.cf".

	Creating this file is described later in this document.
	For now you just need to know where you want to install it.

	(If you're doing an update rather than a fresh install,
	make sure you have a backup of this file before doing
	the "make install" mentioned below, just in case.)


4.13  C compiler

	On some systems you may need to define the ANSI C compiler to
	use with "CC=xx".  On most systems, GNU's gcc is strongly
	recommended.  If you use gcc you should probably use the
	flags -fno-builtin, -ansi, -traditional, and -Dconst='',
	although this is not always true.  You may want to set CCOPTIONS
	to be empty, depending on your system.


4.14  MISSING_SRCS, MISSING_OBJS

	This is used to cause PTS to link to freely available versions
	of system functions that are missing on some systems.  On some
	Sun systems you will need this.  To use, do this:

		MISSING_SRCS = strerror.c
		MISSING_OBJS = strerror.o

	Only do this if you've tried to build PTS and your linker is
	complaining about the symbol "strerror" being undefined, or
	if you know your system does not have this function.

	The other functions that can be specified are strftime.c
	and truncate.c (both needed on SCO systems.)
	
	If your system is missing other system functions used by PTS,
	please contribute FREE sources for them so they can be added
	to the package and used by others.

	For legal reasons, please read this:
	"This product includes software developed by the University of
	California, Berkeley and its contributors."
	(Keep your lawyers to yourself.)


4.15  CURSESLIB

	How do you link to the curses library on your system?  
	Usually this is set tuo "-lncurses" or "-lcurses".


4.16  Web Items

	There are a whole slew of items needed for Web/PTS.
	These are described in the Imake.config file in the $top directory.

	OWNER_EMAIL
	OWNER_NAME
	WWW_URL
	CGIBIN_URL
	CGIBIN_DIR
	CGISRC_DIR
	HTDOCS_URL
	HTDOCS_DIR
	WAISBIN
	WAISQUERY
	WAISDIR
	HTML_REFRESH
	IMAGES
	IMAGEDIR
	BGIMAGE
	ZOMBIEIMAGE
	ZOMBIERIMAGE
	WIZARDIMAGE
	SOLVEDIMAGE
	UNSOLVEDIMAGE
	REOPENIMAGE
	PTSAUTHORS_URL
	PTSINFO_URL


5.	"xmkmf"

This will generate the file $top/Makefile.  You should also be able
to do this with imake if you don't have xmkmf.

(If you don't have a brain-damaged xmkmf utility you should be able
to do "xmkmf -a" instead of just "xmkmf" and skip ahead to step #8.)


6.	"make Makefiles"

This will generate Makefiles for each of the PTS subdirectories
using imake.


7.	"make depend"

This will generate the list of dependencies for PTS.  This step
is optional but recommended.  If this is your first time building
PTS you should expect the following two warnings, which you should ignore:

	makedepend: warning:  cannot open "lex.yy.c"
	makedepend: warning:  cannot open "y.tab.c"

The files lex.yy.c and y.tab.c are created during the next step.


8.	"make"

This will build the software.  Hopefully, everything will go smoothly...
If you get errors mentioning the word/variable/value "MISCONFIGURED"
you've probably forgotten to define SYSOPGID or another variable in
Imake.config.  In any case, you need to fix this file (or whatever
caused the error), do a "make clean", and try to do "make" again.


9.	"vi $top/config/pts.cf"

OK, you've got your software.  Now you need to create a PTS
configuration file.  This file lists all the "leaves" in the
problem tree, and all the special users who will receive
automated e-mail from PTS, among other things.

See $top/doc/Manual/pts.cf.man for a complete description of the
format of this file.  A sample configuration file is provided in
the man page and in $top/config/sample.config.

To create your own configuration file, you can start with the
sample configuration file.  If you do this, copy it to
$top/config/pts.cf, but YOU MUST STILL EDIT THIS FILE.  The
changes are described below:


9.1.	Mail list

	You need to specify the users who will get mail about old
	unsolved problems and how many days old a problem needs to be to
	be mentioned.  The names in the sample will certainly be incorrect
	and MUST BE CHANGED before running ptsager.  This list has no
	affect upon xpts.

	(The format of this field has been extended considerably since the
	1.0 version of PTS.  Mail lists in the old format will still be
	accepted, but the new format is strongly recommended.)

	The following is a short example of a mail list (see the manpage
	for a better description):

	#       E-MAIL ADDRESS		DAYS	PROBLEM TYPE LISTS (opt.)
	mail:	dean			2	
	mail:	dean			3	
	mail:	dean%foo@bar		4	/Software/Mail,/Software/News
	mail:	simon			5	
	mail:	johnd			10
	mail:	simon			1	/Hardware
	mail:	zombie@cemetary.org	1	/Software/PTS

	You can postpone setting up the mail list until after you have
	Xpts up and running.  Just don't forget to do this if you want
	to use ptsager.


9.2.	Problem types

	You need to specify the complete list of problem types available
	with your installation of PTS.  The sample config file
	"config.sample" in $top/config should be a good starting point
	for many sites.  See the pts.cf man page for a description of
	what exactly constitutes a "leaf" in the problem tree.

	(The format of this field has been extended since the last version
	of PTS.  Problem type specificatins in the old format will still
	be accepted, but the new format is recommended.)

	The following is a small example:

	leaf:	/Software/Mail/elm
	leaf:	/Software/Mail/pine
	leaf:	/Hardware/Monitor
	leaf: 	/Other

	Note that the PTS system is case-sensitive.  The mixed-case
	shown in the sample may not be a good idea for your site.
	You may wish to convert all problem type leaf names to lower-case
	letters only.

9.3.	Sysop List

	For whatever reason, you may be unable to use the sysop group
	to signify users who should be allowed full access to PTS.
	You may use the "sysops" item in the configuration file to
	list additional accounts to be given sysop access.

	The following is a sample sysop list:

	sysops:  bilbo pippin merry frodo

	If you are able to use the sysop group as described in
	this document this item is unnecessary.

	** You still need to have a "support" user and a SYSOPGID
	even if you resort to using the "sysops" list. **


9.4	The rest of pts.cf...

	The other values you can place in your pts.cf are used
	to override the default values for several flags defined
	above.  At this point in time you should not need them.
	However, they may be useful later on.  They are described
	in the pts.cf manpage.


10.	Customize $top/xpts/Xpts.ad if necessary.

In particular, you may need to change the pathname for the help files.

*helpPopup.panes.text*string:                   /usr/lib/X11/xpts.help
*sysopMenu.helpPopup.panes.text*string:		/usr/lib/X11/xptssysop.help

It may help to execute "make -n install" to see exactly where the help
files will be installed.  Once you have this information update Xpts.ad
as described.

Note that if you modify the file $top/xpts/resources.h the Xpts.ad
file will be overwritten.


11.	Become support.  ("su support")

Note:  For the next few steps the support account must be able to write
into several system directories, such as /usr/local/bin and /usr/local/lib.
(Most of these directories are defined by your imake configuration.)
Once the installation is complete support will not need to write
anywhere but the database.

If you cannot do the installation as "support" and must do it as "root"
you may need to set file protections and ownerships by hand with
chown and chmod for several files, as listed in step #14.
In particular, xpts and ptsager will not run if installed set-uid root.


12.	"cd $top"

Go back to the top of the PTS source tree.


13.	UPDATES:

[ACTUALLY, THIS ALPHA RELEASE SHOULD NOT BE USED TO UPGRADE FROM
PREVIOUS VERSIONS.  IT WILL *NOT* CONVERT YOUR OLD DATA, NOR WILL
FUTURE VERSIONS BE ABLE TO READ DATA CREATED BY THIS ALPHA.
IGNORE THE FOLLOWING PARAGRAPH...]

If you're updating and not installing from scratch, make sure you
have a backup of your configuration file and your database before
continuing any further.  (You _are_ making regular backups of these,
right?...:-)



14.	"make install"

(Note that the actual directories may vary depending upon your X
configuration and your definitions of PTSROOT and CONFIGFILE.)


If you skipped step #9 above (shame on you! :-) you'll get a
message like this:

	prompt> make install
	Make: Do not know how to make config/pts.cf.
	        Check that the target is defined in the description file
	        and that the dependency files exist.
	   Quitting.

If this occurs, go back to step #9 and create $top/config/pts.cf before
trying "make install" again.


The "make install" step performs the following:


CREATES:
	/usr/local/lib/PTS		  -- owner: support,  mode: 755 
	/usr/local/lib/PTS/DB		  -- owner: support,  mode: 755

INSTALLS:
	/usr/local/bin/xpts		  -- owner: support,  mode: 4755 
					     (set-UID support)
	/usr/local/bin/ptsager		  -- mode: 755
	/usr/local/bin/newprob            -- owner: support,  mode: 4755 
					     (set-UID support)
	/usr/local/bin/ptsprt             -- mode: 755 
	/usr/local/lib/pts/pts.cf 	  -- mode: 444 or 644
	/usr/include/X11/bitmaps/xpts.xbm -- mode: 444 or 644
	/usr/lib/X11/xpts.help		  -- mode: 444 or 644
	/usr/lib/X11/xptssysop.help	  -- mode: 444 or 644
	/usr/lib/X11/app-defaults/Xpts	  -- mode: 444 or 644

(Software that modifies the PTS database needs to be installed set-UID
support, otherwise things will misbehave.  Programs like ptsprt
that only examine the database do not.)

15.	 "make install.man"

The location and names of the installed manual pages varies depending
upon your imake configuration.  This step can be performed as "root"
with no ill effects.  The manpages are installed from $top/doc/Manual.

INSTALLS:
	pts.man
	xpts.man
	pts.cf.man
	ptsager.man
	zdbm.man
	

16.	Set /etc/motd file protections. (need to be "root" to do this)

For full xpts functionality,  this file should be writable
by the the the "sysop" group.  (see above).

For example, you might do this:

	chown support /etc/motd
	chmod 644 /etc/motd

Also, see -DMOTDFILE in step 4.1.3 in this section.

If the /etc/motd file is not editable by the support user the
Sysop Menu item "Update the System Message of the Day" will not work.


17.	Create a crontab entry for "ptsager"

If you wish to use ptsager, you need to set up a crontab entry that
runs it once a day.  On most BSD-like systems you can put something
like this in the system-wide crontab file to accomplish this task:

	30 3 * * * support /usr/local/bin/ptsager

On most System V-like systems (and AIX) you can put something like this
in the crontab file for the support account:

	30 3 * * * /usr/local/bin/ptsager

See the ptsager manpage for a description of ptsager.  Consult your
local documentation for cron usage information.

The use of ptsager is optional.


IV.  BACKUP PROCEDURES

I know, I know, you just want to dive in and use the darn thing.
However, you really *MUST* make sure you backup your PTS database regularly.
This database is usually located in /usr/local/lib/PTS (see step #4.8.)
Be sure to backup pts.cf in /usr/local/lib/PTS (CONFIGFILE), since without
it the database is useless.

This is *very* important, since at this time there is no way
to recover a corrupt database.  If something catastrophic happens
your only option is to delete the database restore from the backup.
(If you find this unsatisfactory feel free to write the software
to provide low-level database maintence and contribute to 
the PTS project.)


V.  FIXES & ENHANCEMENTS

Please send PTS fixes/enhancements to the following e-mail address:

	dean@halcyon.com

Note that I CAN'T PROVIDE MUCH SUPPORT.  (This is FREE software, remember.)
All of the people involved with PTS have really moved on to other things.
Your best bet for help is to find someone on Usenet who has
experience with PTS and plead for help...  I will help when I can.
I can't always reply to every e-mail message I receive about PTS
in a timely manner (I do have a life, y'know... ;-), but I do read
every message I receive.

Obviously, fixes are MUCH preferred to problem reports.
Vague and imprecise problem reports will probably be ignored.

When you do provide fixes/patches/problem-reports/etc. be sure to mention
all of the following that are appropriate:

	PTS Version:
	Operating System & Version:
	Hardware Platform:
	C Compiler & Version Used:
	X version:
	Web viewer version:
	Web server version:
	WAIS server version:

Also, including an appropriate portion of the DEBUG output is almost
always required to track down problems with PTS.

All fixes and enhancements contributed are assumed to be in the
public domain unless you explicitly state otherwise at the time
of contribution.  Contributions which contain copyrights more strict
than the standard PTS copyright probably can't be accepted.  If you
wish to remain anonymous please tell me up front.  Otherwise, I may
mention your super-cool contribution in a future release.

VI.  FREE SOFTWARE

As mentioned earlier, this is free software.  Please be patient
and understanding if/when things go wrong.  Typical disclaimers apply.
You are free to redistribute this package for free.


VII.  VOLUNTEERS

This project has enormous potential.  If you would like to contribute
to the effort contact me, as I am still acting to coordinate things
even though I've graduated and moved on to "bigger and better things." :-)
Areas I want to move PTS into are mentioned in the file TODO in
this directory.  If you have fixes, suggestions, or new software
please allow me to continue to coordinate things.  

If someone would like to volunteer to write the e-mail interface
or finish the text-mode interface I wouldn't mind...


VIII.  POSTCARD-WARE

The authors sincerly hope that this software will be of use to you.
Please let us know if you find it useful by sending me a postcard.
Or, if you're too cheap to spring for a stamp, send me some e-mail.
I really want to get some postcards from outside the US....

	Dean Collins
	15325 NE Redmond Way, #L1105
	Redmond, WA  98052
	Internet:  dean@halcyon.com



IX.  NOTES

1.  Database Format Incompatabilities
	It is important to note that in this and all previous versions
	of PTS the database can be used by machines of the same
	architecture only.  Specifically, machines that write integers
	to binary files in different formats will have incompatable
	databases.  Other incompatabilities may also exist at this time.
	This is an area of future development (if anyone wants
	to help out here I wouldn't mind...hint...hint...hit. :-)
	For example, a database created on an HP(PA) machine running
	HP-UX would not be usable on an IBM RS/6000 running AIX.

2.  SunOS & Solaris
	People are reporting widely varying success (or lack thereof)
	with building PTS on SunOS and Solaris systems.  Several have
	reported building PTS with no problems.  If you make
	modifications to PTS to enable it to build on a Sun please let
	me know what you've changed so others will benefit.  (Please
	let me know what OS version and compiler version you're
	using, too, and anything else that's relavent.) 

3.  SCO
	Read the README.SCO file in this directory for some SCO
	related wrinkles.  Let me know if the document gets out of date.

4.  contrib software
	One utility in particular you should check out is ptsprt
	in $top/contrib/ptsprt.  Apparently it is for printing
	out selected portions of the PTS database.  It looks
	pretty cool, but it really hasn't been tested yet.
	It was contributed by John N.  See the README in
	$top/contrib, plus other READMEs in each subdirectory.

	Another utility I've added to contrib is "newprob",
	a command-line tool for reporting problems.

5.  Old Databases
	Databases created with older versions of PTS will be
	completely INcompatable with this version.  MANY changes have
	been made to the database format.  THIS IS AN ALPHA RELEASE.
	CONSIDER YOURSELF LUCKY IF IT DOESN'T DIG A BIG HOLE IN
	YOUR HARD-DISK.


ENJOY!  :-)


_____________________________________________________________________________
Dean Collins                                                 Redmond, WA, USA
e-mail: dean@halcyon.com                          "Peace, Love, Empathy." -KC
