Hello Kurt, i think it depends on the time the db-volume was createtd and on your deletion-policy of db-volumes like 'del volh todate=today-10 t=dbb' ... for example freeing volumes older than 10 days. If you just manually check in/out those volumes you may experience the following: if the date of the-checkin-again-of-the-db-volume minus the date of the-creation-of-the-db-volume is LOWER than your deletion-policy then that volume may come automatically into scratch when the 'del volh t=dbbb ' will run again. If the time is HIGHER than your deleteion-policy, then your volume may stay in private until you update it to scratch. Knowing that you are checking in db-volumes you may easyly, but manually use the command you have mentioned and after that check the state of the successfully-checked-in tape with a command like 'query drmed DB_MON ' ... if this command shows up something like ' No match found using this criteria' the volume won't go to scratch automatically and you have checked in the volume after the date when your expiration had whiped it out. ... if this command shows the volume with something like 'Mountable ...' the volume will go automatically into scratch because the expiration will run in future and your volume will be online at that time.
So your problem maybe gone if you just checkin the volumes some days later ? Greetings Rainer "[EMAIL PROTECTED]" wrote: > > Hi everybody, > > My environment is TSM 5.1.1.6 on a Win2k server. > > I take every day a full TSM db backup to a private tape volume. The tapes are >checked in as private. > > However, the past week it happened twice that a database tape was allocated in the >storage pool for the backup of the clients. If I check the activity log, it says >indeed "Scratch volume DB_MON is now defined in storage pool SSL_POOL1." > > I've checked in the tape with a status private, but somehow it was returned as being >scratch. Am I'm missing something here? When I perform the command 'checkin libv >ssl2020 search=bulk status=private', the tape is checked in as private and it >shouldn't return to a status scratch. Has anybody else experienced the same behaviour? > > Thanks in advance, > Kurt -- ------------------------------------------------------------------------------- Rainer Wolf mail: [EMAIL PROTECTED] tel: ++49 731 50-22482 fax: ++49 731 50-22471 Computing Center, University of Ulm, Germany web: http://www.uni-ulm.de/urz
