Trailing-Edge - PDP-10 Archives - BB-L288A-RM - swskit-documentation/archive.mem
There are 5 other files named archive.mem in the archive. Click here to see a list.












DEC archive system spec                                     Draft
Implementation details

          This  section  will  describe  the  tasks  DUMPER  must
perform   to  support  the  Archive/Virtual  Disk  system.   This
includes copying files to tape, removing the contents from  disk,

          DUMPER  will not contain any of the policy for deciding
when files may be copied to tape and have their contents  removed
from  the  disk.   This  task  is performed by REAPER, the policy
module for the Archive/Virtual Disk system.  Instead, DUMPER will
only dump those files marked  for  voluntary  archival  or  those
files  past  their  expiration  date  or  marked  for involuntary
migration, depending on which function  the  operator  wishes  to
perform.   The process of dumping files to tape will be called an
archival run if voluntary archivals are  being  processed,  or  a
collection  run  if  involuntary  migrations  and expirations are
being processed.  In either case, the operation is  very  similar
to  performing  an  incremental  dump.   The  command  syntax for
performing an archival run is "DUMPER>SAVE/ARCHIVE  PS:<*>*.*.*";
the   syntax   for  an  collection  run  is  "DUMPER>SAVE/COLLECT
PS:<*>*.*.*".  Alternatively, the switch "/MIGRATE" can  be  used
in  place of "/COLLECT" to process files marked for migration and
ignore files which have expired.  Naturally, any filespec can  be
used  in these commands.  If no filespec is given, the default is
to process all files on the connected structure.

          Each archival or collection run consists of two logical
passes.  During the first pass, selected files  are  copied  onto
tape.   When  this  pass is complete, a second "clean up" pass is
made to mark data as valid and delete the disk contents of  those
files  which  have been reliably copied to two tapes.  (If a file
is being archived, and AR%NDL is set, then the disk contents  are
not deleted.)

          Now  in detail, here is what DUMPER will do during each
pass of the archival or collection run.  Pass  1:   Examine  each
file  in  the specified path.  If this is an archival run and the
file is marked for voluntary archival, or if this is a collection
run and the file is past its expiration  date  (/COLLECT)  or  is
marked for involuntary migration (/COLLECT or /MIGRATE), then set
AR%1ST  in  the  file's  FDB  to indicate that a DUMPER run is in
progress.  Then, set the tape information in  the  FDB  via  ARCF
(.ARSST),  and  dump  the  file  to tape.  This process continues
until all files in the path have been examined.   At  this  point
DUMPER  ends the saveset on the tape and rewinds it.  Pass 2, the
clean up pass, now begins.  Once again the file path is  scanned,
and  any  file  with  AR%1ST set is considered.  First, AR%1ST is
cleared, thereby marking  the  file  contents  valid.   The  tape
information is then examined, and if it is complete (the file has
been  dumped successfully to two tapes), ARCF (.ARFSH) is invoked
to delete the disk contents.  If this is an archival run,  FB%INV
is  set  to  make  the file invisible.  Finally, ARCF (.ARCLR) is

                              - 1 -

DEC archive system spec                                     Draft
Implementation details

invoked to clear the request bits.  At the end of each  directory
(GNJFN  notes this by GN%DIR being returned) a message is sent to
the owner listing all files that have been successfully copied to
two tapes.  This process continues  until  all  files  have  been

          Should  a  file  with  AR%1ST be encountered during the
first pass of DUMPER's  archival  or  collection  run,  the  most
recent  set  of  tape numbers must be cleared.  This is necessary
since AR%1ST indicates that the contents of  the  file  were  not
reliably copied to tape.

          The   retrieval  operation  is  handled  by  DUMPER  as
follows.  Retrieval requests are stored in a queue maintained  by
GALAXY.  When the command "DUMPER>RETRIEVE STR:<*>*.*.*" is used,
DUMPER  first  sends  an  IPCF  message  to GALAXY indicating its
desire to process the retrieval request queue.  It then  receives
retrieval  requests  from  GALAXY  one  by  one.  If a particular
retrieval request falls within the file  specification  given  in
the  command,  DUMPER  attempts  to retrieve that file; otherwise
DUMPER requests that GALAXY requeue the file for retrieval later.
Since the requests are ordered by the tape information, more than
one file can be retrieved from a single tape without rewinding or
dismounting the tape.  Should  the  retrieval  of  a  file  fail,
either because the proper tape could not be mounted or because of
data   errors,  DUMPER  will  request  that  GALAXY  requeue  the
retrieval request, considering  the  first  tape  information  in
place  of  the  more  recent copy.  If DUMPER fails to retrieve a
file from  the  both  tapes,  and  the  retrieval  was  requested
explicitly  by  a  user,  that  user  is notified by mail.  If an
implicitly generated retrieval request  cannot  be  honored,  the
process awaiting the retrieval receives an OPNXxx error.

          For each file that is to be retrieved, a temporary file
is  created.   The  file  contents are restored from tape to this
temporary file, and then the file's FDB is changed to reflect the
file information on tape, except  for  the  archive/virtual  disk
information.   Then  ARCF  (.ARRST)  is  used  to adjust the disk
contents  pointer  of  the  old   FDB,   bring   over   the   non
archive/virtual  disk  information to it from the temporary file,
and delete and expunge the temporary file.

          The  DUMPER  RETRIEVE  command  works  only  from   the
retrieval  requests  in  the GALAXY retrieval queue.  The RESTORE
command, as previously, requires  only  the  file  specification,
along with the appropriate tape already mounted.  When RESTORE is
used,  the  tape  header  record is checked for membership in the
Archive/Virtual Disk system.  If the membership test succeeds,  a
message  is  output  indicating  that RETRIEVE should normally be
used for Archive/Virtual Disk system tapes for reasons of  system
security.    Only   on   confirmation   and   wheel  or  operator

                              - 2 -

DEC archive system spec                                     Draft
Implementation details

capabilities enabled will  the  RESTORE  continue.   The  RESTORE
command  can  thus  retrieve a previously migrated file which has
since been deleted  and  expunged.   If  the  file  as  specified
already  exists  on disk with archive status, the RESTORE command
skips that file.

          Consider   now   the   use   of   tapes   other    than
Archive/Virtual  Disk  system tapes.  When an archived or expired
file is SAVEd, the archive/virtual disk information follows it on
to tape.  On RESTORE,  no  archive/virtual  disk  information  is
brought  back  to  disk  in  the  absence  of  wheel  or operator
capabilities.  In the case  of  wheel  or  operator  capabilities
enabled,   a   simple   RESTORE   command  does  bring  back  the
archive/virtual disk information.  This command  should  be  used
for (local) system tapes only.  An operator handling a non-system
tape  (typically a user tape brought in from another site) should
use RESTORE with  the  NOARCHIVE  switch,  which  suppresses  the
transfer  of archive/virtual disk information and thus avoids the
importation of bogus information into the  backup  words  of  the
FDB,  and  more  importantly,  guards  against attempts to create
counterfeit tape pointers.

                              - 3 -

