>This is known issue and there is a requirement opened against the TSM
>Server to allow COMMTIMEOUT to be set on a NODENAME basis... since you
>don't normally want to set COMMTIMEOUT that large for all nodes.

Del - An approach to this which calls for boosting a timeout value
      (largely by guesswork), even if by nodename, to very high
values seems awfully crude and clumsy for an advanced product like TSM
- and would give product reviewers a point to hammer on in comparing
TSM with other products.  As a systems guy, I would instead seek to
alter product design to allow "intentional disconnect", or "stop
clocking me", in much the same philosophical way that mainframe devices
would disconnect from a channel in performing a lengthy operation, with
the channel controller understanding that they would pick up later.
COMMTIMEOUT should be allowed to retain its meaning - and moderate
values - to limit communications wait time where there was no
negotiation from the client to indicate that it would knowingly be busy
for a while.  The enduring TCP connection should suffice in negotiated
cases.  Causing a capricious timeout in a high-investment client-size
database operation is very undesirable.  And having the customer try to
guess a value is wince-worthy.  Note also that even if COMMTIMEOUT were
by node, it's still unsatisfactory, as nodes can certainly be doing
some combination of ordinary file system and commercial database work
over time, so a single value per node is still problematic.

  Richard Sims, Sr. Systems Programmer, Boston University OIT