The multi-trans schedule type causes a transaction program to remain active between inbound conversations, with its resources available. Subsequent conversation requests can use the same instance of the TP and avoid the overhead of repeated resource allocation and deallocation.

Figure 1 shows how a multi-trans program receives and processes consecutive transaction requests. The multi-trans program is typically coded within a multi-trans shell, an environment that performs initialization and termination processing, surrounding the part of the TP that holds conversations. When a multi-trans program is scheduled in response to an initial allocate request, the multi-trans shell gets control first and allocates general resources, then calls the Get_Transaction service to obtain the inbound request. When the conversation ends, the shell regains control and calls the Get_Transaction service again when the transaction program is ready to handle the next request. Use of a loop structure lets you do the same processing for each requesting user.

Figure 1. Multi-Trans Scheduling for an APPC/MVS Transaction Program

To use multi-trans scheduling, transaction programs must be defined with a schedule type of multi-trans in the TP profile. The TP profile entry must also contain a user ID to provide the initial security environment for the multi-trans shell. The shell runs under this generic user ID during initialization, while the shell allocates general resources for the TP to use. The generic user ID remains in effect until the first successful Get_Transaction call, when the security environment is personalized to the user ID associated with the inbound request. That personalized security environment covers the entire conversation and remains in effect until the next Get_Transaction call, or until the shell explicitly returns to its generic security environment, typically to perform cleanup or data set reallocations between conversations. To return to its generic user ID, the shell can call the Return_Transaction service.

The multi-trans shell is responsible for doing all necessary cleanup between conversations to ensure the integrity and security of the TP's conversations and data for consecutive users. The shell can do the cleanup under the same user ID as the preceding conversation, or the generic user ID.

When there are no more inbound requests for a multi-trans TP to process, control returns under the generic user ID. A return code from Get_Transaction indicates whether or not the caller can invoke the Get_Transaction service again to wait for more work to arrive. If the shell does not call Get_Transaction again, it should clean up any remaining resources and end the program.

Figure 2 shows the different phases of multi-trans processing. Shaded sections are covered by the generic user ID; the rest is under personalized security.

Figure 2. Phases of Multi-Trans Processing

A multi-trans TP must manage user-specific resources such as SYSOUT data separately for each conversation. If you want a multi-trans TP to print SYSOUT data for each user, you need to allocate a SYSOUT data set and explicitly deallocate or close and free it for each conversation. If SYSOUT data sets are not deallocated or closed and freed, SYSOUT data is not printed for users of the multi-trans TP until the entire TP and its shell environment are terminated.

Multi-trans processing is appropriate only for certain types of transaction programs. As a general rule, when properly implemented, multi-trans processing is appropriate for transactions that are requested often by multiple users, that have a high resource overhead, and that finish processing comparatively quickly. For example, multi-trans processing could be appropriate for a phone book application that brings an entire phone book into a data space, then supplies phone numbers to multiple users in sequence.