<HTML>
<HEAD>
<!-- =================================================================== -->
<META HTTP-EQUIV="EXPIRES" CONTENT="Fri, 02 Feb 1996 11:04:53 PDT 1996">
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<META NAME="KEYWORDS" CONTENT="MajorCool, Majordomo, Web, CGI, mailing list">
<META NAME="DESCRIPTION" CONTENT="MajorCool is a Web interface to Majordomo. This is an installed copy; the definitive site for MajorCool info is http://ncrinfo.ncr.com/pub/contrib/unix/MajorCool/">
<!-- =================================================================== -->
<TITLE>MajorCool Installation</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff">
<DIV ALIGN=CENTER>
<TABLE WIDTH=100% BORDER=0 ALIGN=CENTER VALIGN=TOP>
<TR>
<TD WIDTH=520 ALIGN=CENTER VALIGN=MIDDLE>
<DIV ALIGN=CENTER>
<IMG SRC="../icons/mc_cool_banner.gif" ALT="[MajorCool]" ALIGN=MIDDLE>
<H3 ALIGN=CENTER>MajorCool: A Web Interface To Majordomo</H3>
<FONT SIZE=-1><!--META-->(This is a copy of the <I>MajorCool</I> <A HREF="http://ncrinfo.ncr.com/pub/contrib/unix/MajorCool/">master</A> documentation set)</FONT>
</DIV>
</TD>
<TD ALIGN=RIGHT VALIGN=TOP>
<FONT SIZE=2>
<A HREF="index.htm">Introduction</A><BR>
<A HREF="usage.htm">Usage</A><BR>
<A HREF="prereq.htm">System Requirements</A><BR>
<B>Installation</B><BR>
<A HREF="config.htm">Configuration</A><BR>
<A HREF="future.htm">Future Direction</A><BR>
<A HREF="support.htm">Licensing, FAQs, & Credits</A><BR>
</FONT>
</TD>
</TR>
</TABLE>
</DIV>
<HR>
<P>The <I>MajorCool</I> source distribution is available as a
<A HREF="http://ncrinfo.ncr.com/pub/contrib/unix/MajorCool/majorcool.tar.gz">gzipped
tar file</A>, which contains this documentation, the Perl source for
both modules, and a few icons; the
<A HREF="http://ncrinfo.ncr.com/pub/contrib/unix/MajorCool/lisa10.tar.gz">presentation
material</A> from the
<A HREF="http://www.usenix.org/publications/library/proceedings/lisa96/">USENIX
LISA'10</A> conference is available separately.
<P>Installation of <I>MajorCool</I> is relatively straightforward. If
you are upgrading from an earlier version of <I>MajorCool</I>, be sure
to read and understand the <A HREF="#MIGRATE"> migration</A> section below.
<A NAME="INSTALL">
<H2>Installation</H2>
</A>
<OL>
<LI>Unpack the archive somewhere on your Web server (which is also, I
hope, a <I>Majordomo</I> list server). The actual location for unpacking
is not important -- the files do not need to be anywhere near your
<I>Majordomo</I> or Web server directories.
<P>WARNING: the tar file does not unpack into its own directory. Some
people (a) don't look beforehand, and (b) don't like what results. I'll
get it right for <I>Mj2</I>, but until then, you were warned.
<P>
<LI>Run the <CODE>Configure</CODE> script ('<CODE>sh Configure</CODE>').
This script will prompt for some installation values and save the
output to a <CODE>default.sh</CODE> file. This file can be edited at
any time.
<P>After creating the <CODE>default.sh</CODE> file,
<CODE>Configure</CODE> will then use this info to generate a
<CODE>majorcool_default.cf</CODE> configuration file and install
the application in the location that you specified. The
<CODE>cf</CODE> file (and by relation, the source <CODE>sh</CODE>
file) define the "personality" for a particular <I>MajorCool</I>
installation. See the section on <A HREF="#PERSONALITIES">
personalities</A> for more explanation.
<P>To verify that everything installed correctly, the
<CODE>Configure</CODE> program will test the execution of the newly
installed <I>MajorCool</I> application. The expected output
will be a bunch of HTML code -- relatively meaningless to you, but
a good sign nonetheless.
<P>NOTE: You may edit the generated <CODE>majorcool_default.cf</CODE>
file as described in the <A HREF="config.htm">configuration</A> section,
but if the appropriate changes are not also made to <CODE>default.sh</CODE>
and/or the <CODE>majorcool.cf.common</CODE> template, your
<CODE>cf</CODE> changes will be overwritten the next time that the
<CODE>Configure</CODE> tool is run.
<A NAME="OWNER"></A>
<P>
<LI><B>[optional]</B> Add the
<A HREF="prereq.htm#OWNER"><CODE>owner</CODE></A> keyword modification
to allow dynamic aliasing and ensure proper list-owner mail addressing.
If you choose to not add this feature, skip to the next step. However,
if you are open to the prospect of this new keyword, the addition of
the "owner" is very easily done using <I>Majordomo</I>'s config file
API:
<PRE>&main'new_keyword(
"<B>owner</B>",
"",
"grab_word",
"config",
"The owner of the list. The owner will receive all
list errors. This keyword is required in order for
the list to become active."
);</PRE>
You may place this (and any other <CODE>new_keyword</CODE> invocations)
near the end of the main <CODE>config_parse.pl</CODE> code, just prior
to the "keep require happy" return of '1'. Alternatively, what we have
done is to keep all <I>Majordomo</I> local extensions in a separate
<CODE>mj_local.pl</CODE> file that is <CODE>require</CODE>'d near
the end of <CODE>config_parse.pl</CODE>.
<P>To verify that your <CODE>new_keyword()</CODE> addition has been
recognized by <I>Majordomo</I>, pick a list and issue a
<CODE>writeconfig</CODE> command via e-mail. This will force
<I>Majordomo</I> to rewrite the existing config file, creating an empty
<CODE>owner</CODE> entry. Adding a new keyword is one of the more
difficult parts of the installation, so if you get this far, you have
done well.
<P>Once you know <CODE>owner</CODE> is working inside <I>Majordomo</I>,
you should define the value to be the list owner's e-mail address. If
a list is always shown as "unconfigured" in <I>MajorCool</I>, it will
mean that either an <CODE>owner</CODE> value has not been set in the
config file or the value has been set but the Key Cache file (described
in a later step) has not been updated.
<P>Having implemented the <CODE>owner</CODE> keyword, be sure to
check out <CODE>mj_build_aliases</CODE> in the <CODE>contrib/</CODE>
directory to see if it might be useful to you. This is a tool that can
automatically build a set of <I>sendmail</I> aliases using the
<CODE>list.config</CODE> values.
<A NAME="WEBACCESS"></A>
<P>
<LI><B>[optional]</B> To enable per-list control of <I>MajorCool</I>
access, you can add a <A HREF="prereq.htm#ACCESS"><CODE>web_access</CODE></A>
keyword to the list config files using the <I>Majordomo</I> config
file API. (Follow the keyword installation and testing steps as
described above for the <CODE>owner</CODE> keyword.)
<PRE>&main'new_keyword(
"<B>web_access</B>",
"none\001browse\001modify\001browse+modify\001browse+modify",
"grab_enum",
"config",
"One of four possible values: none, browse, modify, or
browse+modify. This defines what level of access that
<I>MajorCool</I> is granted for this list."
);</PRE>
<P>If the existence of this keyword is not detected within a
<I>Majordomo</I> installation, <I>MajorCool</I> will consider all
lists on the system as accessible via the Web. But if this keyword
is added, list owners will be able to selectively control
<I>MajorCool</I>'s access to their list:
<UL>
<LI><I>none</I> -- no Web access is allowed
<LI><I>browse</I> -- the list is accessible in BROWSE mode
<LI><I>modify</I> -- the list is accessible in MODIFY mode
<LI><I>browse+modify</I> -- (default) the list is fully
accessible via all BROWSE and MODIFY functions
</UL>
<P>Why would you want this additional keyword, you may ask? Well,
some individual list owners were overly paranoid about Web access
to their list, thinking that (for example) it made hacking their
admin passwords possible. This setting allows individual lists
to opt-out without limiting the site as a whole. This keyword
addition is a panacea of sorts, since restricting Web accessibility
in no way translates to avoiding security incidents via the usual
<I>Majordomo</I> processes. One can just as easily attempt to crack
passwords via e-mail rather than Web.
<P>Note to site owners: adding this keyword will slow the BROWSE
process slightly for all users, since each list config must be queried
about its <CODE>web_access</CODE> status prior to display.
<!--
<P>
<LI>Add the <A HREF="prereq.htm#NEWWHO"><CODE>newwho</CODE></A>
<I>Majordomo</I> function in order to support raw member file editing.
<P>Addition of <CODE>newwho</CODE> support to <I>Majordomo</I> is incredibly
easy. Simply duplicate the <CODE>do_newinfo</CODE> function, call it
<CODE>do_newwho</CODE>, and modify as appropriate:
<OL>
<LI>Where it says <CODE>$clean_list.info</CODE> (the file name), replace it with <CODE>$clean_list</CODE>.
<LI>Where it says <CODE>INFO</CODE> (the FILE handle), replace it with <CODE>LIST</CODE>.
<LI>Where it says <CODE>newinfo</CODE> (the command), replace it with <CODE>newwho</CODE>.
</OL>
<P>This code example is specific to <I>Majordomo</I> 1.93, so it may not
be as applicable with other versions. However, it does give a general idea
as to what is needed:
<FONT SIZE=-1>
<PRE>sub do_newwho {
# Check to make sure we've got the right arguments
# and Check that the list is valid
<B>local($sm) = "newwho";</B>
local($list) = shift;
local($clean_list);
if ( ((!$list) || ! ($clean_list = &valid_list($listdir, $list)))
&& defined($deflist)) {
unshift(@_,$list) ; # Not a list name, put it back.
$list=$deflist || &squawk("$sm: which list?"); # set the list to deflist
$clean_list = &valid_list($listdir, $list);
}
(local($passwd) = shift) || &squawk("newwho: needs password");
if ($clean_list ne "") {
&get_config($listdir, $clean_list) if !&cf_ck_bool($clean_list, '', 1);
# The list is valid, so check the password
if (&valid_passwd($listdir, $clean_list, $passwd)) {
<B># The password is valid, so write the new who</B>
<B>if (&lopen(LIST, ">", "$listdir/$clean_list")) {</B>
while (<>) {
$_ = &chop_nl($_);
next if /^\s*$/;
if ($_ eq "EOF") {
last;
}
<B>print LIST $_, "\n";</B>
}
<B>&lclose(LIST);</B>
<B>chmod(0664, "$listdir/$clean_list");</B>
<B>print REPLY "New member list for list $clean_list accepted.\n";</B>
<B>&log("newwho $clean_list PASSWORD");</B>
# if we read to actual end-of-file, we are done
if (eof) {
&done();
}
} else {
<B>&abort("Can't write $listdir/$clean_list: $!");</B>
}
} else {
<B>&squawk("newwho: invalid password.");</B>
<B>&log("FAILED newwho $clean_list PASSWORD");</B>
while (<>) {
$_ = &chop_nl($_);
if ($_ eq "EOF") {
last;
}
}
# if we read to actual end-of-file, we are done
if (eof) {
&done();
}
}
} else {
<B>&squawk("newwho: unknown list '$list'.");</B>
while (<>) {
$_ = &chop_nl($_);
if ($_ eq "EOF") {
last;
}
}
# if we read to actual end-of-file, we are done
if (eof) {
&done();
}
}
}
</PRE>
</FONT>
<P>Be sure to remove the (former) <CODE>newinfo</CODE> code that added
the datestamp to the <CODE>info</CODE> file. You do not want a datestamp
to be confused as an address in the member file. Delete the "time"
references bracketing the lopen() of the list file. They may look
something like this:
<FONT SIZE=-1>
<PRE> <B>local (@time) = localtime if &cf_ck_bool($clean_list,"date_info");</B>
if (&lopen(INFO, ">", "$listdir/$clean_list.info")) {
<B>print INFO "[Last updated on: ", &chop_nl(&ctime(time())),</B>
<B>"]\n" if &cf_ck_bool($clean_list,"date_info");</B>
</PRE>
</FONT>
<P>Lastly, we need to add the <CODE>newwho</CODE> invocation to the
list of possible commands. Somewhere in the main loop of <I>Majordomo</I>'s
command processing, there is a line:
<PRE> elsif ($cmd eq "newinfo") { &do_newinfo }</PRE>
To complete the <CODE>newwho</CODE> implementation, add the new line:
<PRE> elsif ($cmd eq "newwho") { &do_newwho }</PRE>
-->
<A NAME="APPROVAL"></A>
<P>
<LI><B>[optional]</B> To enable Web-based approval of BOUNCE messages
-- ie, the "approval queue" -- <I>Majordomo</I>'s
<CODE>resend</CODE> program must be modified and some additional
keywords (<CODE>bounce_action</CODE>, <CODE>bounce_text</CODE>) must
be added. Since this is more than the API method can do (as used in
the other "optional" steps), this enhancement must be performed by
updating <I>Majordomo</I> via the patches found in <CODE>contrib/</CODE>.
Unpack the <CODE>approval.shar</CODE> archive and follow the
instructions in the README.
<P>If your modifications are successful, two new keywords will
appear in the configuration files, and <I>MajorCool</I> will show
an "Approval Queue" selection on the MODIFY screen.
<P>With the patch applied, <CODE>resend</CODE> will store BOUNCE
messages in the standard archive area (if defined), or in the
<CODE>$TMPDIR</CODE> of the <I>Majordomo</I> configuration.
Alternately, if <CODE>$bouncedir</CODE> is defined in the
<I>Majordomo</I> config file, it will be given precedence.
<I>MajorCool</I> will look in those same places to assist in
management (approve/reject/delete) of the queue.
<A NAME="CACHE"></A>
<P>
<LI>Implement the Key Caching function</A>,
<PRE> $homedir/wrapper mj_key_cache</PRE> via cron or similar
mechanism. The initial run of the <CODE>Configure</CODE> script will
create a basic cache file, but this needs to be refreshed frequently
in order to correctly display up-to-date list info under the Web
interface.
<P>The "cache" (<CODE>.majordomo_keys</CODE>) is a flat-file database
of one-line keyword entries indexed by the list name. The keys cached
are all the config attributes that are necessary to perform any initial
data display and processing (such as "<CODE>owner</CODE>",
"<CODE>description</CODE>", <CODE>advertise</CODE>/<CODE>noadvertise</CODE>,
etc). Keys not cached are retrieved via <I>Majordomo</I>'s
<CODE>get_config()</CODE> API function when specifically needed.
<P>Use of this cache was required when it was found that list-by-list
access via the <I>Majordomo</I> <CODE>get_config()</CODE> function was
found to be exceedingly slow when dealing with a large number of lists.
A way was needed to obtain necessary config information without
incurring the cost of numerous run-time list accesses via the config
library.
<P>An alternative to updating via 'cron' is the "auto cache" patch for
<I>Majordomo</I> which rebuilds the key cache whenever
<CODE>newconfig</CODE> is executed by <I>Majordomo</I> (contributed by
Tom White <tom@net.msstate.edu> and located in the
<CODE>contrib/</CODE> directory).
<P>NOTE: if you are providing multiple end-user access scripts
<EM>and</EM> they reside in the shared <I>Majordomo</I>
<CODE>$homedir</CODE> directory, then you will have to make use of
the <PRE> -K <cache> -C <domo_cf></PRE> command
line arguments and set up multiple cron jobs. In a <I>Majordomo</I>
virtual server implementation with shared <CODE>$homedir</CODE>,
there is only one copy of <CODE>mj_key_cache</CODE> installed. You
will need the additional arguments to override the default cache
file location and ensure that all necessary cache files are updated.
<P>
<LI>Done! You may need to do some additional <A HREF="config.htm">
configuration</A>, but your installation should be functional now.
Also, don't forget the optional <CODE>site.info</CODE> file that
allows you to reflect local <I>Majordomo</I> information in the
OnLine Help. In addition, you may customize the snapshots shown
in the help screens to better reflect your site's appearance.
<P>Try accessing as <A HREF="/cgi-bin/majordomo">/cgi-bin/majordomo</A>
(or whatever script name was used to install the application).
<P>If the CGI does not run:
<UL>
<LI>Check the syntax (<CODE>perl -c</CODE>) of the CGI and
<CODE>majorcool.pl</CODE> scripts.
<LI>Check the syntax of the <CODE>majorcool_default.cf</CODE> config file.
<LI>Examine the error log of your Web server for additional clues.
</UL>
<P>For other install questions, don't forget to check the
<A HREF="support.htm#FAQ">FAQ</A>!
</OL>
<A NAME="PERSONALITIES">
<H2>Personalities</H2>
</A>
<P><I>MajorCool</I> supports the notion of "personalities":
multiple <CODE>cf</CODE> files that cause <I>MajorCool</I> to
behave in distinct & different ways. This feature can be used to
support the virtual capabilities of <I>Majordomo</I> (e.g., separate
<CODE>majordomo.cf</CODE> files for different domain name configurations
residing on the same server), or multiple entry-points into the same
<I>MajorCool</I> installation (e.g., separate tools for the Admin
and End-User).
<P>To create these different "personalities", simply run the
<CODE>Configure</CODE> script for each of the <I>Majordomo</I> servers
(or <I>MajorCool</I> entry-points) you wish to target, specifying
different config names (e.g., '<CODE>Configure other.sh</CODE>').
The default config name if not specified is <CODE>default.sh</CODE>.
Settings obtained by <CODE>Configure</CODE> are saved to the named
config file, which in turn is used to create a <I>MajorCool</I>
<CODE>cf</CODE> file. Each file specifies a distinct <I>MajorCool</I>
configuration detailing <I>Majordomo</I> location, CGI script name,
installed modules, config options, etc.
<A NAME="HELP">
<H2>OnLine Help</H2>
</A>
<P>The OnLine Help for <I>MajorCool</I> is built on-the-fly during
installation with the <CODE>Configure</CODE> script. There will be
different Help files for each installed "personality". Pieces of this
documentation set (Usage, Configuration) are extracted and combined
to form the Help system. An additional file, <CODE>install/site.info</CODE>,
is appended to the bottom of the OnLine Help. This file is intended
to be site-specific for any information relevant to your local
users.
<P>A sample <CODE>site.info.sample</CODE> file has been included. You
may copy this to <CODE>site.info</CODE> and modify as needed. The URLs
referenced in the sample are NCR-specific info that is not accessible
outside our firewall. However, it should be disclosed that the "End User
Guide" is the <I>Majordomo</I> chapter from the O'Reilly MIIS book, and
the "Admin Guide" is the list-admin info for new users. Both documents
are already included in the base <I>Majordomo</I> package.
<P>Images used in the OnLine Help (and also this documentation) can
be customized as well. While most of the screen capture "cutouts"
are fairly generic and suitable for all sites, the full-screen
snapshots and associated thumbnails are very specific to the
author's development site. You can tailor for your environment by
replacing the <CODE>mc_scrncap_full_[module].gif</CODE> and
<CODE>mc_scrncap_mini_[module].gif</CODE> files in the source
<CODE>/icons/</CODE> directory.
<A NAME="MIGRATE">
<H2>Migration Notes</H2>
</A>
<H3>Upgrading to 1.0</H3>
<P><I>MajorCool</I> pre-release versions prior to 1.0pre7 used a
hand-maintained configuration file. The new <CODE>Configure</CODE>
process will overwrite this file during installation.
<OL>
<LI>Save a copy of your <CODE>majorcool.cf</CODE> config file prior to
installation.
<LI>If you implemented your own <CODE>siteaddr()</CODE> functions, save
them in a "module" file within the <CODE>siteaddr/</CODE> subdirectory
of the source distribution. (See other modules for an example of the
special comments syntax.)
<LI>Specify the newly created file when prompted for which module to use.
<LI>Use your saved <CODE>cf</CODE> copy to guide you in setting the
other configuration/installation options.
</OL>
<H3>Upgrading to 1.0.3</H3>
<P>Versions prior to 1.0.3 included <CODE>siteaddr()</CODE>
examples that used the 'word boundary' regexp character (\b) to parse
addresses containing RFC822 comments. The use of the character caused
problems in some browsers due to Perl's interpretation as a backspace
character in a certain context. As of release 1.0.3, the requirement
of parsing within RFC822 comments has been eliminated, so any use of
\b in custom <CODE>siteaddr()</CODE> modules is no longer necessary.
If you implemented your own <CODE>siteaddr()</CODE> module and
utilized the \b technique, you may remove those characters.
<H3>Upgrading to 1.1.0</H3>
<P><CODE>siteaddr()</CODE> support for regular expression matching
is now optional. If pattern matching is not required for your site,
the function may return an empty string for the regexp return value.
In this case, a straight text comparison will be made against the
returned address (the 2nd element of the 3-tuple return value).
<P>If your custom <CODE>siteaddr()</CODE> function prompts for
some user interaction (e.g., picking a name from a list), there are
a number of changes that will be required:
<UL>
<LI>The browsing search qualifier '<CODE>status</CODE>' was renamed
'<CODE>criteria</CODE>', so <CODE>$arg{status}</CODE> should be
replaced by <CODE>$arg{criteria}</CODE> wherever BROWSE parameters
are passed.
<LI>A list-matching capability has been added, so the
'<CODE>list_match</CODE>' BROWSE parameter must be passed.
<LI>Due to the support of the <CODE>x-multipart-replace</CODE>
MIME type, a call to <CODE>send_done()</CODE> is necessary to properly
terminate the HTTP "push" session.
<LI><B>The <CODE>ncr-rolo</CODE> file has examples of all these changes.</B>
</UL>
<P>Versions prior to 1.1.0 did not support multiple personalities
via separate config files. The lone config file was called
<CODE>config.sh</CODE>. As of 1.1.0, <CODE>Configure</CODE> will
detect the old filename and rename it to the new default of
<CODE>default.sh</CODE>. The script will also detect an outdated
Key Cache file and re-run <CODE>mj_key_cache</CODE> for you.
Not only has an extra field been added to the keys
(<CODE>unsubscribe_policy</CODE>), but the field delimiter has
been changed.
<P>1.1.0 also adds some new icons and renames some others. It may
be prudent to delete all <CODE>mc_</CODE> prefixed icons from your
Web server image directory and let the install process add only
those needed.
<H3>Upgrading to 1.1.1</H3>
<P>In prior versions, <CODE>majorcool.info</CODE> was a standalone
file to be locally modified with site-specific <I>Majordomo</I> /
<I>MajorCool</I> info, and accessible by clicking on the <I>MajorCool</I>
banner. Unfortunately, that click action turned out to be non-intuitive.
The file is now included as part of the <A HREF="#HELP">online Help</A>
instead. If you had previously utilized this site-info file, you should
move it back into the <CODE>install/</CODE> directory as
<CODE>site.info</CODE>. The <CODE>Configure</CODE> process will do the
rest. [The corresponding $SITEINFO install variable is no longer needed.]
<H3>Upgrading to 1.1.2</H3>
<P><CODE>$list_create_cmd</CODE> and <CODE>$list_delate_cmd</CODE> have
been moved out of the <CODE>cf.common</CODE> template file and into the
config file. Jot down the values (if any) before upgrading and use them
during the 1.1.2 <CODE>Configure</CODE> process.
<H3>Upgrading to 1.3.0</H3>
<P>If you implemented the <CODE>owner</CODE> keyword as outlined
previously, it was suggested to use "address" as the subsystem name. I
have decided to change the name and leverage on the already existing
"config" naming scheme instead. The main place these names are readily
visible is in the "Subsystem" keyword group selection of the Configuration
Screen.
<H3>Upgrading to 1.3.2</H3>
<P>The behavior when using the standalone password form
(<CODE>$opt_hiddenpasswd=1</CODE>) has changed slightly to be more
like <I>Majordomo</I>. Under the previous scheme, an attempt to
change the password was converted into a <CODE>newconfig</CODE>
command <U>unless</U> the password file existed and was not linked
to a <CODE>MASTER.PASSWD</CODE> file (read-only or otherwise). This
"override" logic made it impossible to create an initial password file
via the <CODE>passwd</CODE> command.
<P>
The new command-override behavior depends on the password file being
marked as read-only rather than upon a particular naming convention; if
detected as such, the <CODE>newconfig</CODE> method will be used. Thus,
use of <CODE>$opt_hiddenpasswd=1</CODE> will equate more directly to the
traditional behavior of the <I>Majordomo</I> <CODE>passwd</CODE> command.
If you do not want to encourage .passwd files to be created, you should
treat the password change as part of the entire list configuration
process (<CODE>$opt_hiddenpasswd=0</CODE>).
<HR>
<A HREF="prereq.htm">[Previous: Requirements]</A>
<A HREF="config.htm">[Next: Config]</A>
<A HREF=".">[Top: Intro]</A>
<A HREF="..">[Home]</A>
<A HREF="mailto:Bill.Houle@SanDiegoCA.NCR.COM">[Feedback]</A>
</BODY>
</HTML>
syntax highlighted by Code2HTML, v. 0.9.1