DEC Archive/virtual disk system                             Draft

          System managers are recognizing the  growing  need  for
reliable   and   convenient   offline   storage   of  data.   Its
availability for general use allows valuable disk space now  tied
up  in  inactive  storage  to be freed for active use.  Users are
provided an equally-handy alternative to file  deletion  to  meet
directory  allocation requirements.  At the same time, users need
a permanent repository for  important  files  and  files  not  in
current  use.   A  reasonable model to use for this purpose is an
archive. Items entered into an archive never  change,  and  never
leave; only copies of items can be removed.

                              - 1 -

DEC Archive/virtual disk system                             Draft
User overview

          The  offline  storage  system  is presently implemented
using a collection of magnetic tapes each holding many individual
files.  This collection of tapes is divided  into  two  sections:
archive tapes in permanent storage (say 10 years) and non-archive
tapes in storage for a shorter period, say 6 months.

Archived files

          The  archives  can be viewed as unchanging data that at
one time existed as disk files on some system. Each user  has  in
their directory pointers into the archives for any data they have
placed  in  the  archives.   These pointers can be manipulated as
files, which for practical purposes, they are. When a file  gains
archive status(1) it can no longer be modified. This is necessary
to assure one and only one version of the data exists. Data of an
archived file exists in the archives and may simultaneously exist
on  disk.  These  copies  will  always  be  identical.  A file is
archived only by the explicit action (the ARCHIVE command) on the
part of the user.

Ordinary files in Offline Storage

          The non-archive section  of  offline  storage  provides
shorter- term storage of files with contents no longer desired on
disk,  but  not  considered  so  valuable as to require permanent
storage.  This decision may be made explicitly by  an  individual
user   managing   his   directory   within  the  disk  allocation
requirement, or implicitly by the user as files pass their online
expiration dates (which are user- settable, up to a point), or by
a system policy program used in the case of  insufficient  system
disk  resources.   Such  files have no special status and will be
treated as closely as possible to the way disk  files  have  been
treated  in  the past.  To differentiate them from archive files,
and point up their lack of special properties, we will  refer  to
non-archived  files  as  ordinary files.  Using this terminology,
offline storage is divided into storage  of  ordinary  files  and
archived files.

Tape Recycling

          The  crucial  difference  between  archived  files  and
ordinary files in offline storage is their allowed  lifetimes  on
tape.   The  maximum such lifetime is limited by the tape recycle
time.  The archive and non-archive recycle times are set  by  the
system  manager  at each installation with an eye to the tape and
tape storage resources.  Since files are never marked to indicate
a lifetime on tape beyond the tape recycle time in  duration,  an

(1) A file is considered to have archive status at  the  time  of
the ARCHIVE command. For a file to be completely "archived" there
must be two copies of the file in the archives.

                              - 2 -

DEC Archive/virtual disk system                             Draft
User overview

individual  tape  may  be  recycled  as soon as its (most recent)
write date lies in the past by the amount  of  the  tape  recycle

Concept of a file with contents online and/or offline

          A  file is considered to be a structure consisting of a
single FDB,  its  associated  name  string,  and  its  associated
contents.  Renditions of the file contents may reside on disk, in
offline storage, or both.  To maintain the essential identity  of
the  contents  of  each file,the disk contents of online archived
files are unalterable;  such disk contents are  reference  copies
of  archived  files.   If a writable copy of the same contents is
desired, it is easily obtained through use of the  COPY  command.
In  the case of ordinary files with offline contents, the offline
contents are considered subsidiary  to  the  disk  contents.  The
essential  identity  of contents is maintained by simply clearing
the tape information from the FDB  when  the  disk  contents  are
altered.   Thus just after a successful alteration of contents, a
file is certain to be a disk-only file.

Offline storage

          When entered into offline  storage,  files  (FDB,  file
specification,   and  contents)  are  copied  onto  two different
magnetic tapes, which  are  stored  in  the  installation's  tape
vault.   If  the  installation consists of more than one computer
system, the tape storage may still be made common to all  of  its
systems,  and it is possible to put files in offline storage from
one system, have the directory moved to another system, and  then
retrieve the files in the ordinary manner onto the second system.

Pointers to offline storage

          A pointer into offline storage consists of the tape ID,
saveset  number,  and  tape  file number for each of the two tape
copies  of  the  file  contents.   The  pointer  holds  all   the
information  necessary  to retreive a single file.  It ordinarily
resides in the file's FDB, where it  is  protected  in  the  same
manner   as  other  essential  file  information,  including  the
analogous disk contents pointer.

Delete protection of archived files

          Archived  files  are  protected   against   casual   or
accidental  deletion by the requirement, for successful deletion,
of the use  of  an  archive-specific  subcommand  to  the  DELETE
command.  Deletion may be undone by an ordinary UNDELETE command.
Further, it will be impossible to overwrite an archived file with
a  RENAME  or  COPY  command.   The  archive  pointer  itself  is
preserved past file expunge in a message sent the user.  The user

                              - 3 -

DEC Archive/virtual disk system                             Draft
User overview

may maintain a file (itself archivable) of such messages for dead
storage of archived files.

          Ordinary  files  have  no  such delete protection.  Any
case in which  disk-only  files  lose  their  contents  (rewrite,
destructive rename, simple delete followed by expunge) extends to
all ordinary files.  If an ordinary file is accidentally deleted,
a  backup  operation should be initiated just as in the case of a
disk-only file.

Messages sent to Users

          Messages  are  sent  to  users  when  files  are  taken
offline, archived or not, when retrieve operations are completed,
and when archived files are expunged.  An individual site may use
DEC mail, ARPANET mail, or no mail at all.  Assume here that mail
is used.  Retrieval messages go to the user who made the request.
For the other messages, the directory in which the file exists is
examined  as  follows.   If  the  file DIRECTORY.OWNER exists, it
contains the name of the user for such mail.  If  DIRECTORY.OWNER
does  not  exist, and if ARPANET mail is being used, the messages
go to OFF-LINE-FILE-MSGS.TXT  in  the  directory,  if  this  file
exists.  If not, the messages go to MAIL.TXT in the directory.

Visible and Invisible Files

          A  well-established  user typically has files, archived
or not, online or offline, which are not in current use and  tend
to  clutter  the  directory.   To  solve  the  problem of clutter
without complicating the system for the casual  or  inexperienced
user,  files  have been given a visible/invisible option which is
changed only in conjunction with voluntary offline  archival  and
retrieval or explicitly by the user.

          A  visible  file  is one which shows up on a simple (no
subcommands) directory listing and is accessible to programs  and
EXEC  commands  dealing  with  files.  In some cases, such access
immediately brings about an error  return,  for  example,  in  an
attempted copy of an visible but offline file.  An invisible file
does  not  show  up  on  a  simple  directory  listing and is not
accessible to  programs  and  EXEC  commands,  except  for  those
programs  and commands which specifically provide for them (as is
the case with deleted  files.)   Like  deleted  files,  invisible
files are not totally transparent:  they affect the determination
of  default  generation numbers by virtue of their ownership of a
certain file specification.

          A visible file may be made invisible as follows:


                              - 4 -

