Zlatko,

The 5.1 client is compatible with 4.2 server and storage agent.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.eyebm DOT com (change eye to i to reply)

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
09/19/2002 00:08
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: LAN-free backup goes SAN, LAN, SAN



Paul,

This ought to be like non-Euclidian geometry - Two milleniums
mathmaticians thought there can be only one parallel line and when dropped
this limitation discovered whole new branch in the science :-)
In fact I thought enablelanfree allows client to have conversation with
more than one server - real TSM server and local STA. And management class
bindings direct which route to follow. Now I have to read the fine print
again ,-)
It works fine till now and the result is as I thought it ought to - files
bound to disk class go over LAN and files bound to SAN-tape class go
LAN-free.
I will dig deeper and on success will let you know.
Another question pops up in my head (again on the edge of non-supported :)
- What if I try to use v5.1 client and v4.2.1 storage agent? Have to read
carefully compatibility matrix - v5.1 client is supported with v4.2.1
server, storage agent is same version as the server, nothing said about
what I intend to use ...
Any ideas (Andy?)

Zlatko Krastev
IT Consultant




Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        Re: LAN-free backup goes SAN, LAN, SAN

Zlatko,
I am actually surprised you even got this to work.  When you define in
DSM.SYS as LANFREE it has to go directly to tape for everything you are
backing up with that node.  Nothing can go to a disk pool.  So, you have
to
define multiple stanzas in dsm.sys and multiple dsm.opt files.  Now that
you
have multiple nodes you see the sticky wicket.  You can not send the DIRMC
to a disk pool and the data to a tape pool.

We tried what you did and occassionally got what you have seen, but more
often than not, complete failure.

If you find out that there is a way to make it work, I would like to know
how.  I do not remember where the fine print is buried on this
restriction,
but it is a known restriction.

You have to think of LANFREE as sending the data to an alternate TSM
server
on your local machine that shares the library with the TSM Server owning
the
library, but fakes out the fact that the database is on the TSM Server
owning the library.  A node can only form a session with one TSM server at
a
time.  This is why the TDP for SAP R3 supports a parallel session
capability
that can define more than one node so that you can actually send data to
several TSM server addresses simultaneously.  Typically, they are just
multiple adapters on a single TSM server, but they could be multiple TSM
servers.

I hope that makes sense, what I just said.

Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180


-----Original Message-----
From: Zlatko Krastev/ACIT [mailto:acit AT ATTGLOBAL DOT NET]
Sent: Wednesday, September 18, 2002 12:27 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: LAN-free backup goes SAN, LAN, SAN


Hello all,

If you do not like to read long posts please skip this one - it can be
boring.

I have a very nasty problem at customer site and asking for your help are
we
the only having it. If not can we fight it together.
Environment:
Server: v4.2.1.15, Windows 2000 SP2
Client: v4.2.2.1 (was 4.2.1.25), AIX 4.3.3ML09 + patches Storage Agent:
v4.2.1.15, TCP/IP or Shared Memory
SAN: IBM 2108-F16 (Brocade) switch + IBM 3583-L18 (ADIC) LTO with 2 drives
Storage policy: Stgpools use defined volumes and no scratches. Yes, I know
it's very unusual combination (Windows TSM server + AIX nodes). Even
support
in the beginning thought it is AIX server w/ Win client.

The node in question is somewhat mixed - small (<50kB) and large (Nx100MB
or
1-4GB) files. So for performance small files are directed to go over LAN.
Large files are bound to direct-to-SAN-tape class and storage agent should
take care of them. DIRMC is pointing diskpool as it ought to.

Now the problem:
1. Client starts backup, sent several directories over LAN, on first file
reported ANS1114I and waits server to mount a volume on behalf of storage
agent (OK) 2. Variable number of files are backed up for less than 1% of
the
volume mounted (OK) 3. Client reports another ANS1114I (here is the
problem). Under the covers it seems than client requested this and next
several files to go over LAN instead of LAN-free. So mount is performed by
server for its own use (normal MgSysLAN path). 4. Another bunch of files
are
backed to second volume. 'Q SES' shows tens of MBs so files go over LAN.
5.
Third ANS1114I is reported and client resumes normal operation 6. Backup
completes with no error, everything is backed up but for enourmous time -
test with 3-4 GB went good 20 minutes instead of 5. The result of this
SAN-LAN-SAN sequence is two volumes less than 5% utilized, 5-minutes
backup
taking between 20 and 40 minutes and unwanted data spread. Contents are
VOL1: file set 1, file set 3
VOL2: file set 2
And if accidentally second drive is busy (migration most often) the
process
might go to bed in step 3 and wake up one hour later (when drive becomes
available on the end).

Partial workaround:
If DIRMC is set to point the tapes LAN-free works as it ought to and 4.3
GB
take 5 minutes including mount time. But backup of 20kB in 5 files is
taking
again 5 minutes just because DIRMC required tape mount. This moves the
problem in other area without solving it at all.

Support requested client upgrade from v4.2.1.25 to v4.2.2 with no success.
Upgrade of the storage agent (plus the server and other agents) is
postponed
because we want to ensure this problem is resolved before to introduce new
ones in v4.2.2.

As always any hints, advices or similar experience are thankfully welcome.


Zlatko Krastev
IT Consultant