>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:   gillg AT saic DOT com
Phone:  (858) 826-4062
Pager:   (888) 997-9614