ADSM-L

Re: Interesting 3494 failure condition

1999-10-07 15:26:43
Subject: Re: Interesting 3494 failure condition
From: Tom Bell <tom.bell AT WAII DOT COM>
Date: Thu, 7 Oct 1999 14:26:43 -0500
We've seen this kind of problem intermittently.  The usual cause is that
the robot gripper is positioned slightly low or high relative to the
3590's throat and the gripper applies just enough pressure to the
cartridge when backing out that the cartridge gets pulled away from the
cartridge present sensor.  This should be flagged by a 0E1C fault
symptom code from the drive.  Our CEs have usually had to reposition the
fiducial on the drive and re-teach the frame (and sometimes go through
several iterations of that) before the problem goes away.

>
> Thanks for the info.. We are currently experiencing similar problems,
> although it looks like our problem is different - our LM is not hanging.
>
> We are seeing sporadic Int Req. which turn out as tapes stuck in the drive.
> Sometimes requiring a manual unload sometimes just waiting for the gripper
> to come and pick it up.
>
> Now I realise that once in a while you will get a tape stuck in the drive,
> but we are getting two or three a day. IBM CE's running diags on the drives
> are coming up clean every time. There does not appear to be a problem with
> the drives. The Library is showing up clean also.
>
> This problem appeared when we upgraded Atape and Atldd.
> We are currently at ATAPE 4.4.0.0 and ATLDD 4.0.1.0 , AIX 4.3.2., ADSM
> 3.1.2.41
>
> Our 3493 is HA1 , Lan Attached, with the 3590 B1A drives.
>
> Has anyone been experiencing similar problems with these versions of ATAPE
> or ATLDD??
>
> TIA,
>
> Nathan
>
>
>
>         -----Original Message-----
>         From:   Richard Sims [SMTP:rbs AT BU DOT EDU]
>         Sent:   Wednesday, October 06, 1999 2:06 PM
>         To:     ADSM-L AT VM.MARIST DOT EDU
>         Subject:        Interesting 3494 failure condition
>
>         A note from the field as to what can happen with a 3494...
>         I came in yesterday morning to find an Int Req on the robot:
>         both 3590 drives in the last frame had failed to unload, at very
>         different times of the night.  The two drives in the first frame
>         had no problems.  After some 12 hours of analysis and erroneous
>         guesses by various IBM levels, it was finally determined that the
>         ARTIC (A Real-Time Interface Coprocessor) had partially failed.
>         This card in the industrial computer within the 3494 manages
>         RS-232 and RS-422 communication, as serial connections to a host
>         and command/feedback info to the tape drives.  The last two drives
>         had ejected their tapes and had tried to tell the Library Manager
>         about this, but could not.  When the robot needed to re-use the
>         drive but knew there was a tape in it, it posted the Int Req.
>         Attempting to clear the Int Req at the control screen resulted in
>         the LM being hung with a clock icon.  A Ctrl-Alt-Del reboot would
>         then always result in a memory dump and reversion to a Shutdown
>         selection box.  With all the 3494's internal logging one would
>         think that diagnosis of such a problem would be straightforward;
>         or at least the manifested symptoms would be well-known.  Not.
>
>         So the next time you get an Int Req and the tape is sticking out
>         of a drive but not removed by the robot, suspect a problem with
>         the drive's communication with the library manager.
>               Richard Sims, BU
>


--
Tom Bell                                    tom.bell AT westgeo DOT com
Tom Bell                                    tom.bell AT westgeo DOT com
Western Geophysical                         office:     (713) 689-2203
10001 Richmond, Room 3705                   fax:        (713) 689-2758
Houston, TX  77042                          pager:      (713) 415-0419

If it were easy, anyone could do it.
<Prev in Thread] Current Thread [Next in Thread>