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