I've spoken on the forum about this before but I'm wondering how widespread
it is...

Every night I get over 300 ANE4005E msgs in the activity logs of my ADSM
Servers.

On quite a few occasions this is because the file that ADSM was attempting
to backup was a temp file and was deleted before ADSM could back it up.
However a lot of these stem from files which have exceeded the max_path of
260chars. When a file exceeds this limit ADSM cannot back it up because it
adheres to the Win32 API Max_path variable.

This problem is documented by Microsoft in Q177665.

However the same article states that workarounds are available to allow
software programs to access files which exceed the max_path variable.

The method is documented at
http://msdn.microsoft.com/library/sdkdoc/winbase/filesio_7wmd.htm

Ultimately I think it's Microsoft that's got to fix this one. Why the heck
set a standard on your filesystem and then allow your software to violate
it?

However I'd also like to know why IBM are moving very slowly in implementing
the workaround that Microsoft have documented. Especially when Microsoft's
own rather limited backup utility can manage it!! IBM agreed to open an APAR
to document the difference in errors when a file has exceeded the 260
Max_path value and when it has been delete before being backed up. However
they see the underlying problem as a code enhancement and not likely to be
implemented until at least some time next year.

I consider this problem pretty severe. Is anyone else experiencing this
problem in volume?

Nathan King
MCSE, IBM ADSM CS
Open Systems Storage Management
*  (210) 913-5755
* Pager: 753-5755
* E-mail: nathan.king AT usaa DOT com

The opinions herein are mine and almost certainly do not reflect those of my
employer.