r.kennedy
ADSM.ORG Member
... without an auditdb!
I've been to Hades and back trying to fix my TSM install that recently began getting storage pool id not found errors, as well as errors when I attempted to delete a filespace. The problem turned out to be that I had deleted some copy storage pool virtual volumes (intra-server volumes), their storage pools, and their device classes without reconciling them. Big mistake.
Upon starting TSM I would get errors like this:
ANR9999D asutil.c(358): ThreadId<0> Pool id -15 not found.
When I tried to delete a filespace I would get an error like this:
ANR9999D ssalloc.c(1501): ThreadId<34> Dealloc prohibited - transaction failed.
ANR9999D imfsdel.c(1805): ThreadId<34> IM not able to delete object 0.173681910, rc: 19
Trying to 'delete object' manually resulted in the same message.
When I used 'show bfo' to get more info on the object listed, I would see that it had a primary entry that appeared fine and a copy entry that had a storage pool id of -15 and an unknown volume.
The device classes, storage pools, and volumes were long gone. I only had two options - auditdb or brute force. The last auditdb I ran took 200 hours (slow machine). I chose force.
I noticed that Tivoli creates all primary storage pools with a positive, increasing pool id and all copy storage pools with a negative, decreasing pool id. I was at -3 for copy storage pools. I crossed my fingers, and defined 12 new copy storage pools.
The output of the 'show bfo' did not change and I was sad. I ran a 'q occ' on the offending node and saw that I suddenly had data in one of the new copy storage pools!
I could delete the nodes as I had originally planned. Once I took care of all the nodes that still had data in storage pool -15 I did not get messages on TSM start anymore.
Hopefully someone else finds this useful.
Cheers,
Robert Kennedy
University of Texas at Austin
ITS Systems - UNIX
I've been to Hades and back trying to fix my TSM install that recently began getting storage pool id not found errors, as well as errors when I attempted to delete a filespace. The problem turned out to be that I had deleted some copy storage pool virtual volumes (intra-server volumes), their storage pools, and their device classes without reconciling them. Big mistake.
Upon starting TSM I would get errors like this:
ANR9999D asutil.c(358): ThreadId<0> Pool id -15 not found.
When I tried to delete a filespace I would get an error like this:
ANR9999D ssalloc.c(1501): ThreadId<34> Dealloc prohibited - transaction failed.
ANR9999D imfsdel.c(1805): ThreadId<34> IM not able to delete object 0.173681910, rc: 19
Trying to 'delete object' manually resulted in the same message.
When I used 'show bfo' to get more info on the object listed, I would see that it had a primary entry that appeared fine and a copy entry that had a storage pool id of -15 and an unknown volume.
The device classes, storage pools, and volumes were long gone. I only had two options - auditdb or brute force. The last auditdb I ran took 200 hours (slow machine). I chose force.
I noticed that Tivoli creates all primary storage pools with a positive, increasing pool id and all copy storage pools with a negative, decreasing pool id. I was at -3 for copy storage pools. I crossed my fingers, and defined 12 new copy storage pools.
The output of the 'show bfo' did not change and I was sad. I ran a 'q occ' on the offending node and saw that I suddenly had data in one of the new copy storage pools!
I could delete the nodes as I had originally planned. Once I took care of all the nodes that still had data in storage pool -15 I did not get messages on TSM start anymore.
Hopefully someone else finds this useful.
Cheers,
Robert Kennedy
University of Texas at Austin
ITS Systems - UNIX
