Number of paths

No Paths: In the worst case, there may be NO operational paths for a transport class. This is not fatal. XCF routes the requests to another transport class but there is additional overhead associated with this operation. To determine if this condition exists, look at the RMF™ XCF Usage by System report. ALL PATHS UNAVAIL should be low or 0. In many cases, this is caused by an error in the path definition; in other cases, there may be a problem with the physical path. In this example shown in Figure 1, the CTC links to system JA0 had been disconnected.

Figure 1. Example: XCF Usage by System - ALL PATH UNAVAIL

                    XCF USAGE BY SYSTEM                       
--------------------------------------------------------------------
                                      REMOTE SYSTEMS
--------------------------------------------------------------------
                     OUTBOUND FROM SD0
--------------------------------------------------------------------

                                                     ALL 
TO       TRANSPORT  BUFFER        REQ              PATHS       REQ  
SYSTEM   CLASS      LENGTH        OUT             UNAVAIL   REJECT 

JA0      DEFAULT    16,316        189   ...             0        0   
         DEFSMALL      956     55,794              55,794        0
JB0      DEFAULT    16,316        176                   0        0
         DEFSMALL      956     44,156                   0        0
JC0      DEFAULT    16,316        176                   0        0
         DEFSMALL      956     34,477                   0        0  
                           ----------
TOTAL                         134,968

In the next example from the same system (see Figure 2), notice for system JA0 there were no paths for the transport class DEFSMALL, so all the requests were re-driven through the DEFAULT class. This caused some queuing (see AVG Q LNGTH of 0.16).

Figure 2. Example: XCF Path Statistics - Requests Routed through DEFAULT Class

                     XCF PATH STATISTICS
-------------------------------------------------------------------
                      OUTBOUND FROM SD0                     
-------------------------------------------------------------------
        T FROM/TO                                 T FROM/TO
TO      Y DEVICE, OR      TRANSPORT     REQ   AVG Q
SYSTEM  P STRUCTURE       CLASS         OUT   LNGTH    AVAIL   BUSY  RETRY  
JA0     S IXCPLEX_PATH1   DEFAULT    56,011    0.16   55,894    117      0
JB0     S IXCPLEX_PATH1   DEFAULT       176    0.00      176      0      0 
        C C600 TO C614    DEFSMALL   16,314    0.01   16,297     17      0 
        C C601 TO C615    DEFSMALL   15,053    0.01   15,037     16      0 
        C C602 TO C616    DEFSMALL   15,136    0.01   15,136     20      0
JC0     S IXCPLEX_PATH1   DEFAULT       176    0.00      176      0      0    
        C C600 TO C614    DEFSMALL   11,621    0.01   11,515    106      0
        C C601 TO C615    DEFSMALL   13,086    0.01   12,962    124      0
        C C602 TO C616    DEFSMALL   11,626    0.00   11,526    100      0

Is it necessary to correct the 'ALL PATHS UNAVAIL' condition? In most cases, it is. In this example in Figure 2, DEFSMALL was defined to hold small messages (956). Because there is no path, they are being re-driven through the DEFAULT class. The DEFAULT class is sending data in large buffers (16,316 bytes). This is certainly not an efficient use of message buffer storage to transfer a 956 byte message in a 16,316 byte buffer. Re-driving large messages through a transport class defined with small messages causes more problems. It causes the buffers in this class to expand and contract with all the extra signaling explained previously. Defining separate classes is done for a purpose. If you don't provide paths for these classes, it negates this purpose.

Insufficient Number of Paths: Signaling paths can be CTC links or Coupling Facility structures. In the XCF PATH STATISTICS section example above, the TYP field indicates the connection is a coupling facility structure (S) or a CTC link (C). Since these two types of paths operate in unique ways, different methods are used to evaluate their performance.

Coupling facility structures
For coupling facility structures, an insufficient number of PATHOUT links could result in an increase in the AVG Q LNGTH, and BUSY counts high relative to AVAIL counts. Additional paths are obtained by defining more XCF signaling structures in the CFRM policy and making them available for use as PATHOUTs (and/or PATHINs).

Note: RETRY counts should be low relative to REQ OUT for a transport class. A non zero count indicates a message has failed and was resent. This is usually indicative of a hardware problem.
CTCs
CTCs can be configured in a number of ways. The installation can define CTC's as unidirectional (one PATHOUT or one PATHIN per physical CTC) or bi-directional (one or more PATHOUTs and PATHINs on a physical CTC). Due to the nature of XCF channel programs, a unidirectional path definition can achieve the most efficient use of a CTC thus providing the best XCF response time and message throughput capacity. However, a unidirectional definition will also require using at least four physical CTCs to configure for availability. Two paths are sufficient for most systems, thus only those customers with very high XCF activity, (requiring >=4 paths), should consider using the unidirectional definition.

What indicators should be used to determine if there are enough CTCs for a particular transport class? First of all, the AVG Q LEN on the RMF XCF report is not a good indicator. In the case of CTCs, queued requests are added to the CCW chain which can increase efficiency. A better indicator to use instead is the Display XCF command. This command was updated by XCF APAR OW38138 to provide the path response time (as seen by XCF). See Figure 3 for an example.

Figure 3. Example: Display XCF Command Path Response Time

D XCF,PI,DEVICE=ALL,STATUS=WORKING
 IXC356I  12.02.12  DISPLAY XCF 901
 LOCAL DEVICE   REMOTE   PATHIN    REMOTE                  LAST    MXFER    
 PATHIN         SYSTEM   STATUS    PATHOUT  RETRY  MAXMSG  RECORD  TIME
 C200           JA0      WORKING   C200        10     500   3496     339
 C220           JA0      WORKING   C220        10     500   3640     419

The MXFER TIME is the mean transfer time in microseconds for up to the last 64 signals received within the last minute. If the MXFER TIME is acceptable, less than 2 milliseconds, (or 2000 microseconds), there is probably enough CTC capacity. To insure capacity for heavier or peak workloads, also check the channel utilization for the CTCs, as reported on an RMF Channel Activity report. In laboratory testing, acceptable XCF message response times were observed even at channel utilization of 70% (or 90% when there were multiple CTCs per transport class). Beyond this threshold, response time degenerated rapidly.

RMF, with APAR OW41317 installed, will store the MXFER TIME as observed in the last minute before the end of the RMF interval in the RMF SMF 74 subtype 2 record.