ADSM-L

Re: TSM inventory of empty slots becomes inconsistent wi th IBM3584 li brary.

2006-12-11 15:09:05
Subject: Re: TSM inventory of empty slots becomes inconsistent wi th IBM3584 li brary.
From: "Schneider, John" <schnjd AT STLO.MERCY DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 11 Dec 2006 14:08:02 -0600
Greetings,
        I am updating the list about this problem in case anyone else gets
bit by it.
        Richard was right in a measure; we had a tape drive that was failing
to eject tapes properly.  The side effect, though, with TSM's library
inventory becoming corrupt, is a bug addressed by APAR IC50475.  It is
addressed in TSM 5.3.4, but we are at 5.3.2 today.
        We replace the offending tape drive and the problem has gone away
for now.  But I am still going to apply the TSM 5.3.4 level, because
otherwise I know it is going to come back again when I can least afford the
time to monkey with it.
        Can anyone tell me if TSM 5.3.4 is solid, or are there known
problems?  I apologize in advance if this question has already been
addressed on the list.

Best Regards,

John D. Schneider
Sr. System Administrator - Storage
Sisters of Mercy Health System
3637 South Geyer Road
St. Louis, MO.  63127
Email:  schnjd AT stlo.mercy DOT net
Office: 314-364-3150, Cell:  314-486-2359


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Saturday, November 25, 2006 7:28 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM inventory of empty slots becomes inconsistent with
IBM3584 li brary.


John -

The joy of inherited environments, where you have no solid information on
how things were configured by your predecessors...

In my experience, an ANR8469E unload failure is always due to a tape drive
hardware problem (possibly a sensor or motor problem).  Check your records
or logs to gauge whether one or two drives are troublemakers and need work.
A tape stuck in a drive tends to stay in the drive, where it subsequently
being put away in a strange place
*might* be due to human actions.  Sometimes, a seeming unload failure can be
a timing problem in the drive microcode, where not enough time is being
allowed for the operation.

See IBM Technotes (1143428, 1212674) on the possible causes of ANR8356E.  An
insidious problem is where the barcode is inconsistent with the magnetic
labeling of the volume.  Element number inconsistencies are another gem.

Beyond that, I would activate TapeAlert and review AIX Error Log entries.
You also say that you are doing library sharing, so I would review the logs
of both sharers and see if both are experiencing the same kind of problems,
which may illuminate configuration or software issues.

   what I can think of,  Richard Sims

<Prev in Thread] Current Thread [Next in Thread>