TSM for Linux on non-IBM hardware

[Chris Young]

Is anyone using TSM on Linux on non-IBM hardware? I am trying to run this on
a Dell machine using SuSE 8 and have been unsuccessful in finding a way to
stabilize the system. If so, please would you provide me with details about
what version of Linux you are using and on what hardware platform?

Thanks.

- C. Young

Re: Poor TSM Performances

[Chris Young]

Ruddy,

In a test that I did on a client site, average file size can account for
huge performance differentials when using LAN-Free. In one case, I ran a
test that compared transfer times of a 276480 byte file to a 2146435072 byte
file, the resultant transfer rate was .032 MB/sec. for the small file and
32.978 MB/sec. for the large file. The apparent reason for this difference
is that while file size differs greatly, each backup only required 1 DB
transaction. In this case, the DB transaction was the piece that was taking
the extra time and "degrading" the transfer rate of the small file.

Basically, it all boils down to how much data you can move within the TXN
limit. The more, the better the performance. If there are certain parts of
your file system where larger files are stored, you might want to try and
run a LAN-Free backup against them just to get a comparative baseline. If
you find performance improves, it might make sense to transfer the small
files over the LAN and the larger files over the SAN by establishing a new
management class that points to disk for small files and then modifying your
incl/excl file.

Hope this helps...

- Christopher Young

