Performance Considerations for Conversation Services

The relative performance of APPC/MVS callable services varies depending on the functions that the callable service performs. For example, services that call VTAM or cause the movement of data buffers involve a greater number of internal instructions. For an overview of performance considerations for individual APPC/MVS TP callable services, see Table 1.
Table 1. Performance Considerations for MVS TP Callable Services
APPC/MVS Service
Calls
VTAM
Causes
DASD
I/O
Causes
buffer
moves
Calls
RACF
Creates
SMF
record
Allocate
 Yes Sometimes(1)
No
RACROUTE=
TOKENXTR,
TOKENMAP
No
Confirm
 Yes
No
No
No
No
Confirmed
 Yes
No
No
No
No
Deallocate
 Yes
No
No
No
No
Error_Extract
No
No
No
No
No
Extract_Information
No
No
Yes
No
No
Flush
 Yes
No
No
No
No
Get_Attributes
No
No
No
No
No
Get_Conversation
No
No
No
No
No
Get_TP_Properties
No
No
No
RACROUTE=
TOKENXTR,
TOKENMAP
No
Get_Transaction
No
No
No
RACINIT
SMF 33
Get_Type
No
No
No
No
No
Post_on_Receipt
No
No
No
No
No
Prepare_to_Receive
 Yes
No
No
No
No
Receive_Immediate
 Yes
No
Yes
No
No
Receive_and_Wait
 Yes
No
Yes
No
No
Register_Test
No
Yes (2)
No
RACROUTE=
TOKENXTR
No
Reject_Conversation
 Yes
No
No
No
No
Request_to_Send
 Yes
No
No
No
No
Return_Transaction
No
No
No
RACINIT
SMF 33
Send_Data
 Yes
No
Yes
No
No
Send_Error
 Yes
No
No
No
No
Set_Conv_Accounting_Info
No
No
No
No
No
Set_Syncpt_Options
No
No
No
No
No
Unregister_Test
No
Yes (2)
No
RACROUTE=
TOKENXTR
No
Note:
  1. Might read from the side information file.
  2. Modifies the TP profile.

One general performance tip is to minimize the number of calls to APPC/MVS for conversation services. Try to design a transaction program in such a way that it causes the least amount of code execution in APPC/MVS as possible, without overly complicating the program.

Each time APPC/MVS is called, APPC/MVS checks to see if the caller's parameters contain valid values. When possible, combine functions in a single call, and send and receive large blocks of data. Some specific ways to do this are described in the following suggestions.
  • Send as much data as possible on all Send_Data calls, thus minimizing the number of sends and receives.
  • Use the type parameter on the Send_Data service to combine operations.

    In APPC/MVS, a TP can combine other conversation operations, such as Flush, Confirm, and Deallocate, with each Send_Data call. This can often save an extra call to APPC.

  • Minimize use of the Confirm service.

    The Confirm service forces a transaction program to wait for an explicit acknowledgement from the partner. Use the confirm functions only when acknowledgement is required.

  • Minimize use of the Request_to_Send and Prepare_to_Receive services.

    When possible, the local and partner TPs should be written so that they are aware of the current state of the conversation, and exchange their Send and Receive states when appropriate. The state of the conversation is known at all times, based on what call was issued and the return codes and indicators that are returned. APPC/MVS Conversation State Table describes these states for each MVS TP service, indicator, and return code. CPI-C Reference describes these states for each CPI Communications call.

  • Minimize use of the Get_Type, Get_Attributes, and Get_TP_Properties services.

    Your TPs should know most of this information already. If these services are called, their returned values should be kept in local program variables for later use.

  • Use the Flush service judiciously.

    The Flush function forces APPC/MVS to send the data in its internal buffers, even though those buffers might not be full. Unless the partner needs the data immediately, let APPC/MVS determine when it is most efficient to send the data.

    If your TP calls a Send_Data service and then plans on calling no other conversation services for a while, it should probably call the Flush service or Send_Data with Send_Type of Flush to clear its buffers, so the data can be used by the partner TP.

  • Send one logical record per Send_Data call.

    In basic conversations, send as much data as possible on each send, but use only one LL (record length field) per call. Avoid splitting LL fields across calls.

  • Receive as much data as possible on each Receive call.

    Allocate a large storage area for incoming data, and receive as much data as possible on each Receive_and_Wait or Receive_Immediate.

    In basic conversations, specify a value of Buffer for the Fill parameter on Receive_and_Wait and Receive_Immediate, instead of a value of LL.

  • Use the deallocate_type of deallocate_flush on Deallocate calls.

    The deallocate_type of deallocate_flush is faster than the other types on the Deallocate service.