前面一篇博客我们论了DBMS的architecture的历史进程，其中RAS最具优势的就是DSG ---DATA SHARING GROUP
其整体的architecture结构如下：
Parallel Sysplex Components
Major DB2 Data Sharing Components
注意上面两幅图之间的不同呦，
这幅图对DSG的结构展示的还是比较详细的，而且不同component之间的关系通过不同的线进行连接，更加清晰的展示了各个不同组件之间的关系如不同的member之间通过sysplex timer 相连，而不同的application则通过CF中的lock structure相连接（也就是所谓的linkS）
这些component之间的作用解释如下：
? Coupling Facilities (CFs)
– With structures
– Usually more than one CF
– Run CFCC code rather than z/OS
? Members
– Such as LPARs
– Up to 32 members
? Links between Members and CFs
– Configured for bandwidth and availability
? XCF
– Provides a communications mechanism
? Applications
– Exploiting CF structures directly
– Using XCF services
? Timer
– Ensures all members are synchronised
– Traditonally Sysplex Timer
– Strategically Server Time Protocol network
? XES manages communications
（从上面的介绍我们可以看出XCF比XES重要哈，内容多，嘿嘿，事实是不是真的这样？
上图，有图有真相：
这里我们只对其中的CF，XCF，XES进行研究，首先是概念定义：
CF 软件的角度理解就是OS ,只不过运行的是CFCC，从应用的角度来说就是LPAR外的cache，从硬件的角度来说就是memory
XCF和XES就没有那么好理解了
IBM官方给出的解释如下：
XCF is a component of z/OS. It provides the signaling services in a sysplex. Authorized applications can call XCF services to pass messages to other LPARs in the sysplex. XCF uses signaling paths over high-speed fibre interconnects between servers or through CF list structures and for maintaining the status of members of the sysplex.
XES is another component of z/OS. It provides the Parallel Sysplex services that applications and subsystems use to communicate with the Coupling Facility. These services support the sharing of cached data and common queues while maintaining data integrity and consistency. Any subsystem, such as DB2, that needs to perform activity against the CF structures uses XES services.
通过二者的定义我们可以看出，application通过XCF将消息传递到其它LPAR
而 XES的主要作用是在sysplex中，主要是application与subsystem同CF通信 （看上图）
下面我们就主要来看看XCF：
General signalling mechanism
– Introduced before the other Parallel Sysplex functions
Traffic divided into transport classes
– These use either Coupling Facility structures or CTCs to pass messages
? Dynamically routed based on XCF observing performance
? Dedicated CTCs
– Originally were faster than CF structures
– Transport classes have a maximum message size
? Fitting messages to classes is a significant tuning item
– One message per buffer
> Buffer space wasted if message smaller than the buffer
> Additional processing if it’s bigger
Applications use specific XCF group names
– Example: IXCLOxxx is XES lock resolution
– Application address spaces connect as members of the group
下面我们看看如何进行XCF tuning：
首先我们要明白XCF的运行机制：
XCF signaling is used to communicate between various members of a sysplex. T
he user of XCF
signaling, usually an MVS component or a subsystem, issue messages to members within the
user’s group. The content and/or use of these messages are unique to the members of the group.
As XCF messages are generated, they are assigned to a transport class based on group name
and/or message size. The messages are copied into a signal buffer from the XCF buffer pool.
The messages are sent over outbound paths, (PATHOUT), defined for the appropriate transport
class. Messages from other systems are received by inbound paths, (PATHIN). Inbound paths
are not directly assigned transport classes, although a correlation can be made about which
transport class messages are received via the inbound paths based on the outbound path to which
the inbound side is connected.
通过上图我们，message是从XCF buffer copy到 signal buffer ，然后通过path 进行传输，
message会根据groupname或是message的大小分配给不同的transferclass，
XCF message 通transport class相关联
Transport Classes
第一步message classify:
Transport classes are used to group messages. Using the CLASSDEF parameter in the
COUPLExx parmlib member you can assign messages to a transport class based on the group
name, the message size, or both.
其中每一个transfer class都有自己的signal buffer pool 以及对应好的pathout
Each transport class has its own resources which consists of a buffer pool and one or more
outbound signaling paths. It is recommended you keep the number of transport classes small. In
most cases, it is more efficient to pool the resources and define the transport class based on
message size. Some initial product documentation recommended separate transport classes for
GRS or RMF. These recommendations are no longer advised. If you do have separate transport
classes for specific groups based on early product recommendations you should consider
changing these definitions.
XCF 也有自己的buffer pool
Message Buffers
XCF message buffers are managed by correctly selecting the size of the message most frequently
sent from specific buffer pools and by specifying an adequate upper limit for the size of the
buffer pool.
Message Buffer Size
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.
-
CLASSDEF CLASS(DEFSMALL) CLASSLEN(956) GROUP(UNDESIG)
-
CLASSDEF CLASS(DEFAULT) CLASSLEN(16316) GROUP(UNDESIG)
此处定义两个transfer class且定义了每一个class所传输的message的size以及message对应的group，
其中
The CLASSLEN value determines the size of the most frequent message expected in this
transport class
如果message大于classlen的定义，则选择classlen较大的transfer class
message size expand ：当message size的大小大于任何一个transfer class的 classlen的定义时，classlen定义最大的transfer class会进行expand，不过这会产生overhead，实际中应该尽量少避免这种expand
If the signal is larger than the
CLASSLEN for any of the assigned transport classes, XCF has to choose a transport class to
expand. XCF assigns the message to the transport class with the largest buffer size and expands
the buffer size of this transport class.
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
parameter group制定了XCF generate的message如何assigned到不同的transfer class，
UNDESIG 定义了按照message size 进行group
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. XCF can
dynamically add and delete transport classes by using the SETXCF command.
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 which 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. If you issue a command, D XCF,CLASSDEF, it 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.
上面说了这么多，那么在实际的运维中，我们应该如何查看自己定义的transfer class呢？下面介绍一下相关的命令？
You can use aoperator command,
D XCF,CD,CLASS=ALL
to get information about the current behavior of the XCF transport classes.
命令解释：
The command, which has a single image in scope, returns
information regarding message traffic throughout the sysplex. The command returns infomation
regarding the size of messages being sent through the transport class to all members of the
sysplex and identifies current buffer usage needed to support the load.
Message Buffer Pools
Having determined the optimal size for the individual message buffer, the next thing to do is
select an upper limit for the amount of virtual storage to be allocated to the message buffer pool.
The message buffer space is virtual storage used by XCF to store the message buffers which are
being processed, sent or received.
下面的内容了解一下：
Most of the virtual storage used for this purpose is backed by fixed storage. The storage to hold
LOCAL buffers (for communication within the processor) is DREF (disabled reference)
storagehich is backed by central storage. LOCAL buffers are used for messages within groups
which are on the same MVS image. The most well known IBM exploiters of local messages are
APPC, JES2, JES3, and GRS in Star Mode but any XCF group may choose to take advantage of
LOCAL message processing.
XCF only uses the amount of storage it needs to support the load. But to ensure there are no
surprises which stress available central storage, the installation can use the MAXMSG parameter
to place an upper limit on the amount of storage which can be used for this purpose.
XCF storage is associated with the transport class, the outgoing paths, and the incoming paths, s
MAXMSG can be specified on the CLASSDEF, PATHIN and PATHOUT definitions, or more
generally on the COUPLE definition. MAXMSG is specified in 1K units. The default values are
determined in the following hierarchy:
OUTBOUND INBOUND
-----------------------------------|---------------------------------
PATHOUT - not specified, use | PATHIN - not specified, use
CLASSDEF - not specified, use | COUPLE
COUPLE |
ref：
