We too have a 3584. When an AUDIT LIBRARY checklabel=barcode (run daily) occurs, the arm moves over the entire library of tapes, reading the barcodes. I have witnessed this. If there is something that was done at installation time, of our LTO, to effect this, I couldn't say. Maybe someone out there, intimate with the hardware, can let us all know.
Ken [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 10/22/2002 11:53:54 AM >>> At 11:03 AM -0700 10/22/02, KEN HORACEK said: >With checklabel=barcode, all of the barcodes are read. This is then >checked with the internal memory of the library as to what the >library's inventory says is where. That's not what I'm seeing, and that's not what I think I'm reading from others here. When I execute the audit checklabel=barcode for our 3584 library, it completes almost instantaneously with no movement of the library robotics. I don't see how it could possibly be reading the barcode labels. I suspect it's doing what I think others have suggested: "remembering" the barcode labels that it has read previously. At 2:02 PM -0400 10/22/02, David Longo wrote: >I imagine the checkl=barocde was introduced to shorten audit, without >it you would have to mount every tape in library - which would take >some considerable time with some libraries! I understand that reading the barcode is a good alternative to mounting the tape and reading the internal label. But what I'm saying is that it doesn't appear to be reading the barcodes when the audit is executed. > What you are doing is >checkinbg the barcode label in library memory as opposed to checking >the >magnetic tape label header. That's what I thought .. checking the barcode label in library memory. But in my interpretation, checklabel=barcode should mean read the barcode now, not tell me what it thinks it is based on its memory of the last time it read it. > >The ideal short way is to have the library do it's inventory, which >reads >barcodes and is quick, then do audit with checkl=barcode. OK .. thatmakes sense. The library inventory physically reads the barcode labels and updates the internal memory if necessary, and then the TSM audit checklabel=barcode causes the library's memory to be synced with TSM. In my opinion, the ideal short way would be to have the TSM audit checklabel=barcode command really tell the library to read the barcodes, eliminating the need to do the library inventory in a previous step. When I say checklabel=barcode, I mean checklabel=barcode, I don't mean check your internal memory. But I don't know if that's a limitation in the library or TSM. -- Matt Simpson -- OS/390 Support 219 McVey Hall -- (859) 257-2900 x300 University Of Kentucky, Lexington, KY 40506 <mailto:msimpson@;uky.edu> mainframe -- An obsolete device still used by thousands of obsolete companies serving billions of obsolete customers and making huge obsolete profits for their obsolete shareholders. And this year's run twice as fast as last year's. ----------------------------------------------------- This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. ----------------------------------------------------- <<<<GWIASIG 0.07>>>>