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:Thomas.Denier AT MAIL.TJU DOT EDU]
Sent: Monday, March 03, 2003 3:30 PM
To: ADSM-L AT VM.MARIST DOT EDU
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?