DEC Archive/virtual disk system                             Draft
User overview

Similarly, an invisible file may be made visible:


          Any file, archived  or  not,  may  be  set  visible  or
invisible.   In this sense, the visibility feature is independent
of the archive system.  The default setting, however, depends  on
the archive history of the file, as follows.  A file is (default)
visible  unless  it  is archived and offline, in which case it is
(default) invisible.  Ordinary files maintain their visibility or
invisibility through online-offline transitions.

                              - 5 -

DEC Archive/virtual disk system                             Draft
EXEC Modifications

EXEC Commands Controlling File Content Location

          Three  commands  handle  the  explicit   requests   for
transfer  of  file  contents  to  and  from offline storage.  The
ARCHIVE command requests the contents be entered in  the  archive
section  of  offline  storage.  The SET FILE EXPIRED command sets
the online-expiration date of the file to the  present  date  and
thus  in  effect  requests  the contents be placed in non-archive
section of offline storage.  The RETRIEVE  command  requests  the
contents  be  restored  to disk from whichever section of offline
storage they reside in.

          For each of the following  examples,  assume  that  the
connected    directory    <CALVIN>    has    just   five   files,
archived,  that is, its contents are on tape but not on disk.  It
is  invisible,  the   default   for   offline   archived   files.
Consequently  it  will  not  be accessible to EXEC commands other
than  SET  FILE  VISIBLE,  the   invisible-file   subcommand   to
DIRECTORY,  and  RETRIEVE.   ARCHIVED.ONLINE  is  archived,  with
contents on disk as well as tape.  Again  following  the  default
conditions,  this  file  is  visible.   ORDINARY.DISK-ONLY  is an
ordinary disk file with no pointer to offline  storage,  i.e.  an
old-fashioned  disk  file.   ORDINARY.OFFLINE is an ordinary file
with contents in offline storage but not on disk.  It is visible,
the default case here since visibility  status  does  not  change
with  transfer  of contents to and from the ordinary file section
of offline storage.  Similarly, ORDINARY.BOTH, an  ordinary  file
with contents on both disk and in offline storage, is visible for
these examples.

The ARCHIVE Command

          The  ARCHIVE  command  marks  the  specified  files for
archival by turning on the archive-request bit in the file's FDB.

 ORDINARY.BOTH.1 [Requested]
 ORDINARY.OFFLINE.1 %File is not online
 ARCHIVED.ONLINE %File already archived

          Note the invisibility of  ARCHIVED.OFFLINE.   Here  the
disk  contents  of ORDINARY.DISK-ONLY.1 become unalterable at the
time of the ARCHIVE command, and are expunged from  disk  at  the
end of the archival process.  The resulting offline archived file
is   then   set   invisible.    The   same   treatment  is  given
ORDINARY.BOTH, with the pointer  into  the  ordinary  section  of
offline  storage  being  replaced  by  a pointer into the archive

                              - 6 -

DEC Archive/virtual disk system                             Draft
EXEC Modifications


          In this case, the disk contents become  unalterable  at
the  time  of  the archive request, and remain so past the end of
the archival process.  The resulting online archived file retains
its previous visibility or invisibility.

          The archival request may be changed  from  the  default
disk-expunge  to  retain,  or  vice  versa, by simply redoing the
command in the preferred fashion.  The request for  archival  may
be cancelled:


The DISCARD Command

          The  DISCARD  command  is  used  to throw away the tape
information associated with a file. When this  action  is  taken,
the  tape  information is deleted from the FDB of the file. Files
must have the contents of the file online for DISCARD to succeed.

 ORDINARY.DISK-ONLY.1 %File has no tape pointer
 ORDINARY.OFFLINE.1 %File not online


          The SET  FILE  ONLINE-EXPIRATION  command  is  used  to
specify  when a file's disk contents expire. When this expiration
date/interval is reached, the file's contents are  moved  offline
and  remain  there  until the offline expiration date/interval is


 ORDINARY.OFFLINE.1 %File is offline

          In the first example, ORDINARY.DISK-ONLY will have  its
disk  contents expire 60 days after any reference to the file has
occurred. In the second example, the two files that  were  "[OK]"
will   have   the   disk  contents  moved  offline  on  or  after
18-Jul-1978, depending when the system  personnel  run  the  tape

                              - 7 -

DEC Archive/virtual disk system                             Draft
EXEC Modifications


          The  SET FILE OFFLINE-EXPIRATION command specifies when
the contents of an offline file  can  be  expunged  from  offline
storage.  This  parameter will either specify an explicit date or
an interval of days after the file was moved to offline  storage.
In  either  case,  the  specified value may not exceed the system
tape recycle time.



          The first example will  have  the  file  expunged  from
offline  storage  60  days after it was moved to offline storage.
The second example will have the file expunged on 13-SEP-78.

          To avoid losing a  file  and  its  contents,  the  file
contents  may be retrieved from offline storage and then the tape
information discarded by way of the DISCARD command.


          The SET FILE EXPIRED command causes the specified files
to become online-expired. This is  accomplished  by  setting  the
ONLINE-EXPIRATION date to the present date. These files will then
(at a somewhat later time) be moved to offline storage.

 ARCHIVED.ONLINE.1 %File is archived
 ORDINARY.OFFLINE.1 %File is offline

          Here ARCHIVED.OFFLINE is completely passed over because
it  is  invisible.   If  it  were  made  visible  and the command
reissued, it would result  in  the  message  "File  is  offline".
ORDINARY.DISK-ONLY  is  marked  for transfer of contents to tape.
Unlike the  archive-requested  file,  ORDINARY.DISK-ONLY  can  be
modified at any time while it continues to have contents on disk.
At   any   such  modification,  it  immediately  loses  any  tape
information (then obsolete, since tape  contents  are  considered
subsidiary  to  disk contents).  The request for transfer offline
still remains in effect unless cancelled.  When the file contents
have been copied onto two tapes, the disk contents  are  deleted.
The resulting offline ordinary file remains visible (since it was
visible  before)  and  gains  the  ;OFF-LINE attribute to mark it
offline.  Once it is offline, attempts to read or  append  to  it
fail,  unless SET RETRIEVAL WAIT is set (see below), but attempts
to rewrite it succeed, again with the concurrent loss of  offline

                              - 8 -

DEC Archive/virtual disk system                             Draft
EXEC Modifications


used to specify the online expiration date/interval  to  use  for
new files created in the directory. This default may be specified
as an explicit date or as an interval in days.





used  to  specify  the  default  date/interval  at which files in
offline storage are expunged from offline storage.  This  default
may  be  specified as an explicit date or as an interval in days.
The interval is the number of days since since the file was moved
to offline storage.  In either case its setting is required to be
consistent with the system-wide non-archive tape recycle time.




          The offline expiration date of a file is set when it is
