Big problem with backing up on Sequential Access Storage Pool volumes

[zaxxon]

Hello,



we upgraded TSM server from 4.2 to 5.1.6.5 and the client from 4.2.something to 5.1.5. We have a Jukebox with WORMs attached to the TSM and the client is running on the same machine as the server. For some reason, the TSM is not backing up anymore on the WORMs to the storage pool we have added 10 new and empty WORMs. We did nothing different to when we had earlier versions of TSM.

We checked them in, assigned them to it's storage pool and that's it.

When we do Q VOL we can see the defined Volumes we added recently. We see them with a Q LIBVOL too. Problem is, when we check them, their state is "unavailable". When we audit them and set them to "READWRITE", they will be "READWRITE" for about 10 minutes, until TSM gives up to ask for the missing volumes, even they are not missing since a Q LIBVOL shows them. After the 10 minutes they are getting status "unavailable" again.

An audit fix on the volumes also tells that they are not present and an audit library on the jukebox will not even start and there is no error message for it in the actlog. Anyone any idea? I have a call running at IBM support at the moment, but any faster help/idea is very welcomed. Thanks in forward!

 

[zaxxon]

Just got feedback from TSM support. They say that accidentally the 5.1.6.5 for the server was compiled under AIX 5.x. I have to reject the patch and have to use 5.1.6.4. They don't advice to use 5.1.7.0 as they have one customer, that is has very big problems since 5.1.7.0 and they wanna solve them 1st. Let's see if it helps; I will keep thee informed.

 

[zaxxon]

We rejected 5.1.6.5 and installed 5.1.6.4 and the problem was still there. So I took a closer look at the volume names in q libvol and compared those that have problems with that in a q vol and saw, that there was just a zero too much in there... ok, shit happens. Deleted the volumes from the storage pool and defined them with the correct names. Sorry for the confusion