There is a least one alternative method of letting the Operators know that the
i/o station is full and one method of not worrying about the i/o station being
full in the numbers that you are using.
1) You can turn on snmp traps for the library. One of the traps that the
library generates is that the i/o station has been in a full state for more
than 5 mins. Your snmp trap handler can send the trap information to the
Operators.
2) If you purchase the ALMS feature for the library (I am not sure if you can
talk to IBM or their rep to reduce the price from the list value, this is a
onetime feature for the library that virtualizes the slots and the i/o station.
It allows you to define the virtual i/o station to be up to 255 slots. This
means that at your current rate of 40-60 exports tapes a day, you are not going
to fill the virtual i/o station.
len
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Schneider, John
Sent: Monday, July 28, 2008 10:01 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Method to count tapes in I/O slots of IBM3584 library
Chip,
Thanks for your reply.
I am familiar with the 3584's GUI, and use it all the time. My
script was meant to be an alert. If I could count on the Operators to
remember every 30 minutes all day to go take a look at the 3584 GUI and
see if there are tapes to check out, then I wouldn't need an alert.
But our Operators are busy all day with other things, and need
to be reminded or it doesn't happen. And we have 40-60 tapes going out
every day, so if they don't empty it regularly, things back up behind
the checkout commands. The script as it is written today can count how
many tapes are in the slots, and alert when there are 24 or more, which
is better than waiting until it is totally full.
Best Regards,
John D. Schneider
Phone: 314-364-3150
Cell: 314-750-8721
Email: John.Schneider AT Mercy DOT net
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Bell, Charles (Chip)
Sent: Monday, July 28, 2008 8:49 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Method to count tapes in I/O slots of IBM3584
library
Another way is to activate the 3584 GUI, and give them the link. That's
how I
enabled our operators to look at various things, such as how many slots
are
empty in the library, for those days when we get back from offsite more
tapes
than we have slots for. Ask your IBM tech. You can do all sorts of
things
with, such as update microcode/firmware, look at logs, run inventory,
send
emails, etc., etc.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Steven Harris
Sent: Saturday, July 26, 2008 7:39 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Method to count tapes in I/O slots of IBM3584
library
John,
If I'm reading it correctly, the SML-MIB_112.mib file describes
structures in the library that can be walked with SNMP.
physicalMediaTable might be the one to look at, I have no access to a
library just at present so I can't test.
Alternatively, define another control path and use it just to run your
tapeutil commands.
HTH
Steve
Steven Harris
TSM Admin
Sydney Australia.
Schneider, John wrote:
> Greetings,
> We have an IBM3584 library. We needed a script which would
> determine how many tapes were in the I/O doors of the library, and
then
> send an email to the Operators to empty the I/O doors when the
library
> was mostly full. We fill the I/O door several times a day in the
course
> of daily processing, so we need to notify the Operators regularly.
The
> way that seemed the best to do this was a script which issued:
>
> tapeutil -f /dev/smc1 inventory -i > /tmp/tapeinventory.out
>
> The output file is easy to parse, and count how many slots contain
> media, and spit out the email accordingly. We run the script every 30
> minutes. But now that we have been running the script a couple weeks,
> several times we have gotten TSM errors like this:
>
>
> 07/25/08 05:35:00 ANR8965W The server is unable to automatically
> determine
> the serial number for the device. (SESSION:
> 21742)
> 07/25/08 05:35:00 ANR8840E Unable to open device /dev/smc1 with
file
> handle
> 11. (SESSION: 21742)
>
> 07/25/08 05:35:00 ANR8848W Drive LTO4_F1_D08 of library SUN2079 is
>
> inaccessible; server has begun polling drive.
> (SESSION:
> 21742)
>
> 07/25/08 05:35:00 ANR1794W TSM SAN discovery is disabled by
options.
>
> (SESSION: 21742)
>
> 07/25/08 05:35:00 ANR8965W The server is unable to automatically
> determine
> the serial number for the device. (SESSION:
> 21742)
> 07/25/08 05:35:00 ANR8840E Unable to open device /dev/smc1 with
file
> handle
> 11. (SESSION: 21742)
>
> 07/25/08 05:35:00 ANR8848W Drive LTO4_F1_D06 of library SUN2079 is
>
> inaccessible; server has begun polling drive.
> (SESSION:
> 21742)
>
> 07/25/08 05:35:00 ANR1794W TSM SAN discovery is disabled by
options.
>
> (SESSION: 21742)
>
> 07/25/08 05:35:00 ANR8965W The server is unable to automatically
> determine
> the serial number for the device. (SESSION:
> 21742)
> 07/25/08 05:35:00 ANR8840E Unable to open device /dev/smc1 with
file
> handle
> 11. (SESSION: 21742)
>
> 07/25/08 05:35:00 ANR8848W Drive LTO4_F1_D10 of library SUN2079 is
>
> inaccessible; server has begun polling drive.
> (SESSION:
> 21742)
>
> 07/25/08 05:35:00 ANR1794W TSM SAN discovery is disabled by
options.
>
> (SESSION: 21742)
>
>
> >From the timestamp we know it is exactly when our script which issues
> the tapeutil command is running. Apparently there are times when
> issuing tapeutil interferes with TSM issuing commands through the
> /dev/smc1 device to the library. Perhaps tapeutil makes the device
busy
> for just a second? I think that is the reason, because when I was
> writing the script sometimes it would get a "device busy" error from
> tapeutil, so my script had to be sensitive to that error, wait a few
> seconds, and try again.
>
> Does anybody know of a way around this? Anybody else done something
> similar. Is there a way via IP to get this information from the
library
> that won't interfere with /dev/smc1?
>
> Best Regards,
>
> John D. Schneider
> Lead Systems Administrator - Storage
> Sisters of Mercy Health Systems
> Email: John.Schneider AT Mercy DOT net
>
>
> This e-mail contains information which (a) may be PROPRIETARY IN
NATURE OR
> OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only
for
the
> use of the addressee(s) named above. If you are not the addressee, or
the
> person responsible for delivering this to the addressee(s), you are
notified
> that reading, copying or distributing this e-mail is prohibited. If
you
have
> received this e-mail in error, please contact the sender immediately.
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.5.5/1571 - Release Date:
7/24/2008
5:42 PM
>
>
>
>
-----------------------------------------
Confidentiality Notice:
The information contained in this email message is privileged and
confidential information and intended only for the use of the
individual or entity named in the address. If you are not the
intended recipient, you are hereby notified that any dissemination,
distribution, or copying of this information is strictly
prohibited. If you received this information in error, please
notify the sender and delete this information from your computer
and retain no copies of any of this information.
This e-mail contains information which (a) may be PROPRIETARY IN NATURE OR
OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the
use of the addressee(s) named above. If you are not the addressee, or the
person responsible for delivering this to the addressee(s), you are notified
that reading, copying or distributing this e-mail is prohibited. If you have
received this e-mail in error, please contact the sender immediately.
|
