Agreed; you are a perfect candidate for ALMS. It makes the 3500 behave more like a 3494 - it queues ejects. If the I/O station is full, the next ejects land in the "virtual" I/O slots; as soon as ops clears the physical I/O slots, the library will push out the next 16 (or 32) that are queued.
You would be better off (you don't have to write/maintain scripts). Your ops staff would be better off (they only have to go unload it once per day). W On 7/28/08, Len Boyle <[EMAIL PROTECTED]> wrote: > > 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:[EMAIL PROTECTED] On Behalf Of > Schneider, John > Sent: Monday, July 28, 2008 10:01 AM > To: ADSM-L@VM.MARIST.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: [EMAIL PROTECTED] > > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of > Bell, Charles (Chip) > Sent: Monday, July 28, 2008 8:49 AM > To: ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] On Behalf Of > Steven Harris > Sent: Saturday, July 26, 2008 7:39 AM > To: ADSM-L@VM.MARIST.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: [EMAIL PROTECTED] > > > > > > 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. >