moved to offline storage.  The default  expiration  date/interval
is  used  when  a  file  is  moved  to offline storage to set its
offline-expiration date.

RESIST and PROHIBIT Settings for a File

          A user may mark certain online files for  consideration
last by REAPER, for involuntary migration (including the deletion
of  disk-contents  of  files  with  contents  on tape as well) by
setting the RESIST bit.


          The RESIST setting can be undone as follows.


          A file may be absolutely  protected  against  migration
from  disk  by  marking  it PROHIBIT.  This may be done only by a

                              - 9 -

DEC Archive/virtual disk system                             Draft
EXEC Modifications

wheel or operator with the command SET  FILE  PROHIBIT-MIGRATION.
It may be undone with the command SET FILE NO PROHIBIT-MIGRATION.

The RETRIEVE Command

          The  RETRIEVE  command sends a message to the system to
request  the  restoration  of  the  file  contents  from  offline
storage, archive or ordinary, to disk.

 ORDINARY.BOTH.1 %File not offline
 ORDINARY.DISK-ONLY.1 %File not in offline storage
 ARCHIVED.ONLINE.1 %File not offline

          Note  that  RETRIEVE  is  one  of the very few commands
which acts on invisible files such  as  ARCHIVED.OFFLINE  in  the
above  example.   This  property allows users to retrieve offline
invisible files, archived or not, with a single  command.   After
retrieval, the disk contents of an archived file are unalterable.
The  disk  contents  of  an ordinary file may be changed at will,
with the concurrent loss of the pointer to the obsoleted contents
in offline storage.

          The retrieval requests  not  yet  carried  out  can  be
cancelled by the CANCEL RETRIEVAL-REQUESTS command.

New Aspects of EXEC Informational Commands

          The  DIRECTORY and INFORMATION commands provide natural
vehicles for offline storage information.   Since  the  directory
listing  sets  the  stage  for  the user's concept of his working
area, it is important to  implement  DIRECTORY  in  a  clear  cut
manner  which  reflects  the  realities  of the situation.  Since
retrieval of a file  does  involve  delay,  an  offline  file  is
necessarily  considered  one  significant  step  away from online
capabilities.  Correspondingly, offline files, archived  or  not,
are  conspicuously  marked  by  the  attribute  ;OFF-LINE  on all
DIRECTORY listings.  Users can make  files  invisible  to  remove
them  from  a  default  DIRECTORY  listing  as well as from their
routine working environment, since very few programs  can  access
them.   Offline  files  are  particularly  suited to invisibility
since they are a retrieval operation away from routine  use.   By
listing all visible files, with the offline visible files clearly
marked,  with a simple DIRECTORY command, a user sees his routine
working environment at a glance.

          Consider  the  directory  <CALVIN>  again.   A   simple
DIRECTORY lists all the visible files:

                             - 10 -

DEC Archive/virtual disk system                             Draft
EXEC Modifications



          The  DIRECTORY subcommand to examine just the invisible
files corresponds operationally to the subcommand to examine just
the deleted files.  That is,  with  the  INVISIBLE  (FILES  ONLY)
subcommand, only the invisible files, as otherwise specified, are
listed.   If  this subcommand is omitted, only the visible files,
as otherwise specified, are listed.



          The DIRECTORY subcommand particular to  archived  files
is  merely  selective:   without  it, files are displayed without
regard to their archival  status,  and  with  it,  only  archived
files, as otherwise specified, are displayed.  A complete archive
directory is obtained by listing the (visible) archived files and
then the invisible archived files.





          Offline  storage  information is accessible through use
of DIRECTORY subcommands:


                             - 11 -

DEC Archive/virtual disk system                             Draft
EXEC Modifications

                    Tape Write
ARCHIVED.ONLINE.1    7-Nov-77 15:36
ORDINARY.BOTH.1     15-Jul-78 12:05


                         Online expiration   Offline expiration
 ARCHIVED.ONLINE.1       13-Aug-78           5-Jul-88
 ORDINARY.BOTH.1         4-Sep-78            14-Oct-78
 ORDINARY.DISK-ONLY.1    30-Aug-78           N/A
 ORDINARY.OFFLINE.1;OFF-LINE  N/A            28-Sep-78

          The current archival status of files may be checked  by
the  INFORMATION command.  Suppose for the following example that
an   archive    request    has    recently    been    made    for

ARCHIVED.ONLINE.1     Archived
ORDINARY.BOTH.1       None
ORDINARY.DISK-ONLY.1  Archive requested

ARCHIVE Subcommand to the DELETE Command

          As   noted   before,   deletion   of   archived   files
intentionally involves some extra effort.  The following  example
shows  the failure of a simple DELETE command applied to archived
files, and its success on ordinary files with or without contents
in offline storage.

 ARCHIVED.ONLINE.1 %File has archive status

          On EXPUNGE, the three files ORDINARY.* will  completely
leave  the  system, in the sense that no FDB will be left on disk
to point to the copy of the contents in offline storage.

          To succeed in deleting archived files,  the  user  must
supply the archive-specific subcommand.

                             - 12 -

DEC Archive/virtual disk system                             Draft
EXEC Modifications


 [21 pages freed]

          To  delete  invisible  files,  first make them visible,
then delete them, using the ARCHIVED (FILES INCLUDED)  subcommand
if appropriate.



 [21 pages freed]

          Naturally,  UNDELETE  may be used before the expunge if
desired.  When archived files are expunged, a message is sent  to
the user giving the archive pointer and related file information.

          The  DELETE  command  is  provided  a new subcommand to
selectively expunge the disk contents of a file with a valid tape
pointer.  UNDELETE will not work to recover the disk contents but
RETRIEVE is available with some delay.

@DELETE *.*,
 ORDINARY.DISK-ONLY.1 %File has no tape pointer
 ORDINARY.OFFLINE.1 %File is offline


          Normally, an attempt to read  an  offline  file  simply
fails,  with  an  appropriate message.  Under some circumstances,
such as batch files, it is preferable for the program to wait for
the retrieval rather than to fail because of the lack of a  file.

                             - 13 -

DEC Archive/virtual disk system                             Draft
EXEC Modifications

This  mode  of operation can be set for a job using the following

@SET RETRIEVAL-WAIT (For off-line files)

          Note that invisible files are still inaccessible.   The
mode of operation for the job returns to normal with the command:

@SET NO RETRIEVAL-WAIT (For off-line files)

          Also  note  that  retrieval-waits may be suppressed for
the whole system under various conditions as  determined  by  the
system manager.

Copying and Renaming Files

          There  are  several  aspects  of  the  COPY  and RENAME
commands which involve offline  ordinary  files  and  online  and
offline  archived  files.  A file must have online contents to be
the source file for a successful COPY command. If,  in  addition,
it  has a tape pointer, the tape pointer will not be carried over
to the target file, but will remain solely with the source  file.
This  treatment avoids needless duplication of tape pointers.  By
the same token, the COPY command may be used to make  a  writable
copy of an archived file whenever it is needed.

          Consider  the following unsuccessful attempt to copy an
