It is very important to allow ADSM to manage it's own tapes.  Use DELETE
VOLHISTORY TYPE=DBB to manage the number of database backups to keep.  We
have this command scheduled on a regular basis.  You decide how many days of
DBB you want to keep.

At 01:13 PM 8/22/96 -0400, you wrote:
>I write the full db backups to tape, but the triggered incrementals go to
>disk.  I did change the ACS routines to give those files a mgmtclas with
>the proper retention period;  I couldn't see any other way to do it.  You
>could capture the dataset name from ANR?? messages issued when the backup
>completes and have your console aoutomation product alter the mgmtclas.  I
>didn't do it this way becasue I didn't have a proper mgmtclas, so I had to
>change SMS anyway.
>
>If a dbbackup disk file is not deleted by sms before a VOLH delete command
>is issued, ADSM will wait while the file is recalled by HSM before it is
>deleted.  This isn't directly an ADSM bug, but a long standing 'feature' of
>DFP/FDSMS.
>
>Bill Colwell
>The Charles Stark Draper Laboratory
>Cambridge Ma.
>
>_________________________Reply Header_________________________
>Author: ADSM-L AT vm.marist DOT edu
>Subject: Expiring database backup backup volumes
>08-22-96 07:10 PM
>
>Hi ADSM-ers,
>We don't want applications to directly write to tape. That's why we have
> defined DEVTYPE=FILE in all our deviceclasses.
>However, when a database backup is made, the output file never expires. The
> RETENTION parameter would be ideal for this, but for whatever reason ADSM
> development decided to make this paramater only available when you write
>to
> tape.
>Has anybody encountered this same problem and how did they solve/bypass
>this?
>I don't want to add additional high level qualifiers to my ACS routines.
>We are running ADSM/MVS 1.2.09.
>Thanks in advance for any reply!
>Kindest regards,
>Eric van Loon
>
>