We had a ugly incident with both of our 3584 libraries.
Symptom: The robot picker was getting stuck. When it tried to grab a
tape from a slot or put a tape into a drive (or put a tape back into a
slot), it would get stuck with the tape partially in the slot/drive and
the robot picker. This pinned the robot so it couldn't move.
IBM replaced multiple picker assemblies. After a replacement it would
work for a while, then start having the problems again, and would get
progressively worse. We were getting multiple events per day! The
library error log showed many more errors than just then ones that caused
the robot to hang. These other errors it was able to recover from.
Long story short . . . As tapes were inserted removed from and inserted
into cells, the cells were creating a dust which was causing ware on the
picker. This is a known issue with some plastic cells from a certain
date/time of manufacture. IBM replaced all the plastic cells in the
library. Yup . . .on an outage IBM opened up the the frames, removed all
the tapes, removed the plastic cells, installed new cells, put the tapes
back in. When done we inventoried the library and all was good.
Rick
From: "Stout, Susie (NIH/CIT) [E]" <stouts AT MAIL.NIH DOT GOV>
To: ADSM-L AT VM.MARIST DOT EDU
Date: 04/26/2013 10:00 AM
Subject: Equating current 3494 configuration to TS3500
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Slight tangent, Wanda's volume location comment spurred this:
We upgraded our SCSI 3584 offsite lib to ALMS, no problems...but the
onsite ALMS install went horribly wrong...(maint windows are rare, we did
several things). Afterwards the lib couldn't reliably find a particular
tape with both (robot) hands. Some days it could find some vols, other
days those had slid out and it would forget others -- and not just a few,
but 60 to 100 of them (10-25% of the lib)!...NO extraordinary measures
(like emptying frames and re-inserting) resolved the problem. Our OEM
maintenance could not find the problem and shrugged and walked off after a
couple of months, intimating it was OUR problem and would not bring in
IBM. A lot of time was spent looking through all 3 frames for a
particular volume that was needed; reclamation couldn't find volumes
either. We took outages, powered down the lib...lib and server...the
problem persisted. It was ugly, VERY ugly.
Oddly, no regular pub (TSM books, IBM hardware/operator manuals, device
manuals or stuff online) told you where the *hardware* stores the volume
locations...I stumbled on an obscure 4-5 page blurb from a tape plant
engineer with that magic sentence: the volume physical location
information is stored in the robot's node cards!! That was the key!
We resolved the problem by killing it dead....powered it down (nicely),
pulled the physical power, then pulled the (?9V?) battery from the robot
to clear the CMOS, waited awhile for all memory to die, and powered
everything back up. Of course it was a blithering idiot...all upgrades
were lost. (We were delayed a bit because of the upgrade keys -- the lib
was shipped with the capacity expansion feature but the plant didn't put a
code sticker in the lib or on any documents...after confirming a key was
required, I finally found a nice guy in Mexico who could still generate
the code!).
Does ALMS change the node cards' function? I suspect not but don't know
for sure. For some reason I haven't screwed up the courage to reinstall
ALMS, but may do so -- we recently went back to IBM maintenance. :) -
Susie
-----------------
The "virtual I/O slots" only get involved when you put cartridges in
through the 16/32 slot physical I/O door. For the initial library load,
just open the BIG doors and put the tapes directly into the slots
yourself.
Then for a SCSI library, the syntax for CHECKIN is slightly different than
for your 3494.
checkin libv bubba search=yes status=scratch checklabel=barcode waitt=0
volrange=TS1000,TS1999
checkin libv bubba search=bulk status=scratch checklabel=barcode waitt=0
Search=YES tells TSM to checkin from the INSIDE library slots.
Search=bulk tells TSM to checkin what's in the I/O door (with ALMS, it's a
virtual I/O door, but TSM doesn't know that.)
FWIW:
For the 3494, TSM just tells the 3494 what it wants done, and doesn't know
or care where in the library tapes are located. All the inventory
management is done outboard by the 3494.
If TSM tells the 3494 to mount a cartridge, he doesn't need to know where
the cartridge is, that's handled by the 3494
For a SCSI library, including the TS3500 doing business as a 3584, TSM has
to figure out what tapes are in what slots at checkin time, and saves the
slot numbers in devconfig so he can send the appropriate commands for
cartridge movement. (e.g., take cartridge from slot 1024, load in drive
position 6). That's why the checkin commands are different.
-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
|
