Avoiding common pitfalls with wait conditions

Once TSM is executing the instructions of a script, that execution proceeds uninterrupted until a wait condition occurs. Normally, at this point, script execution is suspended until the system function which required the wait is completed, then the script resumes execution at the point where the wait occurred.

Note:
Scripts that contain more than 400 instructions without a wait condition are suspended by TSM until either an event is received on that channel or the TSM event queue is empty. This may cause the script to execute with noticeable delays under heavy system load. To avoid this, design your scripts to include wait conditions (at least one per every 400 instructions).

Several things can happen during a wait which may effect script execution after that point. When a script needs to wait, TSM returns to reading its message queue to process external events that effect the execution of all currently running scripts. The following is a list of some of the actions TSM may take:

• TSM may resume execution of a waiting script on another channel where the conditions of the wait have been satisfied or the wait has timed out.
• Instead of a wait condition being satisfied normally, TSM may receive another event for the channel, such as a caller disconnect, which terminates the script.
• The MTC process may seize equipment being used by the channel causing the script to be terminated (if the seizure is done unconditionally).
• Touch tones typed by the caller are received by TSM and copied into the touch-tone buffer for the script during a wait.
• Events that are handled by the event script instruction may cause the current wait to be interrupted and script execution to be resumed with an interrupt subroutine (see the event instruction for further details). When this is done, the script may return to the point of interruption (and resume the wait) if the interrupt routine has not caused a second wait condition. If the interrupt routine does cause a wait, the original wait condition is disregarded and the script continues at the next instruction after the point of interruption when the routine returns (using the rts instruction).

It is important to remember how timeout values apply to wait conditions. The nwitime instruction may be used to change the general next wait instruction timeout (NWIT), which has a default of 45 seconds. This timeout value only applies to the next dbase, phreserve, sr_talkoff, tic, or tstop instruction wait. It does not affect the timeouts of other wait-causing instructions that have their own specific timeout values (see Wait-causing instructions). Nor does it affect the wait for speech to finish playing, which has no practical timeout. The NWIT is reset to the 45 second default when the second instruction after nwitime is executed.

Do not to let a wait condition separate a decision point in a script and its dependent action point if the decision is affected by what may happen in the system during the wait. An example of this is using the scrinst instruction to take action based on the number of instances of a particular script running at a particular time. The scrinst instruction returns the number of instances of a script at the time it is executed. If a wait condition is allowed between the scrinst and the point in the script where action is taken based on the result of scrinst, an unintended consequence may result because the number of scripts running may have changed during the wait. In this case, use tflush before scrinst to make sure that any wait for speech playing is not done at a critical time and take care not to use any other wait-causing instructions in the critical interval. This is especially important when using the exec instruction based on the result of scrinst since exec is a speech-flushing instruction.

© 2006 Avaya Inc. All Rights Reserved.