Hi Ruddy:
My problem was solved with a delete volume. It is now in the scratch pool, but here's
what it looked like just prior to the delete:
Volume Name: 000387
Storage Pool Name: AIX3590ARCH
Device Class Name: 3494ATAPE
Estimated Capacity (MB): 17,357.4
Pct Util: 0.0
Volume Status: Full
Access: Read/Write
Pct. Reclaimable Space: 100.0
Scratch Volume?: Yes
In Error State?: No
Number of Writable Sides: 1
Number of Times Mounted: 3
Write Pass Number: 1
Approx. Date Last Written: 10/06/00 10:34:13
Approx. Date Last Read: 10/06/00 17:01:32
Date Became Pending:
Number of Write Errors: 0
Number of Read Errors: 0
Volume Location:
Last Update by (administrator):
Last Update Date/Time: 10/05/00 19:28:27
more... (<ENTER> to continue, 'C' to cancel)
>>> [EMAIL PROTECTED] 10/11/00 10:33AM >>>
Larry,
Could you run the command : Q VOLHIST and make a search on 000387, so we
can see everything related to
this media.
Ruddy
-----Original Message-----
From: Lawrence Clark [mailto:[EMAIL PROTECTED]]
Sent: mercredi 11 octobre 2000 16:16
To: [EMAIL PROTECTED]
Subject: Re: Error deleting trans for 0 bytes
Hi Ruddy:
If the volume had been a copypool volume that might explain it, but this
volume was a storage pool volume that never left the library.
>>> [EMAIL PROTECTED] 10/11/00 09:17AM >>>
May be this could help you. I found some documentation about REUSEDELAY
parameter :
REUSEDELAY parameter : This parameter specifies the number of days that
must elapse before a volume can be reused or returned to scratch status,
after all files have been expired, deleted, or moved from the volume.
When you delay reuse of such volumes and they no longer contain any
files, they enter the pending state. Volumes remain in the pending state
for as long as specified with the REUSEDELAY parameter for the storage
pool to which the volume belongs.
Delaying reuse of volumes can be helpful under certain conditions for
disaster recovery. When TSM expires, deletes, or moves files from a
volume, the files are not actually erased from the volumes: the database
references to these files are removed. Thus the file data may still
exist on sequential volumes if the volumes are not immediately reused.
Ruddy
-----Original Message-----
From: Lawrence Clark [mailto:[EMAIL PROTECTED]]
Sent: mercredi 11 octobre 2000 14:56
To: [EMAIL PROTECTED]
Subject: Error deleting trans for 0 bytes
Yet another new error related to an empty volume that did not return to
the scratch pool. This time after reclamation on the volume:
Anyone seen this:
10/11/00 08:00:44 ANR1041I Space reclamation ended for volume 000387.
10/11/00 08:00:44 ANR9999D afmigr.c(2882): Error deleting transaction
for 0 bytes moved reclamation - volume 000387.
tsm: BACKUP>move data 000387
ANR2232W This command will move all of the data stored on volume 000387
to
other volumes within the same storage pool; the data will be
inaccessible to
users until the operation completes.
Do you wish to proceed? (Yes/No) yes
ANR2209W Volume 000387 contains no data.
ANS8001I Return code 11.
Larry Clark
NYS Thruway Authority
