> After we had four tapes sent to Tucson to try to retrieve the data off them
> (one's tape had snapped- which was a 1° stgp collocated tape, and the other
> three were the offsite backup tapes of the that 1° stgp and they are
> unreadable),  found out that most of the problems I have been seeing and
asking
> the list about are probably due to bad media.  I was told that there was a
> manufacturing process defect that affected 3570 Magstar MP tapes during the
last
>  
> half of 1997.
>  
> We have about 1200 tapes that were manufactured during that time period.
>  
>  
> IBM is going to ship up replacements upfront so we can get the data off the
old
> and onto the new.  Has anyone had experience with such a task?
>  
> The replacing will need to be done at 10 locations in different geographic
> areas.  Approx 120 tapes per location, with a 3575 - L12 library with 3 3570
B
> drives in each library at each location.  ADSM runs on J30s and J40s at
these
> locations.
>  
> Here at HQ, when we went from 3590B drives to 3590E drives in our 3494
library,
> we just maked all the tapes readonly, and over the course of time, the tapes
> were converted to the new format.  This one was easy-- you didn't have to
figure
>  
> out how to move all the data, and pull the "old" tapes out whenever they
were
> empty- after they went to scratch and before used again in another stgp
without
> leaving the library & replacing all the offsite tapes, too.
>  
> Has anyone else had a similar experience, and how did you handle it?  Script
for
>  
> searching the tapes when their access/status changes?  Move data off old
tape to
>  
> DASD and then write to new tapes?  Plain old move data?

One of my past employers ended up with several hundred 3480 volumes that had
bad joints between the two halves of the casing. The bad volumes tended to
fracture when operators dropped them on the floor. The tape vendor sent us a
supply of replacement volumes. I set the bad volumes read-only. Within two or
three months about 90 percent of them had been cleared by expiration and
reclamation. At that point I ran MOVE DATA commands to clear the rest. That
site used permanently defined storage pool volumes, so there was no need to do
anything to prevent the volumes from being reused. Lisa's site is apparently
using scratch volumes. Offhand, I can only think of one way to deal with that
situation: run regular scans for bad volumes in pending status and have them
ejected from the library before their reuse delay period ends. I set up a
scanning process somewhat like that. The volumes found by the scans were
physically removed from the tape racks and deleted from the ADSM database. New
volumes were then labeled, placed in the racks, and defined to ADSM. This was
several years ago, so I have forgotten a lot of the details, but I don't
recall the scan being particularly difficult to set up.