Hi Jeri,

I have built the same scripts myself and see the same problem with the db
backup tape. I reduced the mount retention to 1minute and added a 300
second sleep after the dbbackup and i still occasionally get caught out.

The solution is to retry the dismount command until is works which is what
you appear to be doing.

regards Tonyr

"Bush, Jeri" <jbush AT TI DOT COM> on 04/01/2000 07:47:18

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: Tony Rynan/Australia/IBM)
Subject:  DRM: DB volume does not dismount before 'move drmedia' executes




We have automated a majority of our disaster recovery process but have
encountered a snag in automating it completely.

We run ADSM server version 3.1.2.40 on a Sun Solaris 2.6.  Our tapes are
stored in an IBM3494 ATL.

Our high-level process is:
 - copy appropriate storage pools to DRM storage pool
 - execute a full backup of the ADSM database
 - "Query drmedia * wherestate=mountable"
 - "Move drmedia * wherestate=mountable"  (tapes are then automatically
ejected)
 - execute the prepare

Our problem occurs when the tape used to backup the database is still
mounted in the tape drive.  The 'move drmedia' command will not move the
mounted volume to the 'VAULT' state.  I assume this could also happen if a
volume for our DRM pool is still mounted but I do not have proof of that
occurring.

To get around this we stop the process at the backup completion, manually
'Q
MOUNT' and then 'DISMOUNT' any volumes that are sitting in IDLE state.
Once
the tapes are dismounted we can query and move drmedia.

We have tried getting around the problem with the tape staying on the drive
by setting the 'mountlimit' to 1 minute. That created problems in which
tapes that needed to stay mounted for our log storage pools were getting
mounted and unmounted almost continuously.

Our thoughts are that we need to: automatically query mounts, determine if
a
volume in IDLE state is needed for DRM and dismount that specific tape.
Any
other workable automatic solution could be tested, though.

Any suggestions on how to resolve this would be greatly appreciated.

Regards,
Jeri Bush
ADSM Enterprise Support
Texas Instruments, Inc.
972-575-0868
jbush AT ti DOT com