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 <Len.Boyle AT sas DOT com> 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: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.
>