Reply to deleting old filespa

*** Original Author:  ADSM-L @ MARIST - ** Remote User **; 05/03/95 08:39

>Received: from VM.MARIST.EDU by AUDUCADM.DUC.AUBURN.EDU (IBM MVS SMTP V2R2.1)
>   with TCP; Wed, 03 May 95 08:39:35 CDT
>Received: from VM.MARIST.EDU by VM.MARIST.EDU (IBM VM SMTP V2R2)
>   with BSMTP id 3404; Wed, 03 May 95 09:36:27 EDT
>Received: from VM.MARIST.EDU (NJE origin LISTSERV@MARIST) by VM.MARIST.EDU
> (LMail V1.2a/1.8a) with BSMTP id 6831; Wed, 3 May 1995 09:36:25 -0400
>Date:         Wed, 3 May 1995 15:35:17 +0200
>Reply-To:     "Dist. Stor. Manager(ADSM) List" <ADSM-L AT VM.MARIST DOT EDU>
>Sender:       "Dist. Stor. Manager(ADSM) List" <ADSM-L AT VM.MARIST DOT EDU>
>From:         Reinhard Mersch <mersch AT UNI-MUENSTER DOT DE>
>Subject:      deleting old filespaces
>To:           Multiple recipients of list ADSM-L <ADSM-L AT VM.MARIST DOT EDU>
>
Hello,

as time goes on, we get more and more filespaces which are not
regularly backed up any more, because e.g. the filespace's name
changed or for other reasons. Those filespaces' backups never expire.
After an appropriate time (according to the setting of RETONLY in
the standard backup copy group) I would like to delete these filespaces,
but I do not know what to base this decission on. The server command
"q fi f=d" tells me the last backup date but, as far as I know, this
only reflects incremental backups. Thus, from the server side,
filespaces that do not exist any more, and filespaces with no recent
incremental, but possibly lots of selective backups, look the same.
Am I missing something?

Reinhard Mersch                     Westfaelische Wilhelms-Universitaet
Universitaetsrechenzentrum, Einsteinstrasse 60, 48149 Muenster, Germany
E-Mail: mersch AT uni-muenster DOT de                   Phone: +49(251)83-2488

*** Comments from STEWAJM - Stewart, Mike; 05/03/95 11:19am:
That's my reading as well.  We've got the same problem; lots of
our users only do selective backups, so I can't really tell
what filespaces haven't been touched in forever, and which
which are actively being accessed.  Users may be actively
restoring files from a filespace, but we can't tell.

It would be nice if there was some sort of "last date read" and
"last date written" maintained on a filespace basis.