offline archived file.

 ?File not found

          Here the invisibility of the file prevented  access  to
it.  The file may be made visible, but the resulting access leads
to an error message, since the file is offline:


 ARCHIVED.OFFLINE.1 => MUMBLE..1 ?Source file is offline

          An online archived file is successfully copied:


          In  this  case, MUMBLE..1 is created with the same disk
contents as ARCHIVED.ONLINE but without archive status,  so  that
write  and append are allowed according to the protection status.

                             - 14 -

DEC Archive/virtual disk system                             Draft
EXEC Modifications

          Any visible file, archived or not, online  or  offline,
may  be  the source file for a RENAME command.  As with disk-only
files, the RENAME command changes only the name string associated
with the source file, and never  involves  the  contents  of  the

          The  delete protection provided only for archived files
affects COPY  and  RENAME  as  follows.   Attempts  to  overwrite
archived  files,  visible  or invisible, with COPY or RENAME must
fail, as the following examples show:

 TTY: => ARCHIVED.OFFLINE.1 %Target file has archive status

 DISKFILE..1 => ARCHIVED.ONLINE.1 %Target file has archive status

          Similarly, an archived file may not be changed  through
use  of  the  APPEND command, but, if online, its contents may be
appended to another file.

Other command changes

          The BUILD command has  been  modified  to  include  the
parameters. Both of these take either  an  explicit  date  or  an
interval of days.

          ^ECREATE      has      the      addition     of     the
ARCHIVE-ONLINE-EXPIRED-FILES  commands.   The  first two commands
take either an explicit date or an interval of  days,  the  third
merely sets/clears a mode bit.

          Finally  the ^ESET [NO] RETRIEVAL-WAITS command is used
by  the  operator  to  specify  that  retrievals  are  not  being
processed.  This  is  used  to  cause OPENF's to fail rather than
waiting for the file to be restored to disk.  Explicit  retrieval
requests are still queued in the duration of this command.

                             - 15 -

DEC archive system spec                                     Draft
Implementation details
GALAXY modifications

          Two major pieces of  the  Archive/Virtual  Disk  system
will  be implemented within GALAXY.  The first and most important
of these is the addition of a queue to  hold  retrieval  requests
for  archived  and expired files.  The second modification is the
addition of an internal queue and supporting  code  to  implement
user  notification  by  mail  of  archived  files  that have been
expunged from the disk.

          The  retrieval  request  queue  maintained  by   GALAXY
contains all outstanding retrieval requests for the system.  When
the  retrieval of an offline file is requested via the ARCF JSYS,
the retrieval information is sent to GALAXY in an  IPCF  message,
and the request is entered into the queue.  The retrieval request
queue  is  ordered  by  tape information (volume ID, tape saveset
number, and tape file number), and each new retrieval request  is
inserted   in  the  proper  sorted  position  within  the  queue.
Ordering the retrieval requests in this way  potentially  reduces
the  amount  of  tape  mounting  and  dismounting  that  must  be
performed  by  the  operator  when  the  retrieval  requests  are
eventually  processed.   Other operations on the retrieval queue,
such as listing and cancelling  retrieval  requests,  are  easily
implemented within the framework provided by GALAXY.

          When  a  retrieval  request  is  initially  queued as a
result of the ARCF JSYS, it is inserted into the queue  according
to  the  second  set  of tape numbers associated with the offline
file.  When the retrieval queue is processed by DUMPER's RETRIEVE
command, requests can be requeued for two  reasons:   either  the
request  does  not fall within the path specified by the operator
in the RETRIEVE command, or the retrieval request  could  not  be
honored  for  some  reason.   In  the  first case, the request is
requeued according to the same set of tape numbers as before,  so
that the request can be processed by some later invocation of the
DUMPER  RETRIEVE  command.   In  the  latter case, the request is
requeued according to the first  set  of  tape  numbers,  on  the
assumption that the more recent tape had data errors or could not
be  mounted.   Requests  that  are  requeued  in  this manner are
processed immediately; that is, by the current invocation of  the

          To  implement  this  protocol,  GALAXY  makes  repeated
passes over the retrieval queue, passing to DUMPER  each  request
that  needs  "consideration."   Those  requests  that DUMPER will
consider later are requeued with a time  stamp  which  identifies
the   current   invocation  of  DUMPER's  RETRIEVE  command.   On
subsequent passes through the queue, GALAXY skips  over  requests
that  were  time  stamped during the current retrieval operation.
Requests that are requeued because of  failure  have  their  time
stamp  field  zeroed,  so that GALAXY will reconsider the request
during the  same  retrieval  operation.   When  a  complete  pass
through  the  queue  results in no new requests to be considered,
GALAXY informs DUMPER that the queue has been exhausted.

                              - 1 -

DEC archive system spec                                     Draft
Implementation details
GALAXY modifications

          The  deletion  protection  special  to  archived  files
includes  notifying users by mail whenever valid tape information
is discarded  from  the  archive  system.   In  this  case,  mail
notification  provides  a  "paper  copy"  of the tape information
which can later be used to restore previously archived  files  to
disk.   Whenever  an  archived  file  is expunged, or its archive
status is discarded, an IPCF message is sent to GALAXY,  and  the
tape pointers are stored in the notification queue.  Periodically
(perhaps once per day) GALAXY processes the notification queue by
grouping  the  entries  according  to  the  owner of the expunged
files, and sending one message to each distinct owner giving  the
name  and  tape  information  for  each expunged file.  Since the
notification queue is internal to GALAXY,  users  may  not  list,
modify, or cancel requests in this queue.

          During  the initialization that GALAXY performs after a
system  reload,  those  retrieval  requests   which   were   made
"implicitly"  by  opening  an  offline  file are cancelled.  This
prevents potentially unnecessary transfers from offline to online

                              - 2 -

DEC archive/virtual disk system                             DRAFT
FDB modifications

Note that  all  mentioned  bits  and  offsets  in  the  following
descriptions  are those used in our 3A development system and may
be modified during the integration into release 4 at DEC.

                            FBCTL (1)

FB%ARC (1B11) - File has archive status. Appropriate words in the
FDB (see below) specify where the file is archived. This  bit  is
modified by the ARCF JSYS, CHFDB cannot change it.

FB%INV  (1B12)  -  File  is  invisible.  Puts  the  file  in  the
"invisible" section of the directory. These  files  can  be  seen
only  by using the G1%IIN option to GTJFN. FB%INV can be modified
with CHFDB by anyone with owner access.

FB%OFF (1B13) - File is offline. This is changed by ARCF when  it
removes the contents from disk, and when it restores the contents
to disk. FB%OFF cannot be changed with CHFDB.

                   FBBBT (22) (Formerly FBBK3)

The  left  half  of  FBBBT  is used for bits while the right half
contains the number of pages in the file when the  contents  were
deleted  from  disk. The following describes the bits in the left
half of FBBBT.

