Not to beat  a dead horse, kick the dog, hit a man while he's down, etc.,
but I recall seeing the exact same EOF/EOV thing circa TSM 4.0 on AIX.
Will we (the royal or collective, take your pick) never learn from
history? Must we continually relive the same errors version after version?
Granted, it's not Tivoli directly, but since I'm in a wound up state
today...  There is a large TLA behind this product.




Dale Jolliff
Sungard Midrange Storage Administration
Office Telephone: (856) 566-5022





"Mueller, Ken" <KMueller AT MCARTA DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/25/2004 09:48 AM
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: More TSM Linux  issues


I had the same (or similar) problem using IBMtape 1.4.11, TSM would hit
EOV
then fail with an 'already reached EOV once' error, flag the tape R/O and
move on to the next tape ad nauseum... upgrading to IBMtape 1.4.14 solved
that problem (had to bump the Linux kernel up a notch to run a version the
new driver supported.)
-Ken

-----Original Message-----
From: Zoltan Forray/AC/VCU [mailto:zforray AT VCU DOT EDU]
Sent: Thursday, June 24, 2004 2:19 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: More TSM Linux issues


I think I have the answer to this, but would like someone to verify since
I
don't speak "hardware driver-ese".

On this TSM Linux server, the 3590 drives it uses (FC via QLOGIC), are
constantly "trashing" the tapes it writes to. Almost every tape is marked
as
"READONLY".

Upon investigation, I found a correlation. In the activity log, I see a
message about "end of file" being reached on the tape, followed by an
error

OP=FLUSH, Error Number=5, CC=0, KEY=40, ASC=00, ASCQ=00.

The IBMtape driver is at 1.4.11.  The only fixes since then (latest is
1.4.14) that might be close (this is where the "hardware driver-ese" comes
in) is:

"Fixed Write Filemark 0 handling at the early warning zone" ?

Your thoughts/suggestions on this ?