Good morning,

on a (real big!) x86_64 machine, with freshly installed SuSE SLES 10.3,
scanning a mere ~500k files (and typically saving < 10,000 per run),
"dsmc" has been found to consume about 1.3 GByte of virtual memory
per single run. This is about tenfold from what you'd expect ...

And even worse, in the case of running "dsmc sched", the memory
consumption is cumulative in the sense that after three runs,
virtual memory has grown to about the maximum of ~4 GB, so that
the next time the scheduler ought to run, it will simply refuse
to proceded with a "cannot obtain memory" message (that's how
the problem was discovered in the first place).

Reproducible with "x86" Linux clients 5.5.2.7 and 5.5.1.4.
TSM server 5.5.2.1 on AIX, in case it matters.

Sure running "dsmc" via the CAD is currently a work-around ... but how long?

Normal operation of the client system also involves a lot of 32-bit code
(like the TSM client); I also performed a few simple 'malloc()' tests -
no indication so far that the memory allocation was fundamentally flawed.

IBM support is rather stumped. Any ideas welcome!

On this particular machine, I'd rather not experiment too much
with (potentially incompatible) client versions, unless it was known
that a recent 6.x version did indeed solve a problem of this kind ...

Best regards,

        Wolfgang J. Moeller <moeller AT gwdg DOT de>

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany