Run in a sub-thread option
When this option is selected on the Inbound TPS Editor by clicking TPS Inbound Data, a sub-thread is created under the protocol thread. This sub-thread is used only for data type messages, not those of type reply. There must be a TPS defined; there is no sub-thread if a TPS is not defined.
forThere is only one thread involved with any IB/OB thread SMS (that is, TPS).
All protocol threads have a pre-SMS queue and a post-SMS queue. If there is a TPS defined, then messages go in the pre-SMS queue. The pre-SMS queue is skipped if no TPS is defined for the protocol thread. Between the two queues is the TPS that does something with the message and generates more messages.
If a sub-thread is used, then that TPS runs in it. During the time of the TPS processing, the engine is free to do other work. For example, input messages, output messages, move messages as part of the data flow. When the sub-thread has run the TPS procedure, it then signals the engine to pass the results into the post-SMS queue.
If the defined TPS is small and fast, then there is no requirement to use a sub-thread. The overhead of starting the thread would negate any gain. By “fast,” it is meant that it does not parse a message, as that can take time. It also does not access external data.
In terms of stages, the IB pre and post queues are stages 1 and 2 and the OB queues are stages 10 and 11.
In general, a single CPU machine gains slightly or even loses by turning on the sub-thread. This is the same as xlates.
In the same way, a process that is lightly loaded does not gain anything using the sub-thread. There is no work for the engine to do when it runs.
A sub-thread is helpful when there is a CPU available. It is also helpful when there is other work for the engine to do when the sub-thread is running. Parallel processing of messages is permitted if that is possible in the configuration.