z/OS MVS Setting Up a Sysplex
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Message buffer size

z/OS MVS Setting Up a Sysplex
SA23-1399-00

First let's look at the individual message buffer size definitions. Message buffer size is determined by the CLASSLEN parameter on the CLASSDEF statement in the COUPLExx parmlib member. The CLASSLEN value determines the size of the most frequent message expected in this transport class. If a message could be assigned to more than one transport class, XCF selects the one with the smallest buffer that will hold the message. If the signal is larger than the CLASSLEN for any of the assigned transport classes, XCF has to choose a transport class to expand. Since APAR OW16903, XCF assigns the message to the transport class with the largest buffer size and expands the buffer size of this transport class. Prior to this APAR, the transport class named DEFAULT was chosen to be expanded, even if it had a very small class length.

Expanding the message buffer entails some overhead. The PATHOUT on the sending side and the PATHIN on the receiving side must be cleared out and expanded to handle the larger buffer size. A new, larger buffer must be obtained on the PATHIN side. If no additional messages of this size are received in a short time period, XCF then contracts the PATHIN, PATHOUT, and buffer sizes. In both of these cases extra XCF internal signals are generated to communicate these changes.

The best way to eliminate the overhead of expanding and contracting the message buffers is to define transport classes based solely on the size of the message buffers. One class with the default length of 956 should handle most of the traffic. A second class can be defined to handle larger messages.

An example of this specification in the COUPLExx parmlib member is: CLASSDEF CLASS(DEFSMALL) CLASSLEN(956) GROUP(UNDESIG) CLASSDEF CLASS(DEFAULT) CLASSLEN(16316) GROUP(UNDESIG)

The parameter GROUP(UNDESIG) specifies the messages should be assigned to the transport class based solely on message size. This definition makes all the resources available to all users and provides everyone with peak capacity.

There may be times when you want a separate transport class for a specific group. For instance, if you have a particular XCF user which is consuming a disproportionate amount of XCF resources, you may want to isolate this user to a separate transport class to investigate the user's behavior and protect the other XCF users. Hopefully, after you have diagnosed the problem, you can reassign this user to a transport class based on the length of the messages.

You can use an RMF™ XCF report to determine how well the messages fit. Figure 1 shows an example. In this example, the majority of the messages fit in the DEFSMALL class. A few exceeded the size of the DEFAULT class, but not enough to justify the definition of a new transport class.
Figure 1. Example: RMF XCF Report
                XCF USAGE BY SYSTEM 
--------------------------------------------------------------------
                                    REMOTE SYSTEMS
--------------------------------------------------------------------
                OUTBOUND FROM JB0
---------------------------------------------------------------------
                                             ----- BUFFER -----
TO          TRANSPORT   BUFFER         REQ    %    %    %    %        
SYSTEM      CLASS       LENGTH         OUT   SML  FIT  BIG  OVR
JA0         DEFAULT     16,316         189    98    1    1  100
            DEFSMALL       956      55,794     0  100    0    0  
JB0         DEFAULT     16,316         176   100    0    0    0
            DEFSMALL       956      44,156     0  100    0    0
JC0         DEFAULT     16,316         176   100    0    0    0 
            DEFSMALL       956      34,477     0  100    0    0 
                                ----------
TOTAL                              134,968

  
%SML is the % of messages smaller than the buffer length 
%FIT is the % of messages which fit the buffer length
%BIG is the % of messages larger than the buffer length
Note: XCF has internal buffers of fixed size: 1K, 4K, 8K, ...64K. XCF uses 68 bytes for internal control blocks. So if you specify a length that doesn't fit one of these sizes, XCF will round up to the next largest size. For example, if you specify 1024, it will not fit into the 1K block (1024-68=956), and XCF will round up to the next largest block. The command, D XCF,CLASSDEF, will list the CLASSLEN specified in the PARMLIB member, in this example, 1024. The RMF XCF report will show the actual buffer length, in this case, 4028.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014