Following the discussion here (and in past months), part of the
problem is the way libraries respond. I believe (Tivoli maybe coluld
chime in and give the fine points on this) that when audit library
checkl=barcode is issued that a certain SCSI command is sent to
library.
With the varied libraries out there supported, from simple to complex,
the library interprets the command slightly differently in what it is
requested to do. So as they say on TV "Your results may not be the
same" - or is that what your stock broker says?
On the things getting out of sync question. I just looked at the help
audit library command on a TSM 4.2.2.10 server. Notice the wording
carefully:
"TSM deletes missing volumes and updates moved volume locations. TSM
does not automatically add new volumes; you must check in new volumes
with the CHECKIN LIBVOLUME command."
I think the implication is that it does nothing else. That is if you
manually
put a tape in the library without the checkin command and then run
inventory/audit, TSM wil not pick it up.
Also for instance in cases I have personally seen, if you do a
checkout
and bulk I/O is full, the the prompt to operators is to remove tape
xxx
from slot yyy. If the operator isn't paying attention and replies to
this,
then that tape is removed from TSM inventory but is STILL in the
library.
An audit and inventory will not put it back up into TSM's inventory.
There
are a few other slight variations on this that I have seen, but you
get the idea. I believe these circumstnace would be the same for
all automated libraries but am not completely sure.
How do you find these tapes then? Send me $5.95 plus shipping
and handling and I'll send you instructions on how! But seriously
folks, that's what they pay us the BIG bucks for. In a sentence
of two: run a q libvol from TSM and in very close time sequence
run an inventory for your library with say tapeutil. (Tapeutil
will show ALL tapes, no matter how they got in library). Then do
a comparison. Some libraries you may have to open and do a slot
by slot comparison.
As an alternative to q libvol which puts tapes in volser order use this
select
which puts them in element order:
select volume_name,home_element from libvolumes order by home_element
David B. Longo
System Administrator
Health First, Inc.
3300 Fiske Blvd.
Rockledge, FL 32955-4305
PH 321.434.5536
Pager 321.634.8230
Fax: 321.434.5509
david.longo AT health-first DOT org
>>> msimpson AT UKY DOT EDU 10/22/02 02:53PM >>>
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 AT uky DOT 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.
"MMS <health-first.org>" made the following
annotations on 10/22/2002 03:33:51 PM
------------------------------------------------------------------------------
This message is for the named person's use only. It may contain confidential,
proprietary, or legally privileged information. No confidentiality or
privilege is waived or lost by any mistransmission. If you receive this
message in error, please immediately delete it and all copies of it from your
system, destroy any hard copies of it, and notify the sender. You must not,
directly or indirectly, use, disclose, distribute, print, or copy any part of
this message if you are not the intended recipient. Health First reserves the
right to monitor all e-mail communications through its networks. Any views or
opinions expressed in this message are solely those of the individual sender,
except (1) where the message states such views or opinions are on behalf of a
particular entity; and (2) the sender is authorized by the entity to give such
views or opinions.
==============================================================================
|