-Original Message-
From: Ruddy STOUDER [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2003 2:31 PM
To: [EMAIL PROTECTED]
Subject: Re: Poor TSM Performances


Thanks ! But ... I have done all of them ... The reason why I am looking
here for info.

As I wrote, nothing is running on the 2 involved servers (so, no virus
protection software).
As I wrote, network cards are 10% used => no network settings involved.

Ruddy Stouder
Senior Technical Consultant
TSM Certified Consultant
I.R.I.S.
Rue du Bosquet 10 - Parc Scientifique de
Louvain-La-Neuve
B-1348 Mont-Saint-Guibert
[EMAIL PROTECTED]

Tel: +32 (0)10 48 75 09  -  Fax: +32 (0)10 48 75 40




-Original Message-
From: Richard Sims [mailto:[EMAIL PROTECTED]
Sent: jeudi 6 mars 2003 15:25
To: [EMAIL PROTECTED]
Subject: Re: Poor TSM Performances


>I am quite disappointed by the TSM software performance. ...

Have you looked at the suggestions under "Backup performance" in
http://people.bu.edu/rbs/ADSM.QuickFacts ? Two classic causes of performance
problems are misconfigured networking and virus protection software.  File
system topology and network loading are also substantial factors.  How long
does it take a native W2000 file system scanning utility to traverse the
file system?  (File systems with thousands of files in one directory are A
Bad Idea.)  How long does it take a client running on the TSM server to
perform a backup without networking?  Have you pursued the items in the
Performance Tuning Guide? You have to break down the factors and examine
each. Blame TSM only if you ultimately find the sluggisness to be caused by
TSM.  But you have to do the basic systems analysis to isolate performance
factors in your mix.

   Richard Sims, BU

Re: Tivoli Storage Resource Reporting

[Chris Young]

While I couldn't comment in any great deal on this, I have seen the Tivoli
Storage Resource Manager product (formerly the TrelliSoft product) in
action. It appears to provide detailed reports on data that is stored on
both SAN and LAN based disk volumes (assuming of course that you have a
server that either has the volume mounted locally or there is a server
locally (and direct) attached to the volume on the other end of the
network). It is also fairly easy to install and get started with in terms of
gathering information. Understanding all of the reports that are available
is a different story.

It is probably worth checking out though. I have heard rumors that this will
become even more integrated with the TSM product in the future.

- Chris Young

-Original Message-
From: Jin Bae Chi [mailto:[EMAIL PROTECTED]
Sent: Friday, February 28, 2003 4:33 PM
To: [EMAIL PROTECTED]
Subject: Tivoli Storage Resource Reporting


Hi, all

I'm runnig a TSM 4.2 for LAN servers and another TSM 4.2 for SAN
servers. I heard Tivoli has a good product about disk storage reporting
from LAN and SAN. Anyone using any good reporting and managing software
from Tivoli? My main interest is all disk utilization from LAN and SAN
attached servers. Any comment will be appreciated. Thanks.







Jin Bae Chi (Gus)
System Admin/Tivoli
Data Center, CSCC
614-287-5270
614-287-5488 Fax
[EMAIL PROTECTED]

Re: ACSLS or Native TSM manager

[Chris Young]

StorageTek 9310 tape libraries are only controllable via ACSLS or
LibStation. This is due to the fact that it only supports a TCP/IP (IEEE
802.3, 10baseT, half-duplex), RS423 or 3270 robotic control interface.

- Chris Young

-Original Message-
From: Hart, Charles [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 8:09 PM
To: [EMAIL PROTECTED]
Subject: Re: ACSLS or Native TSM manager


Would you still need ACSLS for a 9310 PowderHorn with Fiber attached 9940B
Tape Drives?

Regards,

Charles

-Original Message-
From: Prather, Wanda [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 1:55 PM
To: [EMAIL PROTECTED]
Subject: Re: ACSLS or Native TSM manager


We run AIX 4.3.3, have gone from TSM 3.1 to 3.7 to 4.1 to 4.2.1.5. Etc.

On ADSM 3.1, you needed ACSLS to support some types of devices that ADSM
didn't support native.

And at one time you could put two types of drives in the library if you used
ACSLS, and TSM doesn't support that with native SCSI (and I'm not sure you
can still do this at TSM 5.x, even with ACSLS).

Once we evolved past those 2 requirements, we dropped ACSLS and went to
TSM's native SCSI support.
It's a much simpler configuration and works just dandy if TSM is the only
application using the library.


-Original Message-
From: Dameon White [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 2:29 PM
To: [EMAIL PROTECTED]
Subject: ACSLS or Native TSM manager


We just bought a used STK L700 with 4 DLT7000 drives.  We
have TSM 5.1.5.2 on AIX and I am confused as to why/if I
would need to use ACSLS to manage the library?  Does ACSLS
provide any features not available with TSM's native
library manager?  We will want to share this L700 with
another TSM server and I can't see why native scsci
library won't be a good choice?

Any advice?

Dameon

Re: ACSLS or Native TSM manager

[Chris Young]

The ability to support multiple drive types in StorageTek ACSLS or
LibStation libraries is enabled through the use of the external library
manager interface and an external library manager. By presenting multiple
virtual libraries through this interface, you can enable TSM to use multiple
drive types. This is valid for all TSM levels.

- Chris Young

-Original Message-
From: Prather, Wanda [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 7:55 PM
To: [EMAIL PROTECTED]
Subject: Re: ACSLS or Native TSM manager


We run AIX 4.3.3, have gone from TSM 3.1 to 3.7 to 4.1 to 4.2.1.5. Etc.

On ADSM 3.1, you needed ACSLS to support some types of devices that ADSM
didn't support native.

And at one time you could put two types of drives in the library if you used
ACSLS, and TSM doesn't support that with native SCSI (and I'm not sure you
can still do this at TSM 5.x, even with ACSLS).

Once we evolved past those 2 requirements, we dropped ACSLS and went to
TSM's native SCSI support.
It's a much simpler configuration and works just dandy if TSM is the only
application using the library.


-Original Message-
From: Dameon White [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 2:29 PM
To: [EMAIL PROTECTED]
Subject: ACSLS or Native TSM manager


We just bought a used STK L700 with 4 DLT7000 drives.  We
have TSM 5.1.5.2 on AIX and I am confused as to why/if I
would need to use ACSLS to manage the library?  Does ACSLS
provide any features not available with TSM's native
library manager?  We will want to share this L700 with
another TSM server and I can't see why native scsci
library won't be a good choice?

Any advice?

Dameon

Re: Shared Storagetek L180 library

[Chris Young]

To the best of my knowledge, the STK L180 does not support ACSLS. It is pure
SCSI based library control. However, what you probably could would be to use
Tivoli's native library sharing functionality, introduce a SCSI multiplexer
(since the TSM server would need visibility to each of the drives in order
to allow native library sharing to work...unlike an ACSLS environment) and
define two drives to each server, limit the mount points on the "master TSM
server" to two and then make sure that the first two drive in the drive list
are the drives that are not defined to the other TSM servers. Possibly a
little more complex than you might like but it should work. The alternative
would be to go to a larger library that was ACSLS controlled and then the
process is a little more streamlined.

Christopher Young

-Original Message-
From: Bill Mansfield [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 31, 2003 9:05 PM
To: [EMAIL PROTECTED]
Subject: Shared Storagetek L180 library


I would like to share a STK L180 library with 6 SCSI drives among
three independent TSM servers.  No drive sharing required, just
want two drives per TSM server.  It appears that the L180 has a
single control path.  Can I get this done with ACSLS?  Is anyone
doing something like this? Any advice is welcome.  Thanks.


William Mansfield
[EMAIL PROTECTED]

Integrating Legacy Systems with TSM

[Chris Young]

I have several legacy systems (VMS and VME) that I am hoping to integrate
into my TSM environment. However, TSM does not provide clients for these
platforms. Has anyone else experienced this difficulty either with these
platforms or other platforms like this? If so, how did you resolve this
problem? Does anyone have any suggestions as to how this integration might
be accomplished?

Christopher Young
TSM Certified Engineer


Privileged or confidential information may be contained in this message.  If
you are not the addressee of this message please notify the sender by return
email and thereafter delete the message.  You may not use, copy, disclose or
rely on the information contained in this message.  Internet e-mail may be
susceptible to data corruption, interception and unauthorized amendment for
which Gresham does not accept liability.  While we have taken reasonable
precautions to ensure that this e-mail and any attachments have been swept
for viruses, Gresham does not accept liability for any damage sustained as a
result of viruses.  Statements in this message that do not relate to the
business of Gresham are neither given nor endorsed by the company or its
directors.  A list of Gresham's directors is available on our web site:

Re: ACSLS connection

[Chris Young]

Don,

To respond to your inquiry, here are some benefits that can be realized in
the environment that you have outlined below.

1) Although the SN6000 is present, it creates a problem when more logical
than physical drives are configured. This is a long standing problem and it
has been resolved by coupling EDT-DistribuTAPE with the SN6000 in a large
number of installs. For this reason, when you see an environment involving
an SN6000 and TSM, you should automatically include EDT-DistribuTAPE.
2) EDT-DistribuTAPE, in a multiple TSM server environment allows both TSM
servers to share the same set of drives as well as a single common pool of
media. This includes virtual resources. The SN6000 is not capable of
providing a single common pool of media to each TSM server.
3) EDT-DistribuTAPE eliminates the need to check-in a specific range of
volumes to each TSM server...this can be a large administrative time savings
feature.
4) EDT-DistribuTAPE automates tape labeling operations. When volumes are
mounted, the header is checked to verify that it contains a valid label. If
it does not, a valid label is written to the tape. This allows
non-initialized volumes to be purchased (an average savings of
$1-2/cartridge) and saves additional administrative time.
5) EDT-DistribuTAPE allows dynamic reconfiguration of the drives that are
available to each TSM server (this can be handy during drive maintenance
periods or the addition of new drives to the environment).
6) EDT-DistribuTAPE, due to its architecture, insulates each TSM server from
an outage that may occur on another server (were drives to be allocated to
each TSM server (dedicated), the outage of one server would cause those
drives to be unutilized. This is not the case with EDT-DistribuTAPE because
every server (if configured in such a fashion) can access every drive).
7) EDT-DistribuTAPE provides mixed media support allowing numerous device
types to be present in one library (a method of centralizing drive and media
management).
8) EDT-DistribuTAPE provides a more robust ACSLS interface than natively
available in TSM (this is a result of continuous efforts that Gresham
undertakes with STK to address issues in the interface and find solutions to
those problems).

