136.latex

\documentstyle{article}
\textwidth=6.25in
\textheight=9.0in
\oddsidemargin=0mm
\evensidemargin=0mm
\parindent=5mm
\parskip=0mm
\headsep=10mm
\headheight=4mm
\topmargin=-10mm
\raggedbottom
\pagestyle{headings}

\def\~{{\char'176}}
\newcommand{\AIPS}{{$\cal AIPS$}}
\newcommand{\aipspp}{{\bf AIPS{\tt ++}}}

\begin{document}

\centerline{\Huge\bf System management for \aipspp}
\bigskip
\centerline{\LARGE\bf Report on progress to 1992/May/06}

\bigskip
\bigskip
\bigskip
\centerline{\Large\it Mark Calabretta}
\centerline{\aipspp\ programmer group}
\centerline{1992/May/06}

\bigskip
\bigskip
\bigskip

\section {Introduction}

The design of the \aipspp\ system has been described in two previous
documents ``System management for \aipspp\ - Part 1: organization and
distribution'', and ``Part 2: activation, generation, and verification''.
A report describing progress to 1992/Mar/14 was delivered to the March
\aipspp\ steering committee meeting in Socorro.  This paper describes further
progress in implementing the design, particularly concerning the code
distribution system.

Most of the major functional elements of \AIPS\ system management are now
present to some extent in \aipspp.  Although not necessarily a good indicator
of progress, the statistics of code written may be of interest:

\begin{verbatim}
                                       shell scripts:  2778
                              aipsinit and aipshosts:   354
                 aipsrc, aipsrc templates, and getrc:   260
         makefiles, makedefs, and makedefs templates:  1417
                             man pages for the above:   676
                                                       ----
                                               total:  5485
\end{verbatim}

\noindent
Development will be required throughout the life of \aipspp, but I would
estimate very subjectively that the system is about 70\% complete, 


\section {The directory tree}

The \aipspp\ code and system directories have been implemented essentially as
described in the original documents.  One issue which was not canvassed
previously is the location of the {\it RCS} source code repositories.  These
have been implemented as a separate and parallel directory hierarchy under
{\tt \~aips++/master}.  At the moment the source code management consists of
plain {\it RCS}, but this structure will readily accomodate {\it CVS}.
Plain-text copies of the code are kept under the {\tt \~aips++/code} tree as
originally planned.

Another point of departure from the original design has been to incorporate
the {\it ftp} directories directly under {\tt \~aips++}.  This was prompted by
the realization that {\tt \~aips++} could itself be NFS mounted under
{\tt \~ftp}, thereby circumventing the {\it chroot} limitation imposed by
anonymous {\it ftp}.  All of \aipspp\ is now available for access via this
method.

One modification required to meet this change was that of renaming the
{\it ftp} directories so that they could be accomodated under {\tt \~aips++}.
Certain other minor changes were also made, particularly with respect to the
code distribution files.  The structure currently resembles the following:

\pagebreak
{\tt \begin{verbatim}
         +--- import ----+---...
         +- import_ftp --
         |                
         |               +--- install ---+----- cpp -----
         |               |               +---- lwf_a ----
         |               |
         |               |               +--- include ---
         |               |               +-- implement --
         |               +--- kernel ----+--- scripts ---
         |               |               +---- data -----
         |               |               |               +---- PBook ----
         |               |               +----- doc -----+---- memos ----
         |               |                               +---- notes ----
         |               |                               +----   :
         +---- code -----+
         |               +-- synthesis --+...
         |               +---- vlbi -----+...
         |               +---- dish -----+...
         |               +---- atnf -----+...
         |               +---- bima -----+...
         |               +---- drao -----+...
         |               +---- nfra -----+...
         |               +---- nral -----+...
         |               +---- nrao -----+...
         |               +---- tifr -----+...
         |               +--- contrib ---+...
         |                
         +-- code_ftp ---
         |                
      ---+
         |               +--- install ---+----- cpp -----
         |               |               +---- lwf_a ----
         |               |
         |               |               +--- include ---
         |               |               +-- implement --
         |               +--- kernel ----+--- scripts ---
         |               |               +---- data -----
         |               |               |               +---- PBook ----
         |               |               +----- doc -----+---- memos ----
         |               |                               +---- notes ----
         |     master    |                               +----   :
         +---- {rcs} ----+
         |     slave     +-- synthesis --+...
         |               +---- vlbi -----+...
         |               +---- dish -----+...
         |               +---- atnf -----+...
         |               +----  :
         |
         +-- master_ftp -
         |
         :
         :
\end{verbatim}}

\pagebreak

A typical \aipspp\ installation would only have the {\tt import} and
{\tt code} subdirectories.  Consortium sites would also have the
{\tt import\_ftp}, and {\tt code\_ftp} subdirectories for redistribution of
\aipspp\ source code to local \aipspp\ recipients.  Consortium sites other
than Charlottesville will also have a {\tt slave} subdirectory containing a
copy of the master {\it RCS} files.  Charlottesville will instead have the
{\tt master}, and {\tt master\_ftp} subdirectories, the latter of which
contains updates for the slave subdirectories at the other consortium sites.

All \aipspp\ installations will have system directories with a structure
similar to the following, except that only consortium sites will have
{\tt ftp} subdirectories:

{\tt \begin{verbatim}
         :
         :
         |
         +---- data -----+...
         |
         |                               +----- lib -----
         |                               +--- libdbg ----
         |                               |
         |                               +----- bin -----
         |                               +--- bindbg ----
         |                               |
         |                               +----- tmp -----
         |                               +--- tmpdbg ----
         |                               |
         |                               +---- data -----
      ---+                               |
         |               +---- apex -----+
         |               |               |               +---- ascii ---
         |               |               |               +---- info ----
         |               |               +----- doc -----+---- manl ----
         |               |               |               +---- catl ----
         |               |               |               +----  :
         |               |               |
         |               |               |               +---- msgs ----
         +---- sun4 -----+               +--- (site1) ---+--- (host1) --
         |               |               |               +--- (host2) --
         |               |               |               +---   :
         |               |               |
         |               |               +--- (site2) ---+...
         |               |               +---    :
         |               |
         |               +---- base -----+...
         |
         +-- sun4_ftp ---
         |
         +--- (arch2) ---+...
         +- (arch2)_ftp -
         +---   :
\end{verbatim}}

\noindent
This hierarchy is identical to that originally envisaged.


\section {Distribution}

Packaging of the \aipspp\ source code for distribution to end-users, and also
of updates for the {\it RCS} repositories to consortium sites, is handled at
Charlottesville by a single script called {\it exhale}.  {\it exhale}'s
behaviour is determined by the contents of, and last modification time of the
{\tt VERSION} file in {\tt \~aips++/master\_ftp}.

If the {\tt VERSION} file contains the string ``{\tt mm.-}'', where {\tt mm}
is a two digit number which defines the major version number, {\it exhale}
interprets this as a signal to produce a new base release.  It produces a
compressed tar file for the {\tt \~aips++/master} tree, and also for each of
the {\tt \~aips++/code} subdirectories.  If all goes well it then installs
these in the {\tt \~aips++/master\_ftp} and {\tt \~aips++/code\_ftp}
directories.  If this succeeds, {\it exhale} finishes by installing a new
{\tt VERSION} file containing the major and minor version number with a
timestamp and file modification time pertaining to when {\it exhale} started
execution.

If, on the other hand, {\it exhale} finds a string of the form
``{\tt mm.nnn}'' in the {\tt VERSION} file, where {\tt nnn} is the minor
version number, it will produce an update for the {\tt \~aips++/slave}
repositories at the consortium sites.  Incremental updates consist of a
compressed tar file containing all files in the {\tt \~aips++/master}
repository which are newer than the {\tt VERSION} file itself.  In addition,
it produces a cumulative update which consists of all {\tt master} files
modified since the base release for the current major version.  Only after
successfully installing these in {\tt \~aips++/master\_ftp} does it update the
{\tt VERSION} file.

The {\tt master} guarantees to create two new updates per day for the
{\tt slave}, one by 0700 and the other by 1900 Charlottesville time via
{\it cron} jobs which activate {\it exhale} a half-hour beforehand.

{\it exhale} maintains a {\tt LOGFILE} which it updates every time it
executes.  It is designed to be {\it fail-safe}, and to date it has operated
flawlessly for about a month, except on one occasion when it ran out of disk
space and did fail safe.  The \aipspp\ {\tt ftp} directories currently contain
the following:

{\tt \begin{verbatim}
                         +--- README
                         +--- VERSION
                         +--- compress-4.0.1.tar
                         +--- cpp-0.00.tar.Z
         +- import_ftp --+--- make-3.62.tar.Z
         |               +--- make_doc-3.62.tar.Z
         |               +--- perl-4.019.tar.Z
         |               +--- rcs-5.6.tar.Z
         |
         |               +--- LOGFILE
         |               +--- README
         |               +--- VERSION
         |               +--- atnf-00.000.tar.Z
         |               +--- bima-00.000.tar.Z
         |               +--- configure
         |               +--- contrib-00.000.tar.Z
         |               +--- dish-00.000.tar.Z
         |               +--- drao-00.000.tar.Z
      ---+-- code_ftp ---+--- install-00.000.tar.Z
         |               +--- kernel-00.000.tar.Z
         |               +--- nfra-00.000.tar.Z
         |               +--- nral-00.000.tar.Z
         |               +--- nrao-00.000.tar.Z
         |               +--- synthesis-00.000.tar.Z
         |               +--- tifr-00.000.tar.Z
         |               +--- vlbi-00.000.tar.Z
         |
         |               +--- LOGFILE
         |               +--- README
         |               +--- VERSION
         +-- master_ftp -+--- master-00.000.tar.Z
                         +--- master-00.001.tar.Z
                         +--- master-00.002.tar.Z
                         +--- master-00.003.tar.Z
                         +--- master-00.003.ALL.tar.Z
\end{verbatim}}

At the remote consortium sites a script called {\it inhale} fetches the latest
consortium updates and applies them.  On its first invokation {\it inhale}
constructs the {\tt \~aips++/slave} subdirectory and fetches the base file
plus cumulative update.  Thereafter it maintains a {\tt VERSION} file in
{\tt \~aips++/slave}, and decides which incremental updates it needs to fetch
from Charlottesville on the basis of the version stored therein.  It does,
however, accept a ``{\it -c}'' option which forces it to fetch the cumulative
update.  This should be done every once in a while at the remote site in order
to ensure that the {\tt slave} is faithfully synchronized with the master.

After fetching the compressed tar files {\it inhale} unloads them in reverse
order.  It then invokes GNU {\it make} to recursively rebuild \aipspp.
{\it inhale} also maintains {\tt VERSION} files in {\tt \~aips++/code} and
{\tt \~aips++/\$ARCH}.  There are corresponding {\tt LOGFILE}s for each of the
three {\tt VERSION} files used by {\it inhale}

Like {\it exhale}, {\it inhale} is designed to be {\it fail-safe} and can be
invoked at any time.  However, it should normally be invoked by {\it cron}
after 1900 hours local time, and not within an hour of the time scheduled for
{\it exhale} to run in Charlottesville.  It works directly on
{\tt \~aips++/slave} so there should never be any danger of it overwriting
{\tt \~aips++/master}.


\section {Installation}

Installation of \aipspp\ is under the control of a script called
{\it configure}.  One of {\it exhale}'s jobs in creating a new base release is
to install the latest version of the {\it configure} script in
{\tt \~aips++/code\_ftp}.  Intending users of \aipspp\ would {\it ftp}
anonymously to their local consortium site and fetch the entire contents of
{\tt \~ftp/pub/aips++/code\_ftp}.  In detail, the sequence would resemble the
following:

{\tt \begin{verbatim}
   yourhost% mkdir ~aips++
   yourhost% chgrp aips2mgr ~aips++
   yourhost% chmod 775,g+s ~aips++
   yourhost% mkdir ~aips++/code
   yourhost% cd ~aips++/code
   yourhost% ftp baboon.cv.nrao.edu
   Connected to baboon.cv.nrao.edu.
   220 baboon FTP server (SunOS 4.1) ready.
   Name (baboon.cv.nrao.edu:you): ftp
   331 Guest login ok, send ident as password.
   Password:you@yourhost.there
   230 Guest login ok, access restrictions apply.
   ftp> cd pub/aips++/code_ftp
   250 CWD command successful.
   ftp> binary
   200 Type set to I.
   ftp> prompt
   Interactive mode off.
   ftp> hash
   Hash mark printing on (8192 bytes/hash mark).
   ftp> mget *
        :
     lots of messages describing what ftp is fetching
        :
   ftp> quit
   221 Goodbye.
   yourhost% chmod 544 configure
   yourhost% configure
\end{verbatim}}

Once {\it configure} has been activated the installation consists of answering
a few questions, most of which have sensible default answers.  {\it configure}
first ensures that certain utilities that it needs are available
({\it compress} and GNU {\it make}).  If they aren't it will fetch them from
the consortium site and if necessary, install {\it compress} in the current
directory.  It then unloads any compressed tar files present in the current
directory.

{\it configure} next installs the {\it aipsinit} scripts (see below) and
constructs the {\tt \~aips++/aipshosts} database via a simple inbuilt editor.
Once the host architectures, site-, and host-names are known, {\it configure}
invokes {\it aipsinit} for itself and then creates the \aipspp\ system
directory tree for each architecture.  With a {\tt bin} directory now in
existence, {\it configure} reinstalls {\it compress} if necessary, and
likewise GNU {\it make}.

Before {\it make} can be invoked, however, the site-specific {\tt makedefs}
file must be defined.  This contains definitions used by {\it make} for
directories, compiler options and the like.  Generic definitions are provided
in {\tt \~aips++/\$ARCH/\$VERS/makedefs} but several of these have no sensible
default and must be defined on a site-wide basis.  If none already exists,
{\it configure} installs a template {\tt makedefs} file in
{\tt \~aips++/\$ARCH/\$VERS/\$SITE} and invites the installer to make the
appropriate entries with a text editor in another window (or by suspending
{\it configure}).  When the user is satisfied, {\it configure} checks to make
sure that all definitions have been made, and then repeats the process for the
site-specific {\tt aipsrc} file (see below).

At this point the system should have been bootstrapped to a state where a
recursive {\it make} may be used to check-out all code and rebuild the system,
and this {\it configure} now does.


\section {\it aipsinit}

   \aipspp\ programmers and users define their \aipspp\ ``environment'' by
means of the {\tt aipsinit.[c]sh} scripts.  One or other of the two scripts
can be used for Bourne-like shells ({\it sh}, {\it bash}, {\it ksh}), or
C-like shells ({\it csh}, {\it tcsh}).  {\it aipsinit} defines a single
environment variable, {\tt AIPSPATH}, which contains five space-separated
character strings describing the root of the \aipspp\ directory tree, the host
architecture, the \aipspp\ version, the local site name, and the local host
name.  This information is fundamental and must be known in order to access
the {\tt aipsrc} databases.  {\it aipsinit} also redefines the {\tt PATH} (and
{\tt MANPATH}) environment variables, adding the \aipspp\ binary (and man
page) directories to it.  The user can control the precise position of the
\aipspp\ binary directories in {\tt PATH}, or else can accept the default of
prepending it (after ``.'' it that was first).


\section {Source code management}

A set of \aipspp\ accounts and groups have been defined to perform the
following functions:

\begin{itemize}
\item
     {\it aips2mgr} (uid=31415, gid=31415): Owns the \aipspp\ directories, and
     all {\it RCS} and {\it ftp} distribution files.  {\it aips2mgr}, and
     those in the {\it aips2mgr} group, are {\it RCS} and {\it ftp}
     administrators for \aipspp.  In particular, they can directly invoke the
     {\it rcs} command on the \aipspp\ {\it RCS} files.  {\it aips2mgr} will
     have an active login account only on selected machines.  {\it aips2mgr}
     is responsible for maintaining the {\tt ftp} directories, and in
     particular, runs the daily {\it exhale} and {\it inhale} cron jobs.

\item
     {\it aips2prg} (uid=31416, gid=31416): A generic programmer account,
     although in practice this may not often be used.  The {\it aips2prg}
     group lists those who have permission to check code into \aipspp, or
     check it out with a write lock (anyone can check code out without a write
     lock).

\item
     {\it aips2usr} (uid=31417, gid=31417): The {\it aips2usr} account itself
     could serve as a generic \aipspp\ usage account if this is so desired.
     The {\it aips2usr} group could be used to control access to \aipspp\
     executables and \aipspp\ data areas if this degree of control is desired
     by the \aipspp\ administrator (the alternative being to give world execute
     and/or write permission).

\end{itemize}

Remote consortium sites with access to the {\it internet} can choose to NFS
mount the {\tt master} \aipspp\ {\it RCS} directories on their local
development machines.  This is most conveniently done via the {\tt /net}
{\it automounter} map.  All that is required is for the fully qualified
hostname to be entered in the {\it aips2-consortium} netgroup which has been
created at Charlottesville for the purpose.  A symbolic link is created at the
remote site as

\begin{verbatim}
   ~aips++/master -> /net/baboon.cv.nrao.edu/aips2/aips++/master
\end{verbatim}

\noindent
This gives a view into the {\tt master} {\it RCS} repositories in addition to
the local copy in

\begin{verbatim}
   ~aips++/slave
\end{verbatim}

\noindent
which is updated once a day.  All \aipspp\ makefiles access the {\it RCS}
repositories via a symbolic link

\begin{verbatim}
   ~aips++/rcs
\end{verbatim}

\noindent
which is set to point to one or the other.  At remote sites it normally points
to {\tt slave} and in Charlottesville it always points to {\tt master}.

When a library or executable is rebuilt, the local {\tt rcs} directories are
normally the ones consulted.  However, it is possible to reset the {\tt rcs}
``switch'' to {\tt master} at a remote site to cause {\it make} to checkout
and/or rebuild \aipspp\ from the {\tt master} repositories.  This has been
tried at ATNF Epping with encouraging results.

\aipspp\ programmers create their own ``shadow'' representation of the
\aipspp\ code directory tree by using the {\it mktree} utility which also
creates symbolic links into the {\tt \~aips++/master} directories.  They then
appear to have their own private workspace with a window directly into the
master {\it RCS} repositories at Charlottesville.  Whenever they check code
out of, or into the system from their private work area they will be dealing
directly with the {\it RCS} repositories in Charlottesville.

Source code checkin and checkout is mediated by {\it ai} and {\it ao}.
{\it ai} activates its alter-ego, {\it ai\_master}, which resides in the
{\tt \~aips++/master} directory itself, and runs setuid to 31415 -
{\it aips2mgr}'s uid in Charlottesville.  This mechanism allows programmers at
remote sites to check code into Charlottesville, which will certainly have a
different set of uids and gids to those at their own site.  The remote
consortium sites will, however, be encouraged to adopt the uids and gids
defined at Charlottesville for \aipspp.  These were deliberately chosen to be
large random numbers to minimize the likelihood of conflict with the remote
site's set of uids and gids. 

Whenever code is checked in to the {\tt master}, {\it ai} updates the local
{\tt slave} copy (if present - and it won't be at Charlottesville), and also
the plain text copy in {\tt \~aips++/code}.  Since the {\tt slave}
repositories are owned by the local {\it aips2mgr}, {\it ai} itself runs
setuid to its uid (hopefully also 31415).

{\it ai}'s counterpart, {\it ao}, has a similar alter-ego called
{\it ao\_master} which operates in precisely the same way as {\it ai\_master},
thereby allowing code to be checked out of the {\tt master} with a lock on it
(which requires write permission on the {\it RCS} version file).

A third useful utility, {\it au} runs setuid to the local {\it aips2mgr}
account and updates {\tt slave} (if present) and {\tt code} with the named
files from the {\tt master}.


\section {System generation}

POSIX.2 compliance for {\it make} applies largely to the way makefiles
themselves are written, and essentially restricts functionality to the lowest
common denominator of all the many varieties of {\it make}.  This means it
would be it very difficult to write portable POSIX.2 compliant makefiles for
\aipspp, so GNU {\it make} has been adopted instead.  GNU {\it make} is itself
POSIX.1 and POSIX.2 compliant, and so satisfies the ``POSIX compliance''
criteria originally set for \aipspp.

\aipspp\ uses a hierarchical system of GNU makefiles.  The head resides in
{\tt \~aips++/code} and recursively invokes all makefiles residing in the
subdirectories beneath it.  The makefiles have the following features:

\begin{itemize}
\item
   The makefiles ``{\it include}'' architecture, site-, and possibly
   host-dependent {\tt makedefs} files which allow local definitions to
   override the defaults, for example, architecture-specific libraries, the
   location of directories, compiler options, etc.

\item
   The makefiles recognize that the \aipspp\ installation may or may not have
   a copy of the {\tt rcs} repositories.  If the repositories are present,
   {\it make} automatically updates the plain-text copy if necessary.  This
   should rarely be necessary though since {\it ai} keeps it up-to-date.

\item
   The makefiles all contain a {\tt makefile} target thereby causing GNU
   {\it make} to invoke its clever mechanism which ensures that makefiles
   remake themselves before attempting to remake anything else.

\item
   Programmer workspaces are supported by means of GNU {\it make}'s
   {\tt VPATH} function.  If the programmer has a {\tt .h} or {\tt .C} file in
   the current directory it will be used instead of those in the {\tt code}
   areas.  In this case the \aipspp\ libraries and executables will not be
   updated.  Instead, the preprocessed code, object module, and/or executable
   will be left in the programmer's own directory.

\item
   The makefiles construct lists of dependency files via GNU {\it make}'s
   {\tt wildcard} function.  Any {\tt .h} or {\tt .C} file in the relevant
   {\tt code} directory (or {\tt rcs} directory if present) is automatically
   included.

\item
   Any subdirectory is recognized as a target.  The {\tt allsys} target of the
   makefile in the subdirectory is invoked.  (This does not apply to
   {\tt include} subdirectories which do not have makefiles but instead rely
   on the {\tt implement} makefile for targets such as {\tt chkout}).

\item
   The {\tt implement} makefiles know about the {\tt TESTBED} mechanism by
   which class test programs are embedded within the class implementation
   files in an ``{\tt \#ifdef TESTBED}'' wrapper.  Executables for the class
   test programs are handled by a pattern rule triggered by appending
   {\tt TEST} to the class name.

\item
   The diagnostic targets {\tt test\_def} and {\tt test\_env} can be invoked
   for informational and debugging purposes.
\end{itemize}

\noindent
By allowing programmers to compile code in their own workspace without having
to extract related files from the {\tt rcs} repository, the makefiles minimize
the number of files that need to be present in the programmer's own workspace.
This reduces the possibility that these may be ``stale''.

The \aipspp\ makefiles use a standard set of target names; references to a
directory in the following list refers to the directory in which the makefile
exists, or the corresponding \aipspp\ directory:

\begin{itemize}
\item
   {\tt all} (programmer): Remake all object modules, executables, etc. from
   files in the current directory.

\item
   {\tt allsys} (system): Remake all object modules, executables, etc. from
   files in the \aipspp\ directory.

\item
   {\tt clean} (programmer): Delete ``rubbish'' files in the current
   directory.

\item
   {\tt cleansys} (system): Delete ``rubbish'' files in the \aipspp\
   directory.

\item
   {\tt chkout} (system): Update the \aipspp\ {\tt code} directories by
   checking out files from the {\tt rcs} directory as required.

\item
   {\tt makefile} (general): Update the makefile itself by checking it out of
   the {\tt rcs} directory, or (for programmers) copying it from the \aipspp\
   {\tt code} directory.

\item
   {\it class}{\tt .i} (programmer): Preprocess class implementation file
   {\it class}{\tt .C} (from the current directory if present) and leave it in
   the current directory.

\item
   {\it class}{\tt .o} (programmer): Recompile class implementation file
   {\it class}{\tt .C} (from the current directory if present) and leave it in
   the current directory.

\item
   {\it class}{\tt TEST} (programmer): Recompile the class test program for
   {\it class}{\tt .C} (from the current directory if present) and leave it in
   the current directory.

\item
   {\tt lib({\it class}.o)} (system): Remake an object module
   {\it class}{\tt .o} from {\it class}{\tt .C} in the \aipspp\ directory and
   replace it in the library 

\item
   {\tt lib} (system): Remake the object library associated with an
   {\tt implement} directory.

\item
   {\tt ranlib} (system): {\it ranlib} the object library.

\item
   {\it applic} (progammer): Recompile application {\it applic}{\tt .C} and
   leave it in the current directory.

\item
   {\tt bin/}{\it applic} (system): Recompile application {\it applic}{\tt .C}
   in the \aipspp\ directory and install it in the {\tt bin} directory.

\item
   {\tt bin} (system): Recompile all applications in the \aipspp\ directory.

\item
   {\tt test\_env} (general): Print out all relevant {\it make} variables
   defined within the makefile.

\item
   {\tt test\_def} (general): Print out all relevant {\it make} variables
   defined in the {\tt makedefs} files included by the makefile.
\end{itemize}

Library maintenance requires special attention to avoiding conflicts which may
arise when two programmers independently try to update the library.  This is
handled by a script used by the makefiles called {\it updatelib}.  Object
modules are deposited by {\it make} in a library-specific subdirectory of
{\tt ~aips++/\$ARCH/\$VERS/tmp}, for example {\tt ...tmp/libkernel}.  When all
modules have been produced the makefile invokes {\it updatelib} which copies
the library to the temporary area, updates it, {\it ranlib}s it, then copies
it back to the {\tt lib} area.


\section {System databases}

   The {\tt aipsrc} databases have been implemented via a {\tt C}-program
called {\it getrc}.  It looks for device and other definitions in a format
similar to that of the {\tt .Xdefaults} database used by {\bf X-windows}.  In
resolving a reference it searches the following sequence of {\tt aipsrc}
files:

\begin{verbatim}
      ~/.aipsrc
      $AIPS/$ARCH/$VERS/$SITE/$HOST/aipsrc
      $AIPS/$ARCH/$VERS/$SITE/aipsrc
      $AIPS/$ARCH/$VERS/aipsrc
\end{verbatim}

The last of these contains default values, and the other three allow these to
be overridden on a user-, host-, and site-specific basis.  A {\it -i} option
provides for {\it getrc} to ignore the user's {\tt aipsrc} file - it would not
be appropriate for them to override access restrictions set by the local
\aipspp\ administrator for example.  A {\it -v} option causes {\it getrc} to
indicate how it resolved the reference, and is useful for debugging.

   The {\tt aipsrc} mechanism works well and {\it getrc} is now used in a
number of \aipspp\ scripts, including a simple and easily configurable set of
printer utilities, and a utility for printing class header and implementation
files in a compact and convenient form. 


\section {Future work}

The following list indicates some areas of development/refinement in \aipspp\
system management.  Some of the jobs listed could be done in under an hour,
others would take several days.

\begin{itemize}
\item
   {\it exhale} should limit the number of incremental update files maintained
   in {\tt \~aips++/master\_ftp} to about two-weeks worth.

\item
   {\it exhale} should create a new {\it RCS} version when it creates a new
   base release.

\item
   When {\it inhale} fetches a new base release from the {\tt master} it
   should also update the {\tt import\_ftp} and {\tt code\_ftp} directories
   for redistribution to local end-users.

\item
   Bug fixes should be stored in {\tt \~aips++/code\_ftp} and a special-purpose
   script should be provided to fetch and apply them.  {\it configure} needs
   to know that bug fixes must be unloaded {\em after} the base release files.

\item
   As far as is possible, {\it configure} should check to see that entries
   made in the {\tt makedefs} and {\tt aipsrc} files are valid.

\item
   Deletions from the {\tt master} must be propagated to the {\tt slave}.

\item
   {\it updatelib} should test library modules (other than {\tt Input.o}) to
   ensure they don't contain a {\tt main()}.

\item
   {\it ai} should test the code being checked in to ensure that it conforms
   to \aipspp\ coding style rules.

\item
   All of the \aipspp\ shell scripts are written in Bourne shell.  It may be
   advantageous in the long run to convert them to {\it perl} which is
   probably more portable.  The exceptions are {\it aipsinit}, which must have
   Bourne and C-shell versions, and {\it configure} which can't assume that
   {\it perl} is available, and would have to install it if it wasn't.

\item
   man pages are required for {\it ai}, {\tt aipshosts}, {\it ao}, {\it au},
   {\it configure}, {\tt makedefs}, and {\it updatelib}.

\item
   Makefile enhancements:

\begin{itemize}
\item
      At the moment {\it make} will recompile everything if one header file
      has been changed because the makefiles don't contain a proper dependency
      analysis.  Dependency information should be generated.

\item
      Separate optimized/nodebug (sharable) and nooptimize/debug (static)
      libraries should be maintained.

\item
      Library and application rebuilds should be structured in such a way that
      several machines can work together to rebuild the system.

\item
      The {\tt makefile} target in all makefiles should copy from the \aipspp\
      code directory if no {\tt rcs} directory is present.

\item
      Directory search should be used for link libraries.

\item
      A makefile is required for the {\tt \~aips++/code/kernel/doc} areas.
\end{itemize}
\end{itemize}

\end{document}