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