>The problem with database backups, migrations failing and not >waiting for >tape drives existed in 4.1.2.0 also.
I just moved up from 4.1.2.0 and did not see this problem here. That version seemed to be very stable for me. >If TSM attempts to access a scratch tape and cannot read the >label, the tape >is marked private. I have seen this issue due to label >libvol failures. These tapes are only about 2 years old, some even newer. None have had problems at all in the past. Support has looked at all the issues I have and knows full well they are all legitimate. The problem I'm told is that somehow TSM is telling the library manager to change the categories, and it does. 0066 is my scratch and 0064 is private. All the tapes reverse themselves. This happens only when the TSM server starts up, so they say. They actually said don't stop and start the server and that won't happen. No kidding, I think I could have figure that out myself! Unfortunately the built in crash mechanism forces both problems on you. TSM support also said TSM is not confused and if one of these tapes gets mounted it knows data is on it and puts it back. Ask me if I believe that 100%.... I'm told this fix will fix all the tape issues I mentioned since I upgraded. >What specific problem did they identify in the TSM code that >was causing >these issues? Or are they just suggesting to "try our cew code"? Actually I don't have a fix for this yet. Maybe tomorrow, but I figure more likely next week. I'd guess the crash fix won't be out for some time. The dsmserv.opt change they want me to make is a guess on their part. Might as well try it, it already doesn't work, what harm can this do. Geoff Gill TSM Administrator NT Systems Support Engineer SAIC E-Mail: [EMAIL PROTECTED] Phone: (858) 826-4062 Pager: (888) 997-9614
