Hans Beierle writes:

> We have applications building up directories with 50000+ files and
> encountered due to this size also various timeout problems during backup
> runs. Same as others did, we fixed that by increasing COMMTimeout. Yet,
> I'm concerned about having to change a general option which applies
> to all client/server sessions to address a problem which relates only
> to some few clients. The install manual states about COMMTimeout:
> "The server terminates the session to release communication resources as
> soon as possible, and to ensure that database locks are not held for
> undue periods of time."
> So, I assume that COMMTimeout should be as low as possible. To get around
> these long running directory scans, the ADSM client should have a kind of
> 'heartbeat' function, which tells the server that it's still alive.

We see this issue quite a bit with large directory structures, although the
IDLETIMEOUT setting is more often the culprit. (ANR0481W is a timeout related
to COMMTIMEOUT and ANR0482W is related to IDLETIMEOUT; we tend to see the
ANR0482W messages more often.)

I am not aware of any problems caused by increasing COMMTIMEOUT. The only
issue I can see with increasing IDLETIMEOUT is if you have a lot of users
who start ADSM sessions but don't end them. This could potentially cause
a shortage of sessions, which you can control with the MAXSESSIONS option.

Although I can not formally announce anything, performance is a major line
item for the next version of ADSM, so this issue may end up being addressed
there.

Andy Raibeck
ADSM Level 2 Support