I certainly would not dismiss the possiblity of an error at the factory.
As it happens I am at this moment in the process of giving some tapes one
last chance. They went status=private while last_use is blank because of
problems reading the labels. 90% of the time I can fix that with
checkout libvol mylib problem_vol1 checklabel=no remove=no
checkout libvol mylib problem_vol2 checklabel=no remove=no
label libvol mylib search=yes labelsource=barcode checkin=scratch
overwrite=yes
Nearly always creating a new label like this is sufficient. Of course I keep
an eye on the tape for the next several days, and first sign of any more
trouble I move data from the tape and get rid of it.
Luck!
- Kai.
-----Original Message-----
From: Taylor, David [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 24, 2001 10:11 AM
To: [EMAIL PROTECTED]
Subject: volume status being changed erroneously
TSM Gurus,
I found several reference to my problem in the archive but, did not find an
explanation or a real fix for it. If I over looked it, I will shamefully
take the time-out chair in the corner.
Our TSM environment is relatively new (< 6 mos). We are running 4.1.3
server on AIX 4.3.3 ML6 with a 3583 LTO library.
The clients are all 4.1.3 AIX and NT. A few TDP clients for Exchange, M$SQL
and DB2 on AIX.
The problem is that I keep seeing several of my scratch volumes' status
being changed from "scratch" to "private" and the "last use" column is
blank. The first time I noticed this it was suggested, by our Business
Partner, that the tapes were probably checked in improperly. I checked them
out and then back in as scratch. Within the last two weeks I recall seeing
several consecutively labeled volumes again with a status of "private" and
no "last use". Again I changed their status back to scratch. This
morning I see the same thing with the same group of tapes. I also happened
to catch it in the activity log, stating that there were I/O errors on these
volumes and the status change was to prevent re-access.
If it were one or two tapes, I could accept it. But the fact that these
seven tapes represent roughly 30% of the library's current population AND
the fact that they are consecutively numbered AND have never previously been
used, to me can't be explained as coincidental. The tapes and the labels
arrived separately. So we can dismiss a error at the factory.
Any help would be greatly appreciated!
Thanks
David Taylor
Senior Software Systems Engineer
West Bend Mutual Insurance
(262) 335-7077
[EMAIL PROTECTED]