AR%RAR (1B1) - User request for a file to be archived.  This  can
only be modified by ARCF.

AR%RIV  (1B2)  - System request for an involuntary migration of a
file. The ARCF jsys is used to modify this bit,  and  the  caller
must have enabled WHEEL or OPERATOR capabilities.

AR%NDL  (1B3)  - Do not delete the contents of the file from disk
when the archival is complete. Set by ARCF.

AR%NAR (1B4) - Resist involuntary migration. This bit is  a  note
from  the user to the system policy module asking the file not be
moved offline if possible.  Set and cleared by ARCF.

AR%EXM  (1B5)  -  File  is  exempt  from  involuntary  migration.
Modified  only by ARCF and enabled WHEEL or OPERATOR capabilities
are required.

AR%1ST (1B6) - First pass of an  archival/collection  run  is  in
progress.  Modified  by  CHFDB and used only by DUMPER.  Requires
enabled WHEEL or OPERATOR capabilities.

AR%RFL (1B7) - Restore failed. Set by ARCF to indicate to another
process that the restore it is waiting on has failed.

                              - 1 -

DEC archive/virtual disk system                             DRAFT
FDB modifications

AR%PSZ (1B18-1B35) - The right half of FBBBT is used to store the
number of pages in a file when the  contents  were  removed  from
disk.  This value is set by the DELF JSYS (DF%CNO option) and can
be read with CHFDB or ARCF.

                   FBNET (23) (Formerly FBBK4)

          On-line expiration date and time. Specifies a date  and
time  at  which  a  file  is  considered expired, or specifies an
interval (in days) after which the file  is  considered  expired.
Modified by SFTAD.

                        FBTDT (31) (New)

          Archive or collection tape-write date and time. This is
the  date  and  time (in internal format) of the most recent tape
write to the archives or  virtual  disk.  Modified  by  ARCF  and
requires enabled WHEEL or OPERATOR capabilities.

                        FBFET (32) (New)

          Offline  expiration  date  and time. Specifies the date
and time (or interval) after which a file in the archives  or  on
virtual  disk  is  considered  expired.  Used for tape recycling.
Modified by SFTAD.

                        FBTP1 (33) (New)

          FBTP1  contains  tape  ID  for  the  first  archive  or
collection  run.   Modified  only  by  ARCF  and enabled WHEEL or
OPERATOR capabilities are required.

                        FBSS1 (34) (New)

          FBSS1 contains the saveset and tape  file  numbers  for
