Features of the MVS-Specific Services
- Support for data spaces
APPC/MVS allows send and receive data buffers to reside in data spaces and accommodate large amounts of data. The following LU 6.2 conversation services use data buffers and accept an access list entry token (ALET), along with the buffer address, to designate the address space or data space in which the buffer resides:
- Extract_Information
- Receive_and_Wait
- Receive_Immediate
- Send_Data
The services listed above accept ALETs for entries on the dispatchable unit access list (DU-AL) for the unit of work that calls those services. Keep the following restrictions in mind when specifying an ALET:- The ALET cannot be the value 1 (which indicates secondary ASID).
- The ALET can represent an entry on the primary address access list (PASN-AL)
only when the ALET points to a SCOPE=COMMON data space (also known as a common
area data space).
A SCOPE=COMMON data space provides your TP with virtual storage that is addressable from all address spaces and all programs. Your TP might want to use a common area data space when it has large amounts of data that it wants to share across multiple address spaces. For more information about how to create and use SCOPE=COMMON data spaces, see z/OS MVS Programming: Extended Addressability Guide.
- Parameter lists and parameters other than data buffers must reside in the caller's primary address space.
- Asynchronous Processing
TPs can use many of the APPC/MVS services asynchronously by specifying the address of an event control block (ECB) on the Notify_Type parameter. The TP can then continue other processing without waiting for the service to complete. When the service completes, APPC/MVS notifies the TP by posting the ECB.
- Transaction Schedule Types
The APPC/MVS transaction scheduler lets you assign a schedule type of standard or multi-trans to transaction programs.
When transaction programs are scheduled as standard (the default), APPC/MVS initializes them for each inbound conversation request and terminates them when they finish processing. Standard scheduling requires that a TP's resources be allocated and deallocated for each inbound conversation, and isolates TPs from each other and from subsequent requests for the same transaction program. The standard schedule type provides full security and basic performance for TPs that are not invoked very frequently or do not require extensive allocation of resources.
In contrast, the multi-trans schedule type causes a transaction program to remain active between inbound conversations, with its resources available. After each conversation ends, the next calling partner can use the same instance of the transaction program and avoid the overhead of repeated resource allocation and deallocation.
Multi-trans TPs run under a shell environment that is responsible for doing all necessary cleanup to ensure that a TP's conversations and data are secure for consecutive users. With proper design, multi-trans scheduling can offer greater performance for transactions that are requested often by multiple users, that have a high resource overhead, and that finish processing comparatively quickly.
To use the multi-trans scheduling option, transaction programs must be defined with a TP schedule type of multi-trans in the TP profile. For standard scheduling, the TP schedule type can be set to standard or omitted. For more information, see Using TP Schedule Types.
Note: Multi-trans scheduling is a feature of the APPC/MVS transaction scheduler. If your transaction program runs under another transaction scheduler on MVS, multi-trans scheduling is unavailable.