     An important consideration in the design of AIPS has been
software portability.  As you read the rest of this volume, you will
notice many concepts which are both old fashioned and simplistic.  It
has been our feeling that portability is best obtained by using an old,
well-distributed and understood language and by keeping the methods
simple.  For example, intertask communication in AIPS is done with
one disk file and four subroutines (activate, resume, kill, and are you
active).  We do not use the substantial intertask capabilities of our
VAX and MODCOMP computers for the simple reason that they are, in
fundamental ways, different from each other and from other machines to
which AIPS may be transported.  Machine dependent operations have
been handled in two ways.  Input/output, task activation, and other
fundamentally machine-dependent operations have been isolated in a
small number of subroutines all of whose names begin with Z.  Machine-
dependent parametric information (e.g. number of disks, words per disk
granule) appear in commons initialized by Z routines and used by all
routines.  Commons are also used to convey information between Z
routines (e.g. I/O control structures).

     We have made a very serious effort to keep the code free of
machine-dependent bias toward such items as word length, character
set representation, and the like.  We believe that we have done a very
good job so far, but we presume that a perfect job is not possible.
In particular, we do presume that some machines will require a
preprocessor to translate our standard code into code acceptable to the
local compiler.  For example, VAX has the lovely concept, called
INCLUDE, which allows standard bits of code from other files to be
inserted in the program during compilation.  We use this concept to
insure uniformity in our declarations of commons and data structures.
However, our MODCOMP compiler does not have this facility.  Thus, we
run all of our routines through a preprocessor which performs the
includes on the way to the compiler.  As another example, our INTEGER*2
statements will have to be preprocessed into INTEGER*3 statements for
Harris 24-bit computers.

     The point of all this software is the data.  We obtain data from
magnetic tape, translate it, and store it in files on disk.  Each
logical collection of data, called "image", resides in a separate disk
file.  Attached to this file in a logical, but not physical, sense are
various "extension" files used to contain history, plotting instruc-
tion, etc. data related to the image.  The "header", which describes
the image, is stored in a catalog file.  This file catalogs all images
on the disk and keeps track of their activity.  All programs have
access to this catalog and, through it, to all images.  There is a
catalog file on each disk in the system.  This, together with a few
other coding practises, allows users to have their own disk packs (if
their system has more than one disk drive).

     Within this manual we use terms such as "word", "byte", and
"integer".  Within AIPS, these terms have a somewhat abnormal meaning.
Both word and integer mean to us the smallest standard integer on the
local machine (i.e. 16 bits on VAX and MODCOMP, 60 bits on CDC).  A
byte is one-half of a word (i.e. 12 bits on a Harris, 30 bits on a
CDC).  We assume that a floating point value requires an integer
number of words and that an integer number of characters (>= 4) fit
more or less neatly into a floating-point value.  These words assume
standard meanings, however, when data are read from or written to
magnetic tape.  For such data communication, we conform to the FITS
standards (see Chapter X).
     We should also mention our hardware setup:

(1) CPU - Vax 11/780 and Modcomp Classic 7860

(2) Disks - 180-Mbyte drives with 3 on Modcomp and 4 on Vax

(3) Tape drives - 1600 bpi required, more than one is supported in the
    software.  Vax has one drive, the Modcomp has two.

(4) Array processor - Floating Point Systems AP120B with 64K words of
    memory.  Used only by special spawned tasks.

(5) TV display - Stanford Technology Corp IIS with 4 512X512 8-bit
    memories, 4 512X512 1-bit graphics planes, trackball, and more.

(6) Line printer - dot matrix printer-plotters, Varian on Modcomp and
    Versatek on Vax.

(7) Terminal - any terminal will probably do.  We use Tektronix 4025
    for its large roll-down memory and future potential.

(8) Monitor - any terminal screen with auto-scroll and no keyboard.
    Used for messages from tasks spawned by AIPS.  Ours is a
    Tele-Tec Data-Screen 1440.

(9) Graphics display - erasable, line-drawing.  We use Tektronix 4012.
