Hmm,
  There are alot of IBMtape SENSE DATA messages...

I couldn't get any support people to know who to send this problem to, so I
downloaded the IBMtape manuals and SCSI reference manual. And tried to
tackle it myself.
Turned the IBMtape trace value to 2.

Wow those, SENSE DATA messages that were occurring now report an additional
line...
A bit easier to read and correlate with codes in the SCSI reference manual.
chk_sns: cmd 0xa(write), key/asc/asq 0x4/4b/0, defer 0, retry 301, rc 5

Ugh, all those obscure messages out at trace lvl 0, summarize em!
write_error, read_error, etc... ugh..

Also, I believe the problem errors are ones that TSM doesn't catch as
errors.... 0x4/4b/0 seems to be the culprit...

A breakdown of the various messages is as follows:
13490 total SENSE DATA messages
13216 of 0xa(write)0x4/4b/0 which are some sort of write error (not being
reported back to TSM)
7817 on drive 2 (out of 8 drives)
5395 on drive 1
4 on drive 3 (I disabled this drive due to write errors reported back to
TSM early on in the testing and waiting for it to get checked on)
6 of 0xa(write)0x4/44/0 that correlate to write errors reported back to
tsm, many on drive3 and 2.
The rest are read errors on various drives, that correlate to the read
errors occuring in TSM.

I am going to do a bit more correlation and trying to figure out what
drives are reporting the errors, seems to be just 1, 2 and 3...  hmmm.

Also I was eventually able to get IBM support to create a ticket and the
sense errors were sent to them.
I will find out what they say.

Matthew Glanville


Dave frost wrote>

      Have you had any interesting records in /var/adm/messages that you
can
      match up to when one or more of the tapes was mounted?  (ANR8468I
volume
      <x> dismounted is a good search key).

      We have only seen this on san-attached devices, and then only when a
RSCN
      has occurred on the fabric.  During reads or writes a block will be
      silently dropped.  Reads are recoverable...