Yes, that is correct. Each TSM server has it's own database.
At 12:08 PM 5/20/2005, Coats, Jack wrote:
If not clustered, they have separate databases and configured
separately. One owns the library to the extent that it controls the
robot. At least that is my understanding. I haven't done it.
Yes, they should be having their own databases and data movement
between them has to be done using export/import commands...
rgds,
Aleem
On 5/20/05, Jon Evans <[EMAIL PROTECTED]> wrote:
> Hi all
>
>
>
> Quick question, which I know is in the manuals somewhere, but I need a
> quick answer and d
If not clustered, they have separate databases and configured
separately. One owns the library to the extent that it controls the
robot. At least that is my understanding. I haven't done it.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Jon Eva
I would be cautious of the tendency to jump to the conclusion that the
database had a problem because you could not query a filespace. As seen
in numerous past postings, filespace visibility issues are often due to
character set code page inconsistencies between the client which
created the filespa
ist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Mark D. Rodriguez
Sent: Tuesday, January 04, 2005 1:44 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Multiple TSM servers on single machine.
Yury,
Not a problem running multiple instances of ITSM server on a single
system. I have worked on machin
Yury,
Not a problem running multiple instances of ITSM server on a single
system. I have worked on machines with 4 ITSM servers on a single AIX
system.
Now the real question is why are you doing an audit db? This is not a
command that should be run casually. You should only be running that
when
Hi Willem
The strange feeling's is this would happen if SAPPROD(on sapprod) requires the same
tape as what SAPPROD (on sapqas)
requires, but if you make all the tapes from readwrite to reado and also if you stop
space reclaim and stop the offsite
copies until your refresh has completed you woul
I would say the advice was incomplete and your "feelings" are quite
correct.
Restore of a TSM server DB is the first step inoperational recovery
process. Next (though not so lengthy) step is to configure the libraries,
drives, paths, and ... storage agents + polled clients.
Imagine the mess when t
. "They cannot reside on the same machine at the
same time."
Does this help any?
lisa
"Fought,Tom"
cc:
Sent by: Subject: Re: Multiple TSM Servers on Same
Host
Thanks so much Lisa. This is exactly what I was looking for.
Tom
-Original Message-
From: Lisa Cabanas [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 1:26 PM
To: [EMAIL PROTECTED]
Subject: Re: Multiple TSM Servers on Same Host
Tom,
In the manual TSM 4.2 for AIX, Quick Start
-
From: Lisa Cabanas [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 05, 2002 11:46 AM
To: [EMAIL PROTECTED]
Subject: Re: Multiple TSM Servers on Same Host
Not necessarily-- if you want different server versions, you will need to
have different environmental variables and separate directories for
Not necessarily-- if you want different server versions, you will need to
have different environmental variables and separate directories for the
different versions.
I am running 3 or 4 different servers on each of two 6M1s, and will have 6
production instances on each when I am thru. I opted to
y manager is in the LTO Open
>Redbook and you just modify what you need for 3494.
>
>Good luck
>Becky
>
>-Original Message-
>From: Kelly J. Lipp [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 14, 2002 4:28 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Multiple
"Davidson, Becky"
cc:
Sent by: "ADSM: Subject: Re: Multiple TSM Servers on
Same Machine
Dist Stor
Manager"
<[EMAIL PROTECTED]
No, you cannot without creating a mess. In fact the way the mount of a
scratch works is not by volume. There is a category mask set for the tape
drive and the library is just told to pick a tape in the category and mount
it in the drive. The privates could be the same I suppose, but it would
re
1-614-308-6637
Cell 1-740-972-6441
Siempre Hay Esperanza
"Davidson, Becky"
cc:
Sent by: "ADSM: Subject: Re: Multiple TSM Servers on
Same Machine
D]
Subject: Re: Multiple TSM Servers on Same Machine
Two ways to set this up:
1. Two separate TSM server sharing the library: use different categories and
be careful.
2. Have one of the servers act as the library manager. The second asks the
first for resources and tape mounts, etc. The first se
Jim,
As documented in 3494 docs, you must use separate category numbers for each
using application/system. Data loss is assured if any use uses the same
category numbers!
Steffan
- Original Message -
From: "Jim Sporer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 14
Two ways to set this up:
1. Two separate TSM server sharing the library: use different categories and
be careful.
2. Have one of the servers act as the library manager. The second asks the
first for resources and tape mounts, etc. The first server knows about all
of scratch volumes, same catego
We share 1 3494 between 2 tsm environments (on different aix boxes...).
We use different scratch categories and private categories, yes...
although we aren't library sharing as far as TSM is concerned.
-Original Message-
From: Jim Sporer [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 1
Try this...
specify different prefixes for the tsm environments in the different
environments
DOUBLE CHECK THIS but I believe if you insert a tape with a volser already
on it and you try to use it as scratch and it has a wrong prefix, the tsm
environment will whine about it and not use it...
(the
>I am worried about our operators accidentally inserting "library-1"
>good tapes (i.e. offsite) into the other "library-2" as scratch.
>The TSM server will add them to the "scratch" pool.
Bill - Richard's idea about using the distinct solid colors around each
library portal is a good one.
If
>I am worried about our operators accidentally inserting "library-1" good
>tapes (i.e. offsite) into the other "library-2" as scratch. The TSM server
>will add them to the "scratch" pool.
Bill - One approach is to apply solid-color labels to each cartridge,
with a big sticker of that color
gt;-Original Message-
>From: Paul Zarnowski [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, May 10, 2001 10:08 AM
>To: [EMAIL PROTECTED]
>Subject: Re: Multiple TSM* Servers On Same Machine
>
>
>The reason I would do it would be to keep the database size down.
>
>At 11:41
We will be looking at running multiple TSM instances, probably on one
box, later this year. Our server has plenty of horsepower and
bandwidth . . . the only reason we may need to do this is database
size.
The more I ponder this the madder I'm getting! Why should I have to
purchase another insta
staggered EXPIRE INVENTORY ( to conserve cpu cycles
"" DB FULL BACKUP "
... etc
Joseph A Faracchio, Systems Programmer, UC Berkeley
Private mail on any topic should be directed to :
[EMAIL PROTECTED]
On Thu, 10 May 2001, Paul Zarnowski wrote:
> The reason I would do it w
That's a good reason ( IMHO ).
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Jim Sporer
Sent: Thursday, May 10, 2001 2:28 PM
To: [EMAIL PROTECTED]
Subject: Re: Multiple TSM* Servers On Same Machine
I do it to run a test TSM server on the
I do it to run a test TSM server on the same machine.
Jim Sporer
At 11:08 AM 5/10/2001 -0400, you wrote:
>The reason I would do it would be to keep the database size down.
>
>At 11:41 AM 5/9/2001 -0400,
>[EMAIL PROTECTED] wrote:
> >Why would one put multiple TSM servers on a single machine?
Hi
But memory utilization , network utilization and CPU utilization and memory
leaks will be high.
Am I right.
-Original Message-
From: Paul Zarnowski [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 10, 2001 10:08 AM
To: [EMAIL PROTECTED]
Subject: Re: Multiple TSM* Servers On Same
The reason I would do it would be to keep the database size down.
At 11:41 AM 5/9/2001 -0400,
[EMAIL PROTECTED] wrote:
>Why would one put multiple TSM servers on a single machine?
l Message-
> From: Lindsay Morris [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, May 09, 2001 7:22 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Multiple TSM* Servers On Same Machine
>
> Well, you're right. Server consolidation is a good thing.
>
> But I usually
ginal Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Jeff Bach
Sent: Wednesday, May 09, 2001 12:22 PM
To: [EMAIL PROTECTED]
Subject: Re: Multiple TSM* Servers On Same Machine
1. Less hardware to manage
2. SCSI tape resources can be shared
3.
ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Jeff Bach
Sent: Wednesday, May 09, 2001 12:22 PM
To: [EMAIL PROTECTED]
Subject: Re: Multiple TSM* Servers On Same Machine
1. Less hardware to manage
2. SCSI tape resources can be shared
3. DISK resources can be moved be
2001 10:22 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Multiple TSM* Servers On Same Machine
>
>
> 1. Less hardware to manage
> 2. SCSI tape resources can be shared
> 3. DISK resources can be moved between instances without
> an outage
> 4. Multiple int
I asked the same wuestion a couple of years ago.
Under older versions of TSM, you didn't want the database to get too large.
On mainframes, it was so you could use multiple virtual machines - something
maybe to do with the TCP/IP bottleneck under older MVS.
Nowadays I don't see why.
-Origin
1. Less hardware to manage
2. SCSI tape resources can be shared
3. DISK resources can be moved between instances without an outage
4. Multiple interfaces can be shared
5. One TSM server license
6. Can be implemented in a few hours
7. Works around application bott
36 matches
Mail list logo
