AUTOFILE HP-71B/9114A/82161A MEDIA MANAGEMENT SYSTEM

The purpose of AUTOFILE is to render maximally transparent
the process of udating on disc any RAM files that have
been altered while the 71 is not connected to the HP-IL.
For why?  Well, on a desktop, which is always connected
to its mass storage, an operator altering a (say) text
file, using Wordstar etc, simply makes the alteration.
The process of actually writing the alteration to disc
is transparent. If any 71 files are altered while the
machine is disconnected from its mass memory, a consciously
directed recording process has to be carried out on return
to base.  If there are many files in the 71, only some
of which were altered, and many files are recorded onto
more than one media - for backup and/or thematic purposes
- the housekeeping involved can become arduous, and is
a point of MAJOR USER-INTERFACE DISCOMFORT when comparing
the 71, as a "personal" computer, to computers that have
permanently online mass storage.  This system provides
a means of automatically tracking changes to RAM files
(using the file checksum LEX function by John Baker [619]),
with full manual override.  When the mass memory drives
are online a single command can be used to initiate the
recording process, during which the operator simply inserts
the discs required, as prompted (look no keys).  Works
for up to 16 primary addressed 9114s or 82161As on the
loop, in any combination.  At each prompt to load media
the 71 senses which drive is being loaded and proceeds to
address that until another is used.  Files are collated
by volume label so that each medium has to be inserted
only once for all the files directed to it to be recorded.

The system is very flexible in terms of where its own files
live (i.e. in RAM or on mass memory).  In this version it's
as in my setup, where a particular disc contains the system's
index and program files, which are loaded, as required, by a
loading/initializing routine kept in 71 RAM, so that that
particular disc has to be loaded first to get things rolling.
However, the files involved are quite compact, and rearranging
the code to make its operation even automaticer by keeping
the whole thing in main memory (RAM or, except for the
mutable TEXT files, EP/ROM) is simple.  A more generalized
controlling subprogram would be easy to write, has been
thought of, but is not here included.  Whaddayaknow.

The system uses volume labelled media, and assumes that
all names, both volume label and filename, are unique (a
filename may appear on several media, but if so it is
assumed that the corresponding recorded sectors are copies
of each other; a volume label may appear on several media,
but if so it is assumed that the media concerned are copies
of each other).

Two TEXT files direct the flow of updating sessions.  Both
are maintained by the system, and either may also be altered
at will by the user.  One is a list of 71 file names.
When the update routine is run, any files in 71 main memory
corresponding to names on this list will be copied onto
the appropriate media.  The second is a list of files which
the system should "auto" track.  Before any media update,
any files in 71 main memory corresponding to the names
on this list will be checksummed.  If the checksum of any
file differs from it's checksum at the last updating then
it's name is added to the list of files to update, thus
effecting an "automatic" update.

A third TEXT file contains the filenames of every file
on every media, by volume label, and is used at update time
to collate the recording of files.  This file, also, can
be altered at will, but more radically.  The first two
files have a very simple but rigid format, while this index
file may be substantially reformatted for alternative uses,
and carry embedded annotations for humans or other systems
sharing the same index, etc, yet still work properly within
the updating system.  If maintenance of this file is left
to the system any fancy formatting and annotation will
be unformatted and unannotated on the next index update
of the volume label concerned, but the collating algorithm
that runs at update time has been written to work with
a wide variety of index formats if required.

Several subprograms perform the work of system maintenance.
One prompts the user to load a disc, then proceeds to create
or update an index for that disc (with an option to alter
the volume label).  A second, called with a filename
parameter, creates and maintains the list of files to be
updated, checking against duplications of the same filename,
etc, before adding the passed parameter to the list.  A
third scans the specified "auto-update" files, adding their
names to the list of files to update if they have been
altered since the last scan.  A fourth co-ordinates the actual
loading/copying process.  Additional lower-level subroutines
perform discrete general purpose support functions, and
a short supervisory routine co-ordinates things.  In
addition, a driver for the HP (or any other) text editor,
and a single key assignment, providing more flexibility
in the user interface, are included.  Some of the subprograms
may be used in other, quite different, mass media routines
(c.f. DISCOPY for "user friendly" mass 92192A copying) and
notes on their operation appear in the AFSUBS file).