We have a Digital Unix 5.1 client that is still running the ADSM v3.1.0.7
Client..........please don't respond "that's unsupported" - I know!

The client has been backing up without problems for about 2 years now. The
TSM server is TSM 4.1.2.0 for Solaris.

About 2 weeks ago, 'dsmc sched' (performing scheduled nightly
incrementals) and 'dsmc incr' (performing remedial backups) both began
failing on 1 of a dozen filespaces.  The client dies and produces a core
file - but not always; sometimes it reports a 'System ran out of memory'
error but then continues and successfully backs up the remaining filespaces.  
The "problem"
filespace is 85GB, 58% utilized, and has almost 2.5 million files buried
in very deep, broad subdirectories.  On the same server there are other,
larger filespaces (more files or more utilized GB) which are still backing
up without problems.

'dsmc' runs as root; 'ulimit' reports "unlimited".  The server has 1GB/4GB
physical/virtual memory.  'memoryefficientbackup' is set/enabled.  'ipcs
-a' reports a few semaphores in use, but none by 'dsmc'/'dsmstat' (since
we only back up local filesystems, we renamed/disabled 'dsmstat').  I
we only back up local filesystems, we renamed/disabled 'dsmstat').  I
tried running with trace turned on for 'errors'.   'dsmc' failed in the
usual place, but no trace output was generated.  I also ran the following
to just walk the directory structure and count the number of files; note
the elapsed time:

        # cd <root of problem filespace>
        # date ; ( find . -print | wc -l ) ; date
        Wed Jun 12 16:47:56 EDT 2002
        2429656
        Wed Jun 12 17:06:28 EDT 2002

I'm not confident that simply upgrading to the TSM 4.x/5.x Client will
resolve this.  Aside from upgrading, which is in the plan but can't be
done yet, is there anything else I can try or recommend now to alleviate this 
problem?

-ideas welcome, thanks
Kent Monthei
Kent Monthei
GlaxoSmithKline