Zlatko,
I hope you can make it work.  We had been unsuccessful.  But, the recent
client levels that have come out, we have not tried.  It would really be
nice for the thing to work correctly.  Andy has corrected my understanding
and he is going to test some more.  The issue we had was the maxsize would
kick in or rebinds of data that had gone down the LAN pathway.  The storage
agent would go nuts.  Essentially, we found that you had to rebind using the
LAN method and then turn LANFREE back on.

In the USA we place these type of animals in a zoo.

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


-----Original Message-----
From: Zlatko Krastev/ACIT [mailto:acit AT ATTGLOBAL DOT NET]
Sent: Thursday, September 19, 2002 3:08 AM
To: ADSM-L AT VM.MARIST DOT EDU
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