Hi Richard,

First of all, thanks for your response !
Now concerning the tests your asked me to perform :
1) ls -aldx did not show anything abnormal -> only regular files, no
links
2) selective backup : was successful !

To test further, I even tried to create a new file under that directory
and to run an incremental backup : here again, no problem ...
It looks like that problem can't be reproduced, or that it appears only
during scheduled backups ...
I'm going to wait until tomorrow (or better said Monday, as the W.E. is
near), to see if this happens again, and react in consequence of the
results ...

Cheers.

Arnaud 

************************************************************************
******
Panalpina Management Ltd., Basle, Switzerland, CIT Department
Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone:  +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: arnaud.brion AT panalpina DOT com
************************************************************************
******

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Friday, 29 October, 2004 14:02
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: ANE4018E : file name too long on AIX

On Oct 29, 2004, at 6:32 AM, PAC Brion Arnaud wrote:
> I got some bad looking messages on my TSM server (AIX 5.2.0.0  with 
> TSM
> 5.2.2.1) yesterday, like :
>
> 10/27/04 19:55:52     ANE4018E (Session: 380998, Node: XXXXXXXXX )
> Error processing '/fswas/was51/AppServer/installedApps/pacrs800Networ
> k/AirWarder_1.6.4.16_train.ear/AirWarderScheduleEJB.jar':
> file name too long(SESSION: 380998)
>
> The client is installed on a AIX 5.2.0.0 and has version 5.2.0.0.
> I can't understand why I'm getting those errors, as AFAIK, TSM is 
> supposed to handle long file names so far they're supported by the OS,

> which is the case here !
> Something else to note : this  AirWarderScheduleEJB.jar is not a file,

> but a directory, so it looks like the TSM client is not searching 
> further in the directory tree, which is only one directory deeper, for

> finding files to backup.
> Someone having an idea on this ?

Arnaud - In that we haven't heard of this message for a long time, the
          problem may be with the file or file system itself.
As the (Unix) client manual says: "As long as the file system allows
creation of the file, the Tivoli Storage Manager client will back up or
archive the file."

I would do 'ls -aldx' on that file system object.  When dealing with
file names, what you see in a simple ls is not necessarily reality, in
that there may be binary crud in there, which the 'x' will reveal.

Your observation that the object is not a file is interesting.  A .jar
suffix is supposed to denote a Java ARchive *file*, not a directory.  So
something seems wrong there.

I would further examine the ls output to see if the object has any
unusual characteristics, perhaps being a hard link.  I would see if
'dsmc s' on it yielded different results than 'dsmc i'.  If so, contact
TSM Support to have them pursue.  You might also try boosting the client
level beyond base 5.2.0.0 and see if any difference, before calling.

    Richard Sims