Hi , Mark.

No so long ago I had the same problem, but now I 've resolved it.

As far as I know the ADSM database backup coouldn't follow a 
management class like other client backups.

To avoid your problem with Recovery log you may upgrade your ADSM server  
(it seems to me that from v2.1.9 ADSM has feature to dynamically 
increase recovery log spase after crash: if when crush has occured you 
still have "Available Space" of recovery log more then "Assigned capacity", 
you will be able to extend your recovery log instead of performing database 
dump and recovery from dump - it takes not so much time to do ).

You can implement the more sophisticated procedure of database backup as well.
In example I'm implementing the following scheme of database backup:
* daily (automated) full database backup to scratch volume of 3590 
device (old volume history information erases manually by my operations staff).
* incremental database backup to _sequental_ disk device (Device Type: FILE) 
when neded (automated, driven by DBBACKUP TRIGGER that has set to 50%)
* backup of volume history information and device configuration to floppy 
by my operations staff daily

That scheme  prevent me from recovery log overfull due to 3590 device 
unavailability (it may be busy with backup and restore operations).


Best regards.
_______________________________________________________________________
Grigory Bourov                                  GAZ
AIX System Engineer                             Design & Experimental Div.      
e-mail: <gburov AT uker.gaz DOT ru>                    Nizhny Novgorod
                                                Russia