The channel-to-channel adapter is a fast device, and Entire Net-Work provides even better performance by driving it directly rather than through some other access method.
Where applications require even better performance than can be provided by a single CTCA, Entire Net-Work allows you to use multiple CTCAs in parallel. The following discussion is provided to help you design your Entire Net-Work environment to meet your needs.
In single CTCA configurations, contention is one of the major reasons for performance problems when the load is increased. Since both nodes must send their messages over the same CTCA, they will occasionally attempt to do so simultaneously. In this case:
only one node is allowed to send;
the other will receive a busy indication, requeue its send buffer, perform the steps necessary to receive the other node's message, then attempt to resend its own message.
This attempt may fail again, however, if the other node gets its next message out first. The busier the CTCA, the more often this problem occurs.
Contention creates overhead for requeuing and retrying the failing I/Os. The problem is too much load on the device. The answer is to use multiple CTCAs. To use multiple CTCAs, parallel links can be specified.
Parallel links are no different from other links except that they connect the same two nodes. With CTCA parallel link routing, the link with the lowest WEIGHT parameter value is always selected as the sending link; the link with the higher WEIGHT parameter value is the receiving link. With FCTC, the UNITREAD and UNITWRT parameters are used to define which units are used for receiving and sending. Any other links are considered backups; that is, they are not to be used unless the "best" link goes down. From then on, the "next best" link is selected. When the "best" link again becomes available, it is automatically selected for data traffic.
Because only one link is ever selected as the sending link, there is no need to define more than two links in parallel except to use as backup links. To reduce system paging overhead, the number of receive buffers defined can be reduced where a lower number is deemed adequate. (See the RCVBLKCT parameter in the section CTCA and FCTC LINK Statements .)
The following example shows a two-node network with a pair of CTCAs configured as parallel unidirectional links, and a VTAM link as backup (to be used only if both CTCAs stop working).
NODE ONE ... * DRIVER CTCA LINK TO2A CTCA UNIT=E30,WE=1 LINK TO2B CTCA UNIT=E38,WE=10 * DRIVER VTAM APP=NETWRK1 LINK TO2V VTAM APP=NETWRK2,WE=100
NODE TWO ... * DRIVER CTCA LINK TO1A CTCA UNIT=E30,WE=10 LINK TO1B CTCA UNIT=E38,WE=1 * DRIVER VTAM APP=NETWRK2 LINK TO1V VTAM APP=NETWRK1,WE=100
The same unit addresses are used for both nodes because, in this example, device addresses are the same on both systems.
Each of the two nodes will select only the link with weight WE = 1. Thus
traffic from Node 1 to Node 2 is sent over CTCA E30 (link TO2A); while
traffic from Node 2 to Node 1 is sent over CTCA E38 (link TO1B).
If one of the two CTCAs malfunctions, traffic will be routed automatically through the other CTCA, causing some performance degradation due to contention. Only if both CTCAs become unavailable is the VTAM link used.
If the weight of the VTAM link were set to WE=5, the priorities would be reversed: if either of the CTCAs malfunctioned, the respective node would immediately start using the VTAM link instead. Running one CTCA with contention generally provides better performance, even if VTAM also uses a CTCA for its connection.