Re: 3494 Volume Stealing
Al, your approach looks for me as Windows 9x security - every program will release the processor with good will and every user will try not to overwrite files of the others. So lets be cooperative ?! If we are talking about *enterprise* product we should ensure security not assume it. So my vote goes to Paul. I do not have 3494 to verify what you've tested. For me it looks that LM does work "as designed" so this is not bug in 3494. However APAR reported by Orville clearly identifies this as TSM bug. And our cooperative security becomes dead. So why not to open request for enhancement/re-design. I've never had cent coins, so get this as 0.02 in my currency (cheaper than $ :-) Zlatko Krastev IT Consultant Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by:"ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject:Re: 3494 Volume Stealing Paul, It's clear to me that we disagree. I understand and accept the inter-operating parameters and requirements of the 3494, and have installed and/or written code residing on each attached host to only look for tapes that it owns. I don't do scans - period. I think your reference to the Shark disk server capabilities is an apples to oranges comparison. For one, Shark lun inventories are a stable commodity (unless more dasd is added and LSS's are created) in that they (luns) don't checkin/checkout like tapes do in a tape library. For another, YOU don't get to pick what the luns are called, but YOU do get to pick what tape volsers you'll use. And what about VTS? One of my 3494s has VTS enabled and the carts used by the VTS function aren't owned or managed by ANY externally attached system. This has caused no impact to me. Now I'm not saying that the 3494 is perfect. There are definitely functions that I'd like to see added. For example, ever try to find out the volser of a cart in cell xxx after the label fell off? There's only 1 painful waypull up a chair and slowly wade through the inventory on the LM console until you find it. There is no perfect solution to disparate systems claiming tapes, but the more responsibility you off-load, the less flexibility you will get. Regards, Al Barth "Seay, Paul" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 03/19/02 11:00 PM Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject:Re: 3494 Volume Stealing Allen, I do not normally boast about my knowledge on something but in this area of this product I know it as well as the engineers do and probably better when considering its interaction with host systems. I have actually run the traces and I can tell you that the buffers returned from the 3494 during an inventory function are in error in some cases because of an internal bug in the LM. This bug can cause software that does no error checking to get all balled up and do something wrong. It is kind of like adding 1 + 1 and expecting to always get 2. The way the LM inventory search facility works (TSM uses this) is it passes back 100 tapes at a time. The first buffer has a header on it that has the total count of entries. The last buffer is what is left. Unfortunately, the buffer is not cleared, so there is residual data in the buffer from previous calls. The last entry in the last buffer has a null entry in it. IBM never tested the count always being right. And, in fact determined they have no way to guarantee the count is correct because they just get the count from a DB2 table on the LM, they do not count the number of entries they are returning. So, any application that does not scan for the null entry can end up picking up bogus information. Note that these buffers can contain all tapes for all hosts, not just the ones for a specific category. The category is in the records returned. Usually, the counter is short and you are missing tapes, but I suppose it could be high and cause the logic to process volumes that are not yours. Just food for thought. There is no user code in my environment. In the case I described below, there was only one host attached to this library and it was non-mixed. We just kept getting 2 tapes or 4 tapes short of what was actually in the library. If you read the 3494 programmers guide you will find that there is a lot more to this than meets the superfical mtlib command. There is a whole set of c routines to allow you to code to the lmcpd interface. In fact, I am in the process of designing an insert and categorize function for TSM. Then, I will have some user code. It will work like the mainframe, automatically categorize the tapes and check them in. The way I am going to do this is execute a high level language perl script that can be recoded easily that wi
Re: 3494 Volume Stealing
Here is the APAR covering the problem. I do not know when it was created. APAR= IC33056 SER=IN INCORROUT TSM 4.2.1 3494 CATEGORIES SCRATCH PRIVATE INSERT Status: OPENClosed: Apar Information: RCOMP= 5698TSMAXTSM AIX SERVER RREL= R420 FCOMP= PFREL= F TREL= T Return Codes: Applicable Component Level/SU: Error Description: When multiple TSM V4.2.1 Servers are using the same partitioned 3494 Tape Library it is possible for a volume to get checked into the wrong server. As of 4.2.1 and higher the TSM server will not check what category a volume belongs to during a "checkin libvol xx search=no" command. Therefore it is possible for a volume belonging to one TSM server to get checked into a different TSM server. The Server will change the volume category to reflect the category assigned to that particular status for that specific TSM server. This issue will only occur when a manual checkin is done and the "search=no" parameter is used. This particular issue was found when a customer setup multiple instances of the TSM Server on the same Unix machine but can also occur when two separate machines are used to access a partitioned 3494 Tape Library. Output from a PVR trace will show TSM recognizing that the volume being checked in has a different category than what has been defined for that server instance, for example;362 TSM changing the tape category to cat=65280 (FF00) (the insert category) then changing the category to the appropriate status for that server, for example; 372 for a scratch tape. .. Local Fix: 1) Make sure that volumes belonging to one TSM server are not being checked into either a separate instance or different TSM Server. 2) Apply the fixtest when released Problem Summary: Temporary Fix: Comments: Problem Conclusion: Orville L. Lantto Datatrend Technologies, Inc. (http://www.datatrend.com) 121 Cheshire Lane #700 Minnetonka, MN 55305 Email: [EMAIL PROTECTED] V: 952-931-1203
Re: 3494 Volume Stealing
This is true, it will always be able to do that until hardware security is placed in the 3494 library or TSM puts the include/exclude function in. However, your original problem was that it was checking in tapes that belonged to other TSM servers already during a CHECKIN command of an inserted tape. Unless there is a bug, the only way this can happen is a Search=yes and a range specification that overlaps the other server. -Original Message- From: Orville L. Lantto [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 7:16 PM To: [EMAIL PROTECTED] Subject: Re: 3494 Volume Stealing An update: The server was updated to 4.2.1.11, Atape to 7.0.3.0, atldd to latest. Result: I can still check-in tapes which are checked into another TSM server. TSM ignores the category on the tape and just grabs the tape and changes the category. Orville L. Lantto Datatrend Technologies, Inc. (http://www.datatrend.com) 121 Cheshire Lane #700 Minnetonka, MN 55305 Email: [EMAIL PROTECTED]
Re: 3494 Volume Stealing
I guess being a defense contractor I have a different take on data security. I call the Internet the "Network of Death" because of the potential exposures that are there because the "that's good enough is rampant". In my business it is either secure or it isn't. I sell security of their information to my customer as much as I sell the product. For this reason we have to jump through hoops to protect information when the product does not complete the solution. In the case of the 3494, I cannot share it in any way with more than one customer making it expensive. The reason is I cannot block a rogue host from doing something it shouldn't. A host becomes rogue when it is broken into. It is not a question of if but when. I need to be able to have many tiers of security. Sharing resources is not possible in the 3494 environment without creating an exposure unless all the systems attached are of the same security categorization and enforce the same security constructs meaning they are owned by the same management team. So, again, my take is just a little different. One thing I can tell you is there were a room full of people in various industries concerned about this issue at Share. And, like at Share, we as competent professionals can agree to disagree on the grounds of our business requirements. That is why we have a thing called requirements voting, a democratic way to influence the direction of IBM dollars spent on research and development. I agree with you on the subject of not doing library range scans because you have no idea what is going to happen. I do not use them either. Not even on a move drmedia command. The bottom line if you do a '*' and have no idea what is there you have no idea what you will get. And, actually, in our environment we do a lot of moving ownership of LUNs around in our Sharks as workload requires them (unassign from one and reassign to another) so I get to decide who can see these LUNs at any point in time. And, in fact, I can allow more than one system to see the same LUN if I wish. The Shark autonumbers the LUNs. That is a minor semantic of the discussion. The important thing from my point of view I get to say who can see what LUNs. And, no matter what kind of GOD you are you cannot get past that. All Share is asking for is at the hardware level of the 3494 allow us to do the same thing for volumes whether they are virtual VTS volumes or physical volumes. I think you would agree even in the financial industry this would be an added value security function when many hosts have been given mtlib equivalent access to the Library Manager. Thus comparing the ESS to the 3494 is very applicable to this discussion when you think of the ESS being delivered by default with LUN access restricted, but you can turn it off and the 3494 is delivered with no volume security and no way to turn it on. Thanks for this healthy debate of the issues. It helps put into perspective the quality of people on this List Server and their ability to philosophically debate a subject. We all win from a discussion like this. It fuels the best in innovation by our vendors as they develop future products. You get one more rebutal. -Original Message- From: Allen Barth [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 5:00 PM To: [EMAIL PROTECTED] Subject: Re: 3494 Volume Stealing Paul, It's clear to me that we disagree. I understand and accept the inter-operating parameters and requirements of the 3494, and have installed and/or written code residing on each attached host to only look for tapes that it owns. I don't do scans - period. I think your reference to the Shark disk server capabilities is an apples to oranges comparison. For one, Shark lun inventories are a stable commodity (unless more dasd is added and LSS's are created) in that they (luns) don't checkin/checkout like tapes do in a tape library. For another, YOU don't get to pick what the luns are called, but YOU do get to pick what tape volsers you'll use. And what about VTS? One of my 3494s has VTS enabled and the carts used by the VTS function aren't owned or managed by ANY externally attached system. This has caused no impact to me. Now I'm not saying that the 3494 is perfect. There are definitely functions that I'd like to see added. For example, ever try to find out the volser of a cart in cell xxx after the label fell off? There's only 1 painful waypull up a chair and slowly wade through the inventory on the LM console until you find it. There is no perfect solution to disparate systems claiming tapes, but the more responsibility you off-load, the less flexibility you will get. Regards, Al Barth "Seay, Paul" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 03/19/02 11:00 PM Please respond to "ADSM: Dist Stor Manager
Re: 3494 Volume Stealing
An update: The server was updated to 4.2.1.11, Atape to 7.0.3.0, atldd to latest. Result: I can still check-in tapes which are checked into another TSM server. TSM ignores the category on the tape and just grabs the tape and changes the category. Orville L. Lantto Datatrend Technologies, Inc. (http://www.datatrend.com) 121 Cheshire Lane #700 Minnetonka, MN 55305 Email: [EMAIL PROTECTED]
Re: 3494 Volume Stealing
Paul,
It's clear to me that we disagree. I understand and accept the
inter-operating parameters and requirements of the 3494, and have
installed and/or written code residing on each attached host to only look
for tapes that it owns. I don't do scans - period. I think your
reference to the Shark disk server capabilities is an apples to oranges
comparison. For one, Shark lun inventories are a stable commodity (unless
more dasd is added and LSS's are created) in that they (luns) don't
checkin/checkout like tapes do in a tape library. For another, YOU don't
get to pick what the luns are called, but YOU do get to pick what tape
volsers you'll use.
And what about VTS? One of my 3494s has VTS enabled and the carts used by
the VTS function aren't owned or managed by ANY externally attached
system. This has caused no impact to me.
Now I'm not saying that the 3494 is perfect. There are definitely
functions that I'd like to see added. For example, ever try to find out
the volser of a cart in cell xxx after the label fell off? There's only 1
painful waypull up a chair and slowly wade through the inventory on
the LM console until you find it. There is no perfect solution to
disparate systems claiming tapes, but the more responsibility you
off-load, the less flexibility you will get.
Regards,
Al Barth
"Seay, Paul" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
03/19/02 11:00 PM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject:Re: 3494 Volume Stealing
Allen,
I do not normally boast about my knowledge on something but in this area
of
this product I know it as well as the engineers do and probably better
when
considering its interaction with host systems. I have actually run the
traces and I can tell you that the buffers returned from the 3494 during
an
inventory function are in error in some cases because of an internal bug
in
the LM. This bug can cause software that does no error checking to get
all
balled up and do something wrong. It is kind of like adding 1 + 1 and
expecting to always get 2. The way the LM inventory search facility works
(TSM uses this) is it passes back 100 tapes at a time. The first buffer
has
a header on it that has the total count of entries. The last buffer is
what
is left. Unfortunately, the buffer is not cleared, so there is residual
data in the buffer from previous calls. The last entry in the last buffer
has a null entry in it. IBM never tested the count always being right.
And, in fact determined they have no way to guarantee the count is correct
because they just get the count from a DB2 table on the LM, they do not
count the number of entries they are returning. So, any application that
does not scan for the null entry can end up picking up bogus information.
Note that these buffers can contain all tapes for all hosts, not just the
ones for a specific category. The category is in the records returned.
Usually, the counter is short and you are missing tapes, but I suppose it
could be high and cause the logic to process volumes that are not yours.
Just food for thought. There is no user code in my environment.
In the case I described below, there was only one host attached to this
library and it was non-mixed. We just kept getting 2 tapes or 4 tapes
short
of what was actually in the library. If you read the 3494 programmers
guide
you will find that there is a lot more to this than meets the superfical
mtlib command. There is a whole set of c routines to allow you to code to
the lmcpd interface. In fact, I am in the process of designing an insert
and categorize function for TSM. Then, I will have some user code. It
will
work like the mainframe, automatically categorize the tapes and check them
in. The way I am going to do this is execute a high level language perl
script that can be recoded easily that will do the necessary mtlib and TSM
commands. This will limit the unsolicited messages processing in the
coded
routine significantly.
I know the site that is having this problem with the 4 TSM Servers. This
is
a tight environment. Another site that has an MVS and TSM environment had
an MVS tape eaten. Both are in the process of reproducing this problem at
will.
This may still be a user problem, but I am betting either TSM code or the
Library Manager.
What everyone is asking for is security by the attaching node as to which
tapes can be acted upon by volume range. This was discussed at length at
Share related to TSM because no other libraries have the kind of smarts
the
3494 or ACSLS have to even do this in hardware. The position of the
customers including us is that the 3494 is an enterprise class, high
integrity, high dollar product. Yes, the functionality is not there in
the
LM, but the amount of code to do a table check of valid ranges is
Re: 3494 Volume Stealing
Allen, I do not normally boast about my knowledge on something but in this area of this product I know it as well as the engineers do and probably better when considering its interaction with host systems. I have actually run the traces and I can tell you that the buffers returned from the 3494 during an inventory function are in error in some cases because of an internal bug in the LM. This bug can cause software that does no error checking to get all balled up and do something wrong. It is kind of like adding 1 + 1 and expecting to always get 2. The way the LM inventory search facility works (TSM uses this) is it passes back 100 tapes at a time. The first buffer has a header on it that has the total count of entries. The last buffer is what is left. Unfortunately, the buffer is not cleared, so there is residual data in the buffer from previous calls. The last entry in the last buffer has a null entry in it. IBM never tested the count always being right. And, in fact determined they have no way to guarantee the count is correct because they just get the count from a DB2 table on the LM, they do not count the number of entries they are returning. So, any application that does not scan for the null entry can end up picking up bogus information. Note that these buffers can contain all tapes for all hosts, not just the ones for a specific category. The category is in the records returned. Usually, the counter is short and you are missing tapes, but I suppose it could be high and cause the logic to process volumes that are not yours. Just food for thought. There is no user code in my environment. In the case I described below, there was only one host attached to this library and it was non-mixed. We just kept getting 2 tapes or 4 tapes short of what was actually in the library. If you read the 3494 programmers guide you will find that there is a lot more to this than meets the superfical mtlib command. There is a whole set of c routines to allow you to code to the lmcpd interface. In fact, I am in the process of designing an insert and categorize function for TSM. Then, I will have some user code. It will work like the mainframe, automatically categorize the tapes and check them in. The way I am going to do this is execute a high level language perl script that can be recoded easily that will do the necessary mtlib and TSM commands. This will limit the unsolicited messages processing in the coded routine significantly. I know the site that is having this problem with the 4 TSM Servers. This is a tight environment. Another site that has an MVS and TSM environment had an MVS tape eaten. Both are in the process of reproducing this problem at will. This may still be a user problem, but I am betting either TSM code or the Library Manager. What everyone is asking for is security by the attaching node as to which tapes can be acted upon by volume range. This was discussed at length at Share related to TSM because no other libraries have the kind of smarts the 3494 or ACSLS have to even do this in hardware. The position of the customers including us is that the 3494 is an enterprise class, high integrity, high dollar product. Yes, the functionality is not there in the LM, but the amount of code to do a table check of valid ranges is small. Each host has to be identified to the 3494 library, why not add the valid ranges and categories too. The big sell for IBM to do this is if I could secure a library at this level then I could share it between many environments like the Shark Disk LUN masking allows me. In other words consolidate many libraries into one. Yes, a host could still mount its own tapes in the wrong drive, that is its problem as you say or set the hardware scratch mount category on the wrong drive to its own. These are difficult to solve in the library design. But, to allow any system to checkin a FF00 tape or change the category of a tape owned by another host is a problem. By default, what IBM should do is make it work the way it does now. All systems can do anything to "*". Then, you can lock it down if you want. I am going to be discussing this issue with 3494 hardware engineering in a couple weeks hopefully. It has always been an issue for us, but now that people are having these kind of problems, I have sturdier ground to stand on to get IBM to provide the functionality. And why are they having these problems, because everyone wants the reliability of the 3590 platform, have this library already installed and say why not. -Original Message- From: Allen Barth [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 5:50 PM To: [EMAIL PROTECTED] Subject: Re: 3494 Volume Stealing 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
Re: 3494 Volume Stealing
I agree that volume stealing as being discussed here is not a bug but
the actual way the 3494 was designed.
--
Joshua S. Bassi
Sr. Solutions Architect @ rs-unix.com
IBM Certified - AIX/HACMP, SAN, Shark
Tivoli Certified Consultant- ADSM/TSM
Cell (415) 215-0326
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of
Allen Barth
Sent: Tuesday, March 19, 2002 2:50 PM
To: [EMAIL PROTECTED]
Subject: Re: 3494 Volume Stealing
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]
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
Re: 3494 Volume Stealing
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]
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
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]
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]
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]
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]
Re: 3494 Volume Stealing
The 3494 docs clearly state that it is the responsibility of the "host
software" to enforce category limits. I thought that the library
performed this function and still think it should, but it isn't so.
Orville L. Lantto
Datatrend Technologies, Inc. (http://www.datatrend.com)
121 Cheshire Lane #700
Minnetonka, MN 55305
Email: [EMAIL PROTECTED]
Bill Boyer <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
03/18/02 02:40 PM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject:Re: 3494 Volume Stealing
How exactly did you 'steal' it from server A to B? I always thought it was
the responsibility of the library manager component in the 3494 to handle
who owns what. Maybe you should be looking at the code level in the 3494
library manager?? You might want to check out the library manager logs for
around the time when you 'steal' this volume.
Whenever I share a 3494 between multiple TSM servers, I use different
volume
numbering schemes and the CHECKIN command for each server is defined in a
server script with the appropriate VOLRANGE= specified. This is then
scheduled to run daily with an admin command schedule. Then I educate the
client that they should only checkin volumes using the RUN command for the
script I created, or better yet just let the schedule command do it for
them.
Bill Boyer
DSS, Inc.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Orville L. Lantto
Sent: Monday, March 18, 2002 11:53 AM
To: [EMAIL PROTECTED]
Subject: Re: 3494 Volume Stealing
No, I tested with a verified scratch volume from Server A (had Server A's
scratch category, verified with mtlib) and "stole" it directly into
Server B (resulting in Server B's scratch category on the tape). This
should not happen and it is the responsibility of the "host" software to
prevent it. In this case TSM has a flaw. My customer has opened a PMR
and we are pursuing it through Tivoli support.
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
Allen Barth <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
03/18/02 10:09 AM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject:Re: 3494 Volume Stealing
It wasn't stolen. I have seen where the 3494 will eject a cart all on its
own for various reasons. This action is not sent to TSM. Perhaps the
operators saw the tape in the IO door and just pulled it out and put it
back in without letting anyone know. Mine have done that several times,
the volume is then in FF00 category (free for all).In your case
another TSM could have claimed this tape, and a later AUDIT LIBRARY on the
rightful owner would leave the 3494 and the TSM's in the state you
mention.
"Orville L. Lantto" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
03/15/02 04:43 PM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject:Re: 3494 Volume Stealing
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. Lant
Re: 3494 Volume Stealing
How exactly did you 'steal' it from server A to B? I always thought it was
the responsibility of the library manager component in the 3494 to handle
who owns what. Maybe you should be looking at the code level in the 3494
library manager?? You might want to check out the library manager logs for
around the time when you 'steal' this volume.
Whenever I share a 3494 between multiple TSM servers, I use different volume
numbering schemes and the CHECKIN command for each server is defined in a
server script with the appropriate VOLRANGE= specified. This is then
scheduled to run daily with an admin command schedule. Then I educate the
client that they should only checkin volumes using the RUN command for the
script I created, or better yet just let the schedule command do it for
them.
Bill Boyer
DSS, Inc.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Orville L. Lantto
Sent: Monday, March 18, 2002 11:53 AM
To: [EMAIL PROTECTED]
Subject: Re: 3494 Volume Stealing
No, I tested with a verified scratch volume from Server A (had Server A's
scratch category, verified with mtlib) and "stole" it directly into
Server B (resulting in Server B's scratch category on the tape). This
should not happen and it is the responsibility of the "host" software to
prevent it. In this case TSM has a flaw. My customer has opened a PMR
and we are pursuing it through Tivoli support.
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
Allen Barth <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
03/18/02 10:09 AM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject:Re: 3494 Volume Stealing
It wasn't stolen. I have seen where the 3494 will eject a cart all on its
own for various reasons. This action is not sent to TSM. Perhaps the
operators saw the tape in the IO door and just pulled it out and put it
back in without letting anyone know. Mine have done that several times,
the volume is then in FF00 category (free for all).In your case
another TSM could have claimed this tape, and a later AUDIT LIBRARY on the
rightful owner would leave the 3494 and the TSM's in the state you
mention.
"Orville L. Lantto" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
03/15/02 04:43 PM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject:Re: 3494 Volume Stealing
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
Re: 3494 Volume Stealing
> It wasn't stolen. I have seen where the 3494 will eject a cart all on its > own for various reasons. This action is not sent to TSM. Perhaps the > operators saw the tape in the IO door and just pulled it out and put it > back in without letting anyone know. Mine have done that several times, > the volume is then in FF00 category (free for all).In your case > another TSM could have claimed this tape, and a later AUDIT LIBRARY on the > rightful owner would leave the 3494 and the TSM's in the state you > mention. I wrote a script that looks at all tapes in the insert category (FF00), and does the right thing. I share my 3494 between two TSM servers, and two mainframe OS's (1 VM and 1 MVS). My two TSM servers share one large pool of tapes, with each server having it's own private and scratch categories. My script ensures that one TSM server does not checkin the other server's private volumes (storage pool, or dbbackup) as scratch, and visa-versa. Steve Roder, University at Buffalo HOD Service Coordinator VM Systems Programmer UNIX Systems Administrator (Solaris and AIX) TSM/ADSM Administrator ([EMAIL PROTECTED] | (716)645-3564 | http://ubvm.cc.buffalo.edu/~tkssteve)
Re: 3494 Volume Stealing
No, I tested with a verified scratch volume from Server A (had Server A's scratch category, verified with mtlib) and "stole" it directly into Server B (resulting in Server B's scratch category on the tape). This should not happen and it is the responsibility of the "host" software to prevent it. In this case TSM has a flaw. My customer has opened a PMR and we are pursuing it through Tivoli support. 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 Allen Barth <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 03/18/02 10:09 AM Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject:Re: 3494 Volume Stealing It wasn't stolen. I have seen where the 3494 will eject a cart all on its own for various reasons. This action is not sent to TSM. Perhaps the operators saw the tape in the IO door and just pulled it out and put it back in without letting anyone know. Mine have done that several times, the volume is then in FF00 category (free for all).In your case another TSM could have claimed this tape, and a later AUDIT LIBRARY on the rightful owner would leave the 3494 and the TSM's in the state you mention. "Orville L. Lantto" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 03/15/02 04:43 PM Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject:Re: 3494 Volume Stealing 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. **
Re: 3494 Volume Stealing
It wasn't stolen. I have seen where the 3494 will eject a cart all on its own for various reasons. This action is not sent to TSM. Perhaps the operators saw the tape in the IO door and just pulled it out and put it back in without letting anyone know. Mine have done that several times, the volume is then in FF00 category (free for all).In your case another TSM could have claimed this tape, and a later AUDIT LIBRARY on the rightful owner would leave the 3494 and the TSM's in the state you mention. "Orville L. Lantto" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 03/15/02 04:43 PM Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject:Re: 3494 Volume Stealing 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. **
Re: 3494 Volume Stealing
I am beginning to think Tivoli Development has a bug where they are not
clearing the buffer out in the lmcpd interface code or something similar.
The way it works is it gives you 100 tapes at a time. I have heard of this
problem where some mainframe tapes got swallowed as well. I would open a
SEV 1 with Tivoli on this. It is an integrity issue.
-Original Message-
From: Orville L. Lantto [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 15, 2002 5:43 PM
To: [EMAIL PROTECTED]
Subject: Re: 3494 Volume Stealing
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]
Re: 3494 Volume Stealing
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]
Re: 3494 Volume Stealing
The TSM Servers are defined with categories (Private,Scratch):
One: 310,311
Two: 320,321
Three: 330,331
Four: 340,341
The Server option 3494Shared is set to Yes.
Library Shared is set to no.
Platform is AIX 4.3.3.9
"Davidson, Becky" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
03/15/02 03:36 PM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject:Re: 3494 Volume Stealing
What are the categories used?
I would imagine if it didn't do it in 3.7.3 it won't in 4.2.1 I know what
we had in 3.1 transferred fine to 4.1.2
Becky
-Original Message-
From: Orville L. Lantto [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 15, 2002 1: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]
Re: 3494 Volume Stealing
I currently have 4 TSM servers sharing one 3494 ,one version 4.1.4 and three using 3.7 I have each using seperate private categories and scratch categories I have each using specific ranges of tapes. I run checkin scratches each day for a specific range for each server. "Seay, Paul" <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 03/15/2002 04:15:06 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 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]
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]
Re: 3494 Volume Stealing
What are the categories used? I would imagine if it didn't do it in 3.7.3 it won't in 4.2.1 I know what we had in 3.1 transferred fine to 4.1.2 Becky -Original Message- From: Orville L. Lantto [mailto:[EMAIL PROTECTED]] Sent: Friday, March 15, 2002 1: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]
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]
