This is a problem for all the newer tape technologies. Typically, this is caused by a bad batch of tapes or a case of tapes that has been slammed on the floor or the librarian stacked them and knocked them on the floor.
Early in the delivery of K tapes there was a packing problem. Also, make sure you have the latest microcode on your drives. If you are running downlevel, you can get errors during certain conditions. I cannot remember what the MIH has to be set for or whether you can take the defaults. The deal is the tape is much longer and can take a long time to rewind. There is a document from IMATION on this subject. I suggest you get that document. -----Original Message----- From: Thomas Denier [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2003 3:30 PM To: [EMAIL PROTECTED] Subject: Errors on 3590 K tapes We are running a 4.2.3.2 TSM server under OS/390. We have four 3590 tape drives that were and are working well with 3590 J tapes (the ones with 20 GB capacity without compression). We are in the process of migrating our onsite storage pools to 3590 K tapes (the ones with 40 GB capacity without compression). So far we have had seven of the new tapes forced read-only because of I/O errors. We have one full 3590 K tape, and seventeen in 'FILLING' status that have not so far had any I/O errors. The errors have been spread across at least three of the tape drives. In most cases, there is an OS/390 message like the following: IOS071I 0C62,1D,ADSM, MISSING CHANNEL AND DEVICE END and a TSM message like the following: ANR5351E Error reading BlockID on device 0C62. Do 3590 K tapes typically suffer the kind of infant mortality rate we are seeing?
