I stand by the statement that the 3494 volume claiming is working as
designed.
I have a 3494 which for the last 6 years is used concurrently by:
multiple non-shared os/390 lpars
two disparate as/400 systems
multiple rs/6k servers
2 TSM systems
Yes, it is up to the 'host software' to maintain category limits. In
every one of these 'host' environments, the 'host software' is a
combination of system or product software and user written code. None of
these systems uses a pure search technique, there's always some user code
to help each system 'know' what its' valid tapes are. In some it's just a
little harder to find the user code. I further use a different volser
range for each platform to aid in more generic user code. I don't see any
way that a robotic tape server able to hook up to a plethora of platforms
and software could be expected to isolate categories. Also think of error
conditions. There is no way in for the 3494 to move or recategorize
tapes. Those commands must come from attached hosts.
OK, this is all a learning curve. Been there did that. But I think it
works.
my .02
Al Barth
"Seay, Paul" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
03/19/02 03:03 PM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: 3494 Volume Stealing
Actually, Nick we think there really is a bug. I saw something similar
once
on Netbackup. Essentially, the 3494 inventory count got off from the
actual
number of entries presented in the SEARCH=YES type CHECKIN equivalent in
NetBackup. After we ran a full offline inventory of the library the
problem
went away for a week or two and would come back. Eventually, we got a LM
code level that apparently fixed the corruption problem. Have not seen it
for a long time.
-----Original Message-----
From: Nicholas Cassimatis [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 19, 2002 10:07 AM
To: [EMAIL PROTECTED]
Subject: Re: 3494 Volume Stealing
This falls under the old "Measure twice, cut once" rule. If you're
sharing
a library and NOT doublechecking yourself, you're asking for trouble.
Plain
and simple. Don't describe a "defect" to something that is working at
the
level it's designed to. The nice thing about a shared library is you can
have a pool of "spare" tape to assign to any server you want to, as
needed.
Checkout and checkin of tape can be a destructive process, and shouldn't
be
taken too lightly.
Nick Cassimatis
[EMAIL PROTECTED]
Today is the tomorrow of yesterday.
"Orville L.
Lantto" To:
[EMAIL PROTECTED]
<orville.lantto@D cc:
TREND.COM> Subject: Re: 3494 Volume
Stealing
Sent by: "ADSM:
Dist Stor
Manager"
<[EMAIL PROTECTED]
.EDU>
03/15/2002 05:43
PM
Please respond to
"ADSM: Dist Stor
Manager"
The volume which was "stolen" was checked in to another TSM server with
that
server's scratch category code (verified by mtlib). Yes, this is very
disturbing!
Orville L. Lantto
Datatrend Technologies, Inc. (http://www.datatrend.com)
121 Cheshire Lane #700
Minnetonka, MN 55305
Email: [EMAIL PROTECTED]
V: 952-931-1203
F: 952-931-1293
C: 612-770-9166
"Seay, Paul" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 03/15/02 03:15
PM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: 3494 Volume Stealing
Yes and no. Once a tape is ejected from the library, when it is
reinserted,
it is anybody's game because it does not belong to a specific TSM server.
It
is in FF00 status. So, if you do a checkin command with a range,
search=yes, another TSM Server could get it. This is why I do checkin
commands with a specific volume id when I checkin each tape.
At Share we have asked for a function to be added in general to setup an
include table for each TSM server. This include table would limit what
ranges of tapes are allowed to be picked up by that TSM server instance.
Now, if the tapes are already in the library and assigned a scratch or
private category and the tapes can be stolen, that is a major problem that
support needs to know about. I have never tried to see if I can cause one
TSM to steal tapes from another TSM server this way.
-----Original Message-----
From: Orville L. Lantto [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 15, 2002 2:51 PM
To: [EMAIL PROTECTED]
Subject: 3494 Volume Stealing
I just tested a problem brought to me by one of my clients. They have one
3494 library shared by four TSM Servers. Using 4.2.1 TSM, properly
configured with different 3494 Categories, it is possible for one TSM
server
to steal a volume that is checked in to another TSM server. This behavior
is not exhibited by 3.7.3.
Has anyone seem this?
Orville L. Lantto
Datatrend Technologies, Inc. (http://www.datatrend.com)
121 Cheshire Lane #700
Minnetonka, MN 55305
Email: [EMAIL PROTECTED]
******************* PLEASE NOTE *******************
This message, along with any attachments, may be confidential or legally
privileged. It is intended only for the named person(s), who is/are the
only authorized recipients. If this message has reached you in error,
kindly destroy it without review and notify the sender immediately. Thank
you for your help.
**********************************************************