the  first  tape. The left half is the saveset number the file is
recorded in, the right half is the tape file number  within  that
saveset.   Modified  only  by  ARCF and enabled WHEEL or OPERATOR
capabilities are required.

                        FBTP2 (35) (New)

          Tape ID for second archive or collection run. (as  with

                        FBSS2 (36) (New)

          Saveset and tape file numbers for the second archive or
collection run.  (as with FBSS1)

                              - 2 -

DEC archive/virtual disk system                             DRAFT
JSYS descriptions

                Modifications to existing JSYSes


          Some  restrictions have been placed on CHFDB. CHFDB can
no longer modify FBBK3 and FBBK4 with the  exception  of  several
bits  in  FBBK3  (now  FBBBT).   These  modifiable  bits are: B0,
AR%1ST, and the right half of FBBBT.  Further, FB%DEL may not  be
set if FB%ARC (in FBCTL) is on.


          Default  online  expiration  date  and time and default
offline  expunge  date  and  time  have  been  added.  These  are
specified  by way of the .CDDNE (20) and .CDDFE (21) words in the
CRDIR argument block. These date and times may be  explicit  date
and  times (internal format) or an interval (in days).  In either
case, the specified  date/interval  may  not  exceed  the  system
maximum.   These  parameters are taken from the argument block if
CD%NED (1B2) or  CD%FED  in  .CDLEN  (1B3)  are  set.  If  a  new
directory   is   being  created  and  these  parameters  are  not
specified, the system default is used.

          An unprivileged user may modify his defaults, but  only
to a value less than or equal those which are currently specified
or the system maximum, whichever is greater.

          Additionally,  a  new  mode  bit (CD%DAR 1B3), has been
defined. This  bit  specifies  that  when  online  expiration  is
reached,  the  files  concerned  should  be  archived rather than
migrated to virtual disk.


          When  a  file  with  archive  status  is  deleted   and
expunged,  DELDF  sends a message to galaxy. The message contains
all archive status information which includes tape information as
well as the present file name, user who expunged  the  file,  and
the  time  at which it was expunged.  These messages (of the IPCF
flavor) will be processed by GALAXY at a later time.

                         DELF and DELNF

          DELF and DELNF fail (DELXnn)  for  files  with  archive
status.  For  the  delete  to succeed, DF%ARC (1B4) must be on in
AC1. This bit specifies permission to delete files  with  archive
status.   A  second  bit has been defined in DELF and DELNF. This
bit, DF%CNO (1B5), causes only the contents of  the  file  to  be
deleted  and  immediately  expunged. The file's FDB and name will
remain as it was (with the exception of the page count  and  page
table  address).   A  DELF  or DELNF with DF%CNO set will fail if
AR%NDL is set in FBBBT or  if  a  complete  set  of  tape  backup
information is not in the FDB.

                              - 3 -

DEC archive/virtual disk system                             DRAFT
JSYS descriptions

                         GTJFN and GNJFN

          GTJFN  has  only  one area of modification. It must now
ignore files that have the invisible bit (FB%INV) set. GTJFN  has
a  new  bit (G1%IIN 1B5) which specifies that GTJFN should ignore
the invisible status of a file. G1%IIN is given to GTJFN in .GJF2
of the extended argument block. GTJFN will return a  bit  (GJ%GIV
1B17) (like GJ%GND for deleted files) for use by GNJFN.


          JFNS  can  now  output  a new attribute ";OFFLINE". The
output of this can be requested by the JS%OFL (1B29) bit in  AC3.


          OPENF  has  been  modified to deal with archived and/or
offline files.  The following table describes OPENF's action  for
each possible state of a file.

                   Archived                     Non-archived
OPENF Access|  Online  |  Offline    ||  Online    |  Offline
   Read     |    Ok    |  Fail/Hang  ||    Ok      |  Fail/Hang
   Write    |   Fail   |    Fail     ||    Ok (discard implied)
   Append   |   Fail   |    Fail     ||Ok (discard |  Fail/Hang (discard
                                         implied)          implied)

          The  fail  cases  will  all return an appropriate error
message (OPNXnn).  The Fail/Hang cases will return an  error  for
fail  or wait until the OPENF can be successfully completed. Fail
or hang will be determined by the setting of OF%NWT  (never  wait
for file), OF%RAR (retrieve file if necessary), or the setting of
the job default (retrieve file if necessary). If OF%NWT is set on
the  OPENF call, OPENF will always fail (in the Fail/Hang cases).
If OF%RAR or the job default is set, the OPENF will wait for  the
file  to  be retrieved and then complete successfully.  In the Ok
(discard implied) cases, tape pointers, if any, for the file  are


          Three  new  words  can  be  returned by RFTAD. They are
.RSTDT  (4)  (tape-write  date  and  time),  .RSNET  (5)  (online
expiration  date  and  time),  and .RSFET (6) (offline expiration
date and time). Of these, .RSNET and .RSFET may  be  a  date  and
time  (in  internal  format)  or an interval (specified in days).
Intervals are limited to 2**18-1 days (a half word).


                              - 4 -

DEC archive/virtual disk system                             DRAFT
JSYS descriptions

          Renaming a file with tape information carries the  tape
information to the new file name. Renames which would effectively
destroy a file with archive status fail.


          A  new  function  code  (.SJDFR  (6)  set  job  default
retrieval) has been added to enable a user to override the system
default for OPENF. .SJRFA (0) specifies that OPENF should  always
fail  if the file's contents are not online. .SJRWA (1) specifies
that OPENF should wait for ARCF to restore the  contents  of  the
file to disk. .SJRFA is the system default.


          Three  additions  have  been  made  to  SFTAD. They are
.RSTDT  (4)  (tape-write  date  and  time),  .RSNET  (5)  (online
expiration  date  and  time),  and .RSFET (6) (offline expiration
date and time). Modification of .RSTDT requires enabled WHEEL  or
OPERATOR capabilities. .RSNET and .RSFET may be either a date and
time  (internal  format)  or  an  interval  (specified  in days).
Intervals are limited  to  2**18-1  days.   Date  and  times  and
intervals may not exceed system/directory maximum.


          New function codes .SFMCY (54), .SFACY (55), and .SFRTW
(56)  have  been  added.  .SFMCY  specifies  the  maximum offline
expiration  (tape  recycle  time)  for  ordinary  files.   .SFACY
specifies  the  expiration period for archive files (tape recycle
period). .SFRTW is used to set/clear the NO RETRIEVAL-WAITS  flag
in  the  monitor.  When  set this specifies that those retrievals
waiting for the retrieval should fail rather than hang.


          .SFMCY and .SFACY have been added to read  the  maximum
offline  expiration  time  for ordinary and archived files. These
values are the recycle times for tapes containing either ordinary
or archived files.

                           New Jsyses

                            ARCF Jsys

          The ARCF jsys will perform all operations pertaining to
the archive and virtual disk systems.  This  includes  requesting
archival and migration, requesting retrieval, and setting archive
status and tape information for a file.

                              - 5 -

DEC archive/virtual disk system                             DRAFT
JSYS descriptions


                    1: JFN
                    2: Function code
                    3: Function dependent, normally 0



                    +1 Always


          .ARRAR  (0)  -  This  function  sets/clears  AR%RAR  in
.FBBBT, a user request for archival. The value .ARSET in AC3  (1)
will  request an archive while .ARCLR (0) will clear the request.
Setting AR%NDL with .ARSET in AC3 requests the  contents  of  the
file not be flushed from disk upon archival.

          .ARRIV  (1)  -  This  function  sets/clears  AR%RIV  in
.FBBBT, a system request to migrate a file off  disk.  The  value
.ARSET  in AC3 will request migration while .ARCLR will clear the
request. The caller must be an enabled WHEEL or OPERATOR.

          .AREXM (2) - Set/Clear AR%EXM (exempt from  involuntary
migration)  in  .FBBBT. A 0 in AC3 clears AR%EXM while a 1 in AC3
sets it.  Requires enabled WHEEL or OPERATOR capabilities.

          .ARRFR (3) - Request a file's contents be  restored  to
disk.   Normally  .ARRFR returns without waiting for the contents
of the file to be restored to disk.
Options in AC3 are:
AR%NMS (1B0) - Do not  send  a  message  to  the  requestor  upon
AR%WAT  (1B1)  -  Wait  (hang in the ARCF jsys) until the file is

          .ARDIS (4) - Discard tape  information.  Clears  FB%ARC
(if  set),  .FBTP1, .FBTP2, .FBTSN, .FBTFN, and .FBTDT.  The file
must be online for the function to  succeed.   AC3  option  bits:
AR%CR1  (1B0)  clears  only  first  run information. AR%CR2 (1B1)
clears only pass two  information.  Requires  WHEEL  or  OPERATOR
capabilities to use AR%CR1 or AR%CR2 individually.

          .ARSST  (5)  -  Set  tape  information  for  a file. It
requires WHEEL  or  OPERATOR  capabilities.   AC3  points  to  an
argument block as follows:

               0: (.AROFL) Option bits
                   AR%O1 (1B0) - Set run 1 information
                   AR%O2 (1B1) - Set run 2 information

                              - 6 -

DEC archive/virtual disk system                             DRAFT
JSYS descriptions

                   AR%OFL (1B2) - Delete disk contents of file
                            when done. Requires bothsets of
                            tape info be set.
                            (.ARGST returns 0 for word .AROFL)
                   AR%ARC (1B3) - Set FB%ARC (archive the file)
                   AR%CRQ  (1B4) - Clear archive and/or migration
                            requests (AR%RAR and AR%RIV)
               1: (.ARTP1) Tape 1 ID
               2: (.ARSF1) XWD TSN 1, TFN 1  see footnote(1)
               3: (.ARTP2) Tape 2 ID
               4: (.ARSF2) XWD TSN 2, TFN 2
               5: (.ARODT) GTAD of tape-write; 0 implies
                           present time
               6: (.ARPSZ) Number of pages in the file.
                           This word is only returned
                           by .ARGST (.ARSST cannot set it)
This  function (.ARSST) is used to set information for the first,
second, or both tape runs. AR%O1 and AR%O2 are used together when
restoring files to disk via DUMPER's RESTORE command.

          .ARRST (6) - Restore the contents of a  file  to  disk.
AC3  is  a  JFN  for  a temporary file that contains the data for
currently offline archived file. After copying .FBADR, .FBBSY and
.FBSIZ the temporary file is deleted.  Both files must be on  the
same   device   or   structure  and  enabled  WHEEL  or  OPERATOR
capabilities are required.

          .ARGST (7) - Get tape information for file. AC3  points
to an arguement block to be filled. The format is the same as for

          .ARRFL (10) - The restore for this file has failed. Set
AR%RFL  in  FBBBT  to notify a waiting process that the retrieval
request cannot be completed.  Requires enabled WHEEL or  OPERATOR

          .ARNAR  (11)  -  Resist  involuntary migration. Sets or
clears AR%NAR in .FBBBT. .ARSET in AC3 will cause  resist  to  be
set, while .ARCLR will clear it.  Error returns:

CAPX1 - WHEEL or OPERATOR capabilities required.

ARGX02 - Invalid function code

ARCFX2 - File already has archive status

(1) TFN is for Tape File Number. It is a number recorded  on  the
tape  with  the file which is its index in a given save set.  TSN
is for Tape Saveset Number. The saveset number on a tape is  also
recorded in the save set name.

                              - 7 -

DEC archive/virtual disk system                             DRAFT
JSYS descriptions

ARCFX3  - Cannot perform ARCF functions on non-multiple directory

ARCFX4 - File is not online

ARCFX5 - Files are not on the same device or structure.

ARCFX6 - File does not have archive status

ARCFX7 - Invalid parameter for .ARSST

ARCFX8 - Archive not complete

ARCFX9 - File not offline

ARCX10 - Archive prohibited

ARCX11 - Archive requested, modification prohibited

ARCX12 - Archive requested, delete prohibited

ARCX13 - Archive system request not completed

ARCX14 - Restore failed

ARCX15 - Migration prohibited

ARCX16 - Cannot exempt  offline,  archived,  or  archive  pending

ARCX17 - FDB improper format for ARCF

ARCX18 - Retrieval wait cannot be fulfilled for waiting process

ARCX19 - Migration already pending

                              - 8 -

DEC archive system spec                                     Draft
Implementation details
Policy module

          The policy module for the Archive/Virtual Disk  system,
REAPER,  is intended for use by system administrators to increase
free disk space.  It can free up disk space in several  ways:  by
marking  for  involuntary  migration  files  which  have not been
referenced within a specified period of time;   by  deleting  the
disk  contents  of  archived or migrated files that have not been
referenced within a specified period; and by trimming directories
that are over their permanent disk allocations.

          A typical  use  of  REAPER  is  to  give  a  number  of
commands,  one  for  each  operation  to  be performed.  When all
desired operations have been  specified,  the  BEGIN  command  is
given,  specifying the path of files to be considered.  Following
is a list of REAPER's commands, with a description of each.

          BEGIN (Processing Files) -  Specifies  which  files  to
process  in a scan over the disk system.  Normally, one specifies
PS:<*>*.*.*,  but  one  could  specify  other  paths,   such   as
PS:<*>*.REL.*,   or  FOO:<TST*>*.*.*,  etc.   This  command  also
initiates the scan over the disk system, so  it  should  only  be
given  after  all desired options have been specified.  After the
specified files have been  processed,  REAPER  prints  the  total
number of pages reclaimed and then exits.

          DELETE  (Disk contents) - Specifies that files existing
both on disk and on an Archive/Virtual  Disk  tape  are  to  have
their  disk  contents deleted if the file has not been referenced
within a specified time period.  The time period is specified  by
the PERIOD command.  If the DELETE command is not given, the disk
contents of these files remains online.

          EXIT - Exits from REAPER, without processing any files.
Normally,  the  BEGIN  command  is used to exit from REAPER after
processing some files.

          LIST (To file) -  Specifies  an  output  file  for  the
listing  produced  by  REAPER.  If this command is not given, the
listing is written to the file DSK:ARCHIVE.LIST.

          MIGRATE  (Old  files)  -  Specifies  that   files   not
referenced  within  a  specified time period are to be marked for
involuntary migration.  The  time  period  is  specified  by  the
PERIOD command.  If the MIGRATE command is not given, these files
are not marked for migration and remain online.

          ORDER  (For trimming) - Specifies the order in which to
mark files for migration when TRIMming a directory that  is  over
its   permanent  allocation.   This  order  is  a  list  of  file
specifications, such as:  *.TMP.*, *.LST.*, *.REL.*.  This  order
list is only used if the TRIM command is given.

                              - 1 -

DEC archive system spec                                     Draft
Implementation details
Policy module

          PERIOD  -  Specifies  an age limit in days within which
files will not be MIGRATEd or have their disk  contents  DELETEd.
The usual period is 60 days.  This means that files older than 60
days  will  be  marked  for involuntary migration (if the MIGRATE
command is given) or will have their disk  contents  deleted  (if
the  DELETE  command  is  given.)   If  the PERIOD command is not
given, a default period of 60 days is assumed.

          SCAN (Only) - Specifies that no files  should  actually
be  DELETEd, MIGRATEd, or TRIMmed, but that only a listing should
be produced.  If the user is not an enabled  wheel  or  operator,
this is the default mode of operation (see below).

          SKIP  (Directories)  -  Specifies a list of directories
that are  not  to  be  considered  when  performing  the  DELETE,
MIGRATE,  and  TRIM operations.  This should be a select group of
directories; for instance, system directories and  other  special
directories should be included in this list.  If the SKIP command
is  not  given, all directories encompassed by the filespec given
in the BEGIN command will be processed.

          TAKE (Command file) - Reads a file of REAPER  commands.
This  file  can  contain  a list of directories to be SKIPped, an
ORDER list, a standard PERIOD, etc.  Although the  BEGIN  command
can  be  included in the command file, it probably should not be.
The default TAKE file is SYSTEM:REAPER.CMD.   This  command  file
can  contain the REAPER commands that implement a site's policies
toward involuntary migration.

          TRIM (Directories) - Specifies  that  directories  over
their  permanent disk allocations should be trimmed down to size.
The order  in  which  files  are  marked  for  migration  can  be
specified  in  two  ways.   If  the directory under consideration
contains a file named MIGRATION.ORDER, then the contents of  that
file  constitutes  the order list for that directory.  If no such
file exists, then the order list is taken as given in the  REAPER
ORDER command.  Thus, a per-directory order list takes precedence
over  a system wide order list.  REAPER makes several passes over
a  directory  attempting  to  trim  it  back  to  its   permanent
allocation.   First,  all  files in the order list are considered
(subject to the PERIOD in effect) except those having the "resist
migration" or "exempt from migration" bits set.  If there  is  no
order  list,  then this pass is skipped.  If the first pass fails
to bring the directory under its allocation,  all  files  in  the
directory (*.*.*) are considered, except those marked "resist" or
"exempt".  If necessary, these two passes are then repeated, this
time ignoring the "resist" bit.

          When  the  BEGIN command is given, REAPER processes the
specified file path on a directory by  directory  basis.   Within
each  directory,  the  MIGRATE,  DELETE,  and TRIM operations are

                              - 2 -

DEC archive system spec                                     Draft
Implementation details
Policy module

performed, in that order.   (TRIM  is  performed  last  to  avoid
unnecessary  file migration.)  Two other operations are performed
as well:  temporary (;T) files which are older  than  the  PERIOD
are  deleted  and  expunged;  and the directory is purged of FDBs
which point to offline files which  have  reached  their  offline
expiration  date.   If Control-A is typed while the BEGIN command
is underway, REAPER prints  the  name  of  the  directory  it  is
working on at the moment.

          If the user is not an enabled wheel or operator, REAPER
does  not  prompt  for commands.  Instead, it simply asks for the
name of the listing file, and  the  file  path  which  is  to  be
scanned.   REAPER  then  processes  this  path as if the commands
"TAKE SYSTEM:REAPER.CMD"  and  "SCAN"  were  given,  producing  a
listing  of  those  files  that  would be taken given the present
system policies toward file migration.

                              - 3 -