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
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
: 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
, 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
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
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,
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
#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
.
Lantto To: [EMAIL PROTECTED]
orville.lantto@Dcc:
TREND.COM Subject: Re: 3494 Volume Stealing
Sent by: ADSM:
Dist Stor
Manager
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
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
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
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
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,
]]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
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
]
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
[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
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
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
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
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
22 matches
Mail list logo