There are further features and benefits that are present in the
EDT-DistribuTAPE product that make it worth the investment. Hopefully, the
above features alone convince you of this fact. Regardless, please let me
know what additional information I can provide you to facilitate your
efforts to "sell" the EDT-DistribuTAPE product in the environment you have
mentioned and other environments you are involved with.

Sincerely,

Christopher S. Young
Senior System Engineer
Gresham Enterprise Storage
www.greshamstorage.com
Office: 303.413.1799 x 205
Mobile: 303.717.2745


-Original Message-
From: Don France (TSMnews) [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 13, 2002 2:21 PM
To: ADSM: Dist Stor Manager
Cc: [EMAIL PROTECTED]
Subject: Re: Re: ACSLS connection


Chris,

I have looked at the Gresham EDT-DT info, am trying to understand why a
customer
might want to use it in a non-LAN-free environment.

I have a client who's installing a StorageTek SN-6000, which virtualizes the
tape drives
in a Powderhorn silo;  they will use two TSM servers, initially -- so, there
does not seem
to be a compelling reason to use EDT-DT.  I have reviewed the online
material and the
latest install & user's guide -- except for SAN mgmt/monitor utilities, I am
still trying to
find ways to "sell" the client on installing it before deploying a broad,
LAN-free solution.

Can you please highlight some benefits of using EDT-DT in a context where
it's not
absolutely required?!?  (In my client's shop, the TSM servers are on AIX,
the ACSLS
is on its own Solaris box.)

Thanx,
Don

 Don France
Technical Architect - Tivoli Certified Consultant
Professional Association of Contract Employees (P.A.C.E.)
San Jose, CA
(408) 257-3037
[EMAIL PROTECTED]

----- Original Message -
From: "Chris Young" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, April 02, 2002 6:45 AM
Subject: Re: ACSLS connection


> Craig,
>
> If you are using a single TSM server and you do not plan to use LAN-Free
> clients (which I believe you are from the message below), then you can use
> TSM's native ACSLS communication drivers. However, if you are using
LAN-Free
> clients in addition to your TSM server, where each client will access the
> same library as the TSM server, you need to obtain Gresham's
> EDT-DistribuTAPE product to enable this functionality. There are other
> reasons that you might want Gresham's EDT-DistribuTAPE in environments
that
> do not involve LAN-Free clients and employ only a single TSM server but it
> isn't required as it is when using LAN-Free clients. You can obtain more
> information on EDT-DistribuTAP

Re: ACSLS connection

[Chris Young]

Craig,

If you are using a single TSM server and you do not plan to use LAN-Free
clients (which I believe you are from the message below), then you can use
TSM's native ACSLS communication drivers. However, if you are using LAN-Free
clients in addition to your TSM server, where each client will access the
same library as the TSM server, you need to obtain Gresham's
EDT-DistribuTAPE product to enable this functionality. There are other
reasons that you might want Gresham's EDT-DistribuTAPE in environments that
do not involve LAN-Free clients and employ only a single TSM server but it
isn't required as it is when using LAN-Free clients. You can obtain more
information on EDT-DistribuTAPE from
www.gresham-software.com/storage/products/distributape.htm.

Chris Young

-Original Message-
From: Murphy, Craig [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 01, 2002 9:05 PM
To: [EMAIL PROTECTED]
Subject: ACSLS connection


Hello,

We are looking to use TSM to backup over fibre attached client to a STK
Powderhorn controlled by ACSLS.
The TSM server is on a solaris server and the ACSLS is a separate solaris
server. What do I need on my TSM server to be able to communicate to the
ACSLS server? I see there is LibAttach software for Windows. Whats the equiv
for Solaris?

Regards
Craig Murphy

Re: TSM client for AIX5 on 32 bits system

[Chris Young]

Michel,

It has been my experience that it is possible to use the TSM 4.2.1 client
for AIX 4.3.3 on an AIX 5.1 machine so long as you have the necessary
patches applied.  This should also allow you to overcome the 64-bit issue as
well.

Chris Young

-Original Message-
From: Meilink, Michel [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 20, 2002 2:08 AM
To: [EMAIL PROTECTED]
Subject: TSM client for AIX5 on 32 bits system


Hi,

I'm looking for a TSM client for AIX 5.1. I found one (4.2.1) via the Tivoli
website, but it's available for 64bit platforms only. I have AIX 5.1 running
on a 32.bit system, and thus it won't install.

Will Tivoli produce a 32bit version for AIX 5.1 also, or do they assume that
AIX 5.1 will only be installed on 64bit machines? Or should I use the AIX
4.3.3 (32bit) version instead on my AIX 5.1 machine?

Greetings,
Michel Meilink

Re: TSM support of STK library in SAN environment

[Chris Young]

John,

To respond to your questions, please see responses below:

Christopher Young

-Original Message-
From: John Schneider [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 14, 2002 11:15 AM
To: [EMAIL PROTECTED]
Subject: TSM support of STK library in SAN environment


Greetings,
I have looked through the listserv archives for an answer to this
question, but so far have not found an answer that quite addresses my
question.

I am about to install TSM 4.2.1 on an IBM pSeries box with FC attach
through Brocade switches to FC 9840 tape drives and a STK 9310
Powderhorn library.  Soon the customer is going to want to do LAN-free
backups using TSM Managed System for SAN Agent directly across this SAN
to the 9840 tape drives.

My questions:

1) Can TSM talk directly to this STK Library?  Do we need ACSLS?  I have
used TSM with other STK libraries, and just controlled them directly.
This library will not be attached to any other server besides TSM, so is
ACSLS required?  Does it make anything easier?

A: TSM cannot communicated directly to a STK 9310 library.  This is because
a 9310 library necessitates an ACSLS control connection.

2) IF I can directly talk to the library, how is this done?  TCP/IP,
through the SCSI interface, or what?

The library will communicate to the ACSLS server via a RS-232 or RS-432
serial connection.  The TSM server will communicate with ACSLS via TCP/IP.

3) The LAN-free page at the TSM web site hints that to do LAN free
backups to a STK ACSLS library, I would need the EDT software.  But is
this necessay IF I can control the STK library directly from TSM without
ACSLS?

This is tricky...according to TSM documentation, LAN-Free can be achieved,
in absence of EDT-DistribuTAPE, when you are using a SCSI attached STK
library.  If this is not the case, TSM has you employ the EDT-DistribuTAPE
product to establish connectivity.

Please reply directly, as well as to the list.

Thanks much in advance,

John Schneider
LSi

Re: Version 3.1 client on HPUX 10.2

[Chris Young]

I am aware of a site where the individual is running v3.1 clients on HP
10.20.  However, they are using Autosys to initiate the backup operations.
They have not had any problems with this configuration as far as I am aware.

Chris Young
Gresham

-Original Message-
From:   [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 16, 2001 7:08 AM
To: [EMAIL PROTECTED]
Subject: Version 3.1 client on HPUX 10.2


Does anyone out there run TSM v 3.1 on an HPUX 10.2 client?
We have to HPUX 10.2 boxes here that for some reason we can't upgrade to
later versions. (the only version that will run is v 3.1)
We can successfully run scheduled backups with  one of them.  But the other
will not get contacted by the server when the schedule is supposed to run.
I tried using polling and prompted on both servers but still no success.

Can anyone shed any light

TSM Server Performance on SUN Servers

[Chris Young]

I am attempting to determine the upper threshold for the aggregate data
transfer rate on clients backing up to a TSM server running on a SUN Solaris
TSM server.  It has been my experience thus far that this ranges somewhere
between 800 Kb/sec (on the low end) up to 2400 Kb/sec (on the high end).  I
am hoping that there are other sites that are experiencing better
performance.  Any statistical data along these lines would be greatly
appreciated.

Christopher S. Young
Senior System Engineer
Gresham Enterprise Storage
www.greshamstorage.com
Office: 303.413.1799 x 205
Mobile: 303.717.2745
 <>



Chris Young.vcf
Description: Binary data

Re: LAN free backup for NT

[Chris Young]

A requirement for LAN-Free is that you are running TSM server version 4.2.1
or later.

Christopher S. Young
Senior System Engineer
Gresham Enterprise Storage
www.greshamstorage.com
Office: 303.413.1799 x 205
Mobile: 303.717.2745


-Original Message-
From: Leijnse, Finn F SITI-ISES-31 [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 02, 2001 7:31 AM
To: [EMAIL PROTECTED]
Subject: LAN free backup for NT


Hello,

I want to start testing with LAN free for NT but I have to choose between
several TSM backup servers.
Can someone tell me if a backup server with TSM V4.1 level 2.0 can handle
the LAN free backup?

> met vriendelijke groeten, regards et salutations,
>
> Finn Leijnse
> ISES/31 - Central Data Storage Management
> Shell Services International bv.
>

Re: ACSLS, library sharing and SAN

[Chris Young]

Dmitri,

To answer your questions:

Q: Why is Gresham's EDT product required as part of the Storage
Agent/LAN-Free solution?
A: Gresham's EDT product was selected to handle tape resource brokering
between TSM and ACSLS/LibStation.  In particular, EDT-DistribuTAPE enables
TSM to use a single scratch pool between multiple TSM servers.
EDT-DistribuTAPE ensures that when multiple TSM servers use a single scratch
pool, tapes that are in use by one TSM server are not allocated to other TSM
servers ensuring that data integrity is maintained and data is protected on
each volume.

Q: What are the issues involved with sharing ACSLS between multiple TSM
servers?
A: If you do not use EDT-DistribuTAPE in a solution where you have multiple
TSM servers accessing a single ACSLS server, the largest problem that you
will face is the fact that TSM is designed to employ ACSLS scratch pool 0.
Since multiple TSM servers would be accessing the same tape pool, you cannot
ensure that a volume that is in use by one TSM server will not be assigned
and overwritten by another TSM server.

Q: What is EDT's exact role in LAN-Free data transfer?
A: EDT-DistribuTAPE is responsible for satisfying mount requests, ensuring
that the proper tape volume has been mounted, that the volume is properly
prepared for use and that the data path has been properly established.  Once
this process has been completed, EDT-DistribuTAPE turns control over to TSM
along with all appropriate information allowing TSM to perform the backup.
EDT-DistribuTAPE does not actively participate on the data path.

Q: Has anyone setup an ACSLS library for SAN using EDT?
A: Gresham has numerous clients who use EDT-DistribuTAPE with
ACSLS/LibStation and TSM in a SAN environment.  Lately, Gresham has deployed
LAN-Free solutions at several locations all with great success.

For additional information, please refer to www.gresham-software.com/tivoli.

Christopher S. Young
Senior System Engineer
Gresham Enterprise Storage
www.greshamstorage.com
Office: 303.413.1799 x 205
Mobile: 303.717.2745


-Original Message-
From: Dmitri Pasyutin [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 29, 2001 1:58 PM
To: [EMAIL PROTECTED]
Subject: ACSLS, library sharing and SAN


Hi fellow TSMers,

I use an ACSLS (STK 9360) library with my TSM server (4.2.1 on AIX). It had
been great news for me to hear that as of v4.2.0 TSM supports ACSLS library
sharing, and now SAN data transfer with ACSLS as of v4.2.1. Still, after
thinking about it many times, I still can't figure out why this came so
late. Sharing of SCSI STK libraries has been supported as of v3.7, but not
ACSLS. However, with its (100%-software) ACSSI interface, TSM controls
an ACSLS robot just as it would a SCSI one. There seems to be no technical
reason why an ACSLS robot could not be shared between multiple servers, i.e.
I can't see how it can be related to hardware or the physical device driver.
And even now with SAN support, a third-party product like Gresham's EDT is
required as the interface between the library and the storage agent. Why?
Can someone enlighten me on the ACSLS sharing issue? What is EDT's exact
role in lan-free data transfer? Also, if someone has set up an ACSLS library
for SAN using EDT, I would very much like to hear about your experiences.
Thanks in advance.

Yours truly,

--
Dmitri PASYUTIN
TSM administrator
Paris, France

Re: Strange behaviour????

[Chris Young]

Jerry,

I have seen this problem in the past but it isn't really a problem.  I
believe Tivoli would refer to it as a security feature.  What happens when
backups are performed is that directories, not files, are bound to the
management class with the longest retention period.  If you look at
individual files, they should still be bound to the standard management
class.  You can override the directories being bound to the LOG_POLICY-MC by
including an option in the client's configuration files that specifies the
STANDARD management class as the location to bind directories to.

Christopher S. Young
Senior System Engineer
Gresham Enterprise Storage
www.greshamstorage.com
Office: 303.413.1799 x 205
Mobile: 303.717.2745


-Original Message-
From: Jerry Caupain [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 26, 2001 3:12 AM
To: [EMAIL PROTECTED]
Subject: Strange behaviour


Hello everyone,

I have noticed something strange. In my policy domain I have two management
classes. One is called STANDARD and the other is called LOG_POLICY-MC. I
want to use the last one only for my log server so I included the following
line in my include/exclude file:
INclude /logs/.../* log_policy-mc

Managementclass STANDARD is the default managementclass.

Why is it that all my other systems also use the LOG_POLICY-MC
managementclass?  It seems that the directories on my other systems are all
bound to this managementclass. This can't be normalcan it???

Jerry Caupain

Re: SAN Environment

[Chris Young]

Joerg,

What type of library and tape drives are you using.  In the testing that I
have done, to the best of my knowledge, I have not encountered this problem.

Chris

-Original Message-
From: Jörg Nouvertné [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 24, 2001 7:35 AM
To: [EMAIL PROTECTED]
Subject: Re: SAN Environment


That's correct as long as you install the Storage Agent on the client, which
"borrows" a drive from the TSM server and send only the management info
through the LAN. Therefore you needs the (expensive) STA license and to my
knowledge the library sharing option.

We used it once but had to disable it, since in our environment (W2K
Client/STA and AIX TSM 4.2.0.1) we cannot read most of the data being backed
up, because the real blockheader on the tape does not match the expecting
one. But it's fast, together with the TDP for Domino we achieved ~18MB/sec
throughput for each tape drive (3 in parallel). I hope, IBM/Tivoli can
resolve this issue soon.

Joerg Nouvertne
http://home.wtal.de/the_swordsman

> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
> Chris Young
> Sent: Dienstag, 23. Oktober 2001 21:37
> To: [EMAIL PROTECTED]
> Subject: Re: SAN Environment
>
>
> One other thing that is interesting to note...If you are using
> LAN-Free, you
> can create a management class that points to a disk pool and a management
> class that points to a tape pool and then make entries in the
> incl/excl list
> to include these management classes.  By doing this, you can direct some
> data to go over the SAN directly to tape (LAN-Free) and have
> other data pass
> over the network to disk.  While I have only experimented with
> this at this
> time, it seems to have potential performance benefits if you network
> bandwidth available.
>
> Christopher S. Young
> Senior System Engineer
> Gresham Enterprise Storage
> www.greshamstorage.com
> Office: 303.413.1799 x 205
> Mobile: 303.717.2745
>
>
> -Original Message-
> From: Lambelet,Rene,VEVEY,GL-IS/CIS [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 23, 2001 12:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: SAN Environment
>
>
> You can backup LAN-free to disc if you have SANErgy installed on
> a metadata
> server.
> If not, you can only backup LAN-free to tapes.
>
> Regards,
>
> >   René Lambelet
> >   Nestec S.A. / Informatique du Centre
> >   55, av. Nestlé  CH-1800 Vevey (Switzerland)
> >   *+41'21'924'35'43  7+41'21'924'28'88  * K4-117
> >   email [EMAIL PROTECTED]
> >   Visit our site: http://www.nestle.com
> >
> >   This message is intended only for the use of the addressee
> > and
> > may contain information that is privileged and confidential.
> >
> >
> > -Original Message-
> > From: Mauro Jr, Frank [SMTP:[EMAIL PROTECTED]]
> > Sent: mardi, 23. octobre 2001 18:39
> > To:   [EMAIL PROTECTED]
> > Subject:  SAN Environment
> >
> > We currently point our backups to disk.
> >
> > If we go to a SAN environment can we still use disk or will we
> have to go
> > to
> > tape?
> >
> > Frank Mauro
> > Backup and Recovery Services
> > [EMAIL PROTECTED]
> > Telephone Number: 603.245.3207
> > Beeper Number: 888.797.0806
>
>

Re: SAN Environment

[Chris Young]

One other thing that is interesting to note...If you are using LAN-Free, you
can create a management class that points to a disk pool and a management
class that points to a tape pool and then make entries in the incl/excl list
to include these management classes.  By doing this, you can direct some
data to go over the SAN directly to tape (LAN-Free) and have other data pass
over the network to disk.  While I have only experimented with this at this
time, it seems to have potential performance benefits if you network
bandwidth available.

Christopher S. Young
Senior System Engineer
Gresham Enterprise Storage
www.greshamstorage.com
Office: 303.413.1799 x 205
Mobile: 303.717.2745


-Original Message-
From: Lambelet,Rene,VEVEY,GL-IS/CIS [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 23, 2001 12:57 PM
To: [EMAIL PROTECTED]
Subject: Re: SAN Environment


You can backup LAN-free to disc if you have SANErgy installed on a metadata
server. 
If not, you can only backup LAN-free to tapes.

Regards,

>   René Lambelet
>   Nestec S.A. / Informatique du Centre 
>   55, av. Nestlé  CH-1800 Vevey (Switzerland) 
>   *+41'21'924'35'43  7+41'21'924'28'88  * K4-117
>   email [EMAIL PROTECTED]
>   Visit our site: http://www.nestle.com
> 
>   This message is intended only for the use of the addressee
> and 
> may contain information that is privileged and confidential.
> 
> 
> -Original Message-
> From: Mauro Jr, Frank [SMTP:[EMAIL PROTECTED]]
> Sent: mardi, 23. octobre 2001 18:39
> To:   [EMAIL PROTECTED]
> Subject:  SAN Environment
> 
> We currently point our backups to disk.
> 
> If we go to a SAN environment can we still use disk or will we have to go
> to
> tape?
> 
> Frank Mauro
> Backup and Recovery Services
> [EMAIL PROTECTED]
> Telephone Number: 603.245.3207
> Beeper Number: 888.797.0806

Re: Mixed drives in STK library

[Chris Young]

If you are employing StorageTek's ACSLS or LibStation, you can add
EDT-DistribuTAPE to the mix to support both tape drive types in one library.
The interface with TSM is via the external library manager (ELM) component.
In essence, you would create two library definitions in TSM, one for DLT and
one for 9840.  These definitions would be reflected in the configuration of
the EDT-DistribuTAPE product.  When a mount was requested, the proper media
based on the library definition being used by TSM would be mounted in the
appropriate drive and operations would proceed as normal.  This is an
excellent way to get the most out of your tape resources.  Furthermore, as
Zlatko stated below, this methodology will also allow you to migrate data
from one device type to another should you desire to do so.

Christopher S. Young
Senior System Engineer
Gresham Enterprise Storage
www.greshamstorage.com
Office: 303.413.1799 x 205
Mobile: 303.717.2745

-Original Message-
From: Zlatko Krastev/ACIT [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 19, 2001 9:38 AM
To: [EMAIL PROTECTED]
Subject: Re: Mixed drives in STK library


You still can define a SCSI library over 9840 drives and manual library
over DLT drives. You then will be able to perform current backups on new
drives and slowly to migrate data from old cartridges. The drawback is that
you (or the operators) will be the tape robot ;-)

Zlatko Krastev
IT Consultant





ORNESS <[EMAIL PROTECTED]> on 17.10.2001 01:57:49
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:

Subject:Re: Mixed drives in STK library

Hi

My STK 9740 Scsi libraries have both DLT7000 and T9840B drives without
ACSLS

9840B drives are FC native
DLT7 drives and LB0 are driven by a SCSI cable...

Rv


- Original Message -
From: "Prather, Wanda" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 12, 2001 3:30 PM
Subject: Re: Mixed drives in STK library


> A SCSI library can have only 1 type of drive; an ACSLS library can have 2
> (maybe more, I don't know).
>
> We run TSM for AIX, ACSLS 5.3, STK9710 robots.
> At various times we have run 3490 & DLT drives in the same robot, then
DLT
> and 9840 drives in the same robot.  Certainly makes media conversion
> easier!!
>
> TSM doesn't really "support" it, but what you do is install ACSLS, which
> gives you it's own robot driver on the robot address.  Then you just
define
> two TSM libraries on the same physical robot address.  Then you checkin
one
> type of tape to the first "library", and the other type of tape to the
other
> "library".  It should work unless there is something strange about the
LTO
> support that prevents it.
>
> Check with STK, see if they can find other customers doing it...
>
>
>
>
>
> -Original Message-
> From: Bill Mansfield [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 12, 2001 9:07 AM
> To: [EMAIL PROTECTED]
> Subject: Mixed drives in STK library
>
>
> Can TSM handle mixed drives (LTO and DLT) in an STK L180 library?  It
> appears that a SCSI library can only have one type of drive.  Can this be
> done with ACSLS?  Or some other approach?
> _
> William Mansfield
> Senior Consultant
> Solution Technology, Inc
>

Re: storage agent?

[Chris Young]

When/If TSM implements 3rd party copy, they will be capable of Serverless
backup because the metadata will be routed via the SAN to the server opposed
to being transferred over the LAN.  LAN-Free, on the other hand, employs the
StorageAgent, which sends the metadata over the LAN while physical data is
sent over the SAN to the designated tape/target device.

Christopher S. Young
Senior System Engineer
Gresham Enterprise Storage
www.greshamstorage.com
Office: 303.413.1799 x 205
Mobile: 303.717.2745


-Original Message-
From: Suad Musovich [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 17, 2001 10:10 PM
To: [EMAIL PROTECTED]
Subject: Re: storage agent?


That will imply 3rd party SCSI copy functionality, which I haven't
seen any indication they have incorporated to TSM.

The physical data will still have to go through the TSM server, within the
SAN environment, before it gets put in a storage pool.

Suad
--
On Wed, Oct 17, 2001 at 10:44:36PM -0400, Seay, Paul wrote:
> Yes
>
> -Original Message-
> From: Bern Ruelas [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 17, 2001 6:32 PM
> To: [EMAIL PROTECTED]
> Subject: Re: storage agent?
>
>
> Thanks Alex,
>
> Now this is LAN-less backups, right? Just metadata going to the server,
> all backups going direct from disk to tape over the SAN network.right?
>
> -Bern
>
> At 10:30 AM 10/17/2001 -0700, you wrote:
> >Bern, Si se puede, and it's available right now
> >
> >Regards...Alex Osuna
> >IBM Principal Systems Engineer
> >Tivoli Certified Consultant
> >408-256-9952
> >Fax 408-904-5326
> >Pager 408-390-0813
> >"The price of Freedom is eternal vigilance"--Thomas Jefferson"
> >
> >
> >
> > Bern Ruelas
> >  > COM> cc:
> > Sent by: Subject: Re: storage agent?
> > "ADSM: Dist
> > Stor Manager"
> > <[EMAIL PROTECTED]
> > IST.EDU>
> >
> >
> > 10/17/01 09:24
> > AM
> > Please respond
> > to "ADSM: Dist
> > Stor Manager"
> >
> >
> >
> >
> >
> >Joshua,
> >
> >Could this be used with IBM's San Data Gateways to stream data
> >directly to the tape drives? I thot that was due out 1Qtr of next year.
> >
> >-Bern
> >Sr. Systems Engineer
> >Cadence Design Systems
> >Off: (408) 428-5246
> >[EMAIL PROTECTED]
> >
> >At 04:52 PM 10/16/2001 -0800, you wrote:
> > >The Storage Agent is a stripped down version of the TSM server that
> > >allows LAN-free and I think eventually serverless backup of data.
> > >
> > >
> > >--
> > >Joshua S. Bassi
> > >Independent IT Consultant
> > >IBM Certified - AIX/HACMP, SAN, Shark
> > >Tivoli Certified Consultant- ADSM/TSM
> > >Cell (408)&(831) 332-4006
> > >[EMAIL PROTECTED]
> > >
> > >-Original Message-
> > >From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf
Of
> > >Gerald Wichmann
> > >Sent: Tuesday, October 16, 2001 3:07 PM
> > >To: [EMAIL PROTECTED]
> > >Subject: storage agent?
> > >
> > >Whats the storage agent download for in the TSM 4.2.1 upgrade? Must be
> > >something new to TSM 4.2 that I'm just not remembering offhand.
> > >
> > >Gerald Wichmann
> > >System Engineer
> > >StorageLink
> > >408-844-8893 (v)
> > >408-844-9801 (f)