Richard,

Very good points.

In fact, we also discussed this when we evaluted the requirement.
There are other reasons for customers to want to boost
the COMMTIMEOUTs for certain nodes based upon
communication links etc... and this was termed as
a shorter term solution for this SQL problem
but also necessary to satisfy other requirements.

The long term solution will probably be more like
you discussed, i.e. to allow the restore verb protocol
to have a "pause" state... that would allow the
timer to be measured against the IDELTIMEOUT
timer versus the COMMTIMEOUT.. or even allow
the verb protocol to allow "pings" to indicate
that the client is busy, but still requires
services from the current restore. We obviously
have to keep bounds on this to allow freeing
of resources in error situations.

Thanks for your excellent input.

Del

----------------------------------------------------

> 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.
>