Richard

Thank you for the reply. 

Our only way out was to kill the TSM StorageAgent process and restart
it. Lanfree backups then continued as normal. For some of the messages
and message text, there were a number of identical hits on the IBM
support site saying that this had happened in TSM v5.2.2 (our version)
and were fixed in a v5.3 release. All of our other TSM servers are >5.4,
but trying to upgrade this one is a nightmare. The StorageAgent and main
TSM have been running since September 2006. It's a very high
availability Oracle application, and the business/IT management won't
allow us to take it down to upgrade. I've pointed out that we are down
level and unsupported, but it does'nt help.

They now want us to move the backups to a new library (TS3500), so i
guess we'll have to force the issue at some stage soon. 

Again, thanks for the help 

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: 16 February 2008 15:04
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Lan Free Backup Problem

On Feb 16, 2008, at 8:30 AM, Jeff White wrote:

> 14-02-2008 19:31:31      ANR8223W (Session: 877917, Origin:
> COUXIPR05_STA)  Unable  to connect to remote system 172.20.34.21
> due to
>                           unexpected return code 67(SESSION: 877917)
> ====> Return code 67 = "EADDRINUSE"

That errno seems to be centric to this problem.  Its classic cause in
TCP/IP communications is that the local end has attempted to create a
socket, and then bind a specific port number to it - but some other
process is already using that port number.  That port number would be
one either specified in your options file or be a product default.
See http://www.redbooks.ibm.com/abstracts/TIPS0564.html for a
convenient summary of port specifications.  See the TSM manuals for
more detail.  You can use lsof, netstat, and like commands to see in-
use ports.

I would also check your hardware for anomalies.  Where you cannot
cancel a session or process, that usually indicates an I/O hang,
where a device has stopped responding and is blocking progress.
There should be site monitoring in place to call out device problems,
so they won't be the mystery cause of dependent software failing to
function.  At a minimum, check your AIX Error Log in conjunction with
involved TSM server Activity Logs.

    Richard Sims

------------------------------------------------------------------------
--------------
Email scanned for viruses and spam by the Woolworths
anti-virus systems.

If you believe this email is spam, please forward to
suspectspam AT woolworths.co DOT uk
****************************************************************************
Woolworths plc
Registered Office: Woolworth House, 242/246 Marylebone Road, London NW1 6JL 
Registered in England, Number 104206

This e-mail is only intended for the person(s) to whom it is addressed and 
may contain confidential information.  Unless stated to the contrary, any 
opinions or comments are personal to the writer and do not represent the 
official view of the company.  If you have received this e-mail in error, 
please notify us immediately by reply e-mail and then delete this message 
from your system. Please do not copy it or use it for any purposes,  or 
disclose its contents to any other person.  Thank you for your co-operation.
****************************************************************************
------------------------------------------------------------------------------------
Email scanned for viruses and unwanted content by emailsystems

Information regarding this service can be found at www.emailsystems.com