CSI TCP/IP Stack Testing Status for XCOM for z/VSE 3.1
Article ID: 29104
Updated On:
Products
Issue/Introduction
This article describes the attempt to certify the CSI TCP/IP 1.5F Stack for z/VSE (subsequently referred to as “the CSI stack”).
Environment
- XCOM™ Data Transport® for z/VSE
- CSI TCP/IP 1.5F Stack for z/VSE
Cause
The results of the certification tests showed that the current state of the CSI stack is inadequate for XCOM's purposes
Resolution
The results of the certification tests showed that the current state of the CSI stack is inadequate for XCOM's purposes. Those results are summarized in this document.
The testing environment was the following:
1) z/VSE mini system (running under z/VM)
2) z/VSE version 5.2
3) CSI TCP/IP Stack 1.5F with all current maintenance available from IBM*
4) CSI TCP/IP Stack 1.5E
5) XCOM for z/VSE 3.1 with all published maintenance
6) MAXTASK was set to the maximum allowable value**
7) Multiple technicians were submitting transfer requests concurrently using CMS and z/OS NJE
The CSI TCP/IP 1.5F stack was minimally functional in the above-described environment. When keeping transfers limited to small volumes, the CSI stack remained stable and was able to process the workload given to it. However, when the volume of transfers was increased, the performance (speed) of the CSI stack began to deteriorate rapidly, and ultimately resulted in causing XCOM’s TCP/IP listener task to also become unstable. Each time this deterioration occurred, an IPL of the z/VSE mini was required in order to restore functionality. According to numerous messages received, the failure was responsible for producing a condition in the SYSTEM GETVIS area used for XMOVE handling of data buffers. This condition seemed to always create problems creating and passing sockets between address spaces and tasks on the system.
The CSI stack was not able to keep up with even half of the MAXTASK setting in the XCOM server, which was set to the maximum of 28. Once the deterioration began, in each case, it was a matter of minutes until the CSI stack and the XCOM TCP/IP listener ceased to process any new requests.
In researching to prepare for this testing, it was discovered that there were some technical message board discussions relating to the ability of the CSI stack to keep up with network traffic in the systems where it was running. The solution put forth in those message boards was to run multiple listener tasks. Due to the CSI stack’s non-standard socket implementation, it is possible to have multiple tasks listening on the same port on the same IP address. The specific details of how the CSI stack distributes the workload amongst the listeners is not clear, and is beyond the scope of this document.
Given the current design of XCOM for z/VSE and the intra-partition task limitations imposed by z/VSE architecture, it is not feasible to add additional listener tasks to a single XCOM for z/VSE instance. The only option available was to start a second XCOM for z/VSE server which was configured to listen on the same port and IP address as the primary server. This proved to be somewhat successful. The CSI stack did remain stable with a higher volume of transfers. However, as the volume continued to increase, the same symptoms started to manifest - performance (speed) began to deteriorate which ultimately resulted in XCOM’s TCP/IP listener task becoming unstable. An IPL of the z/VSE mini was required in order to restore functionality
The research came across the following message board which describes the problem with the CSI stack: TCP/IP Listeners on narkive.com
In this board there is an update from a Tony Thigpen (seems to be an independent contractor that works closely with BSI) that says:
**********
There are several things that are involved here.
The CSI SOCKET macro does not allow the type of "one listener/multi-child" process that is normal in TCP/IP Listeners. You need multiple listeners running because once a connection is made, that
socket is no longer available for more connections. Because of this, the CSI stack must allow multiple listeners on the same port.
EZA, on the other hand, is designed for the "one listener/multi-child" process that is normal on any other platform than VSE. In z/OS, it will not normally allow multiple listeners on one port. (For now we are
ignoring a couple of special SETSOCKOPTs that they have to allow some special processing.)
The CICS Listener is written in EZA, but when using the CSI stack, the underlying code still uses SOCKET macros with its restrictions. So there is a lot of ‘multiple open SOCKETs' and 'generate a new SOCKET'
code in the EZA interface from IBM. If I remember correctly, they generate 4 listeners. During heavy workloads, I could see where an extra listener transaction would be very helpful.
Things are different for the BSI stack. We work more like z/OS. One listener is all that is required for multiple connections. (Our EZA code does not use the SOCKET macro.) However, we do deviate from the z/OS
"only one listener per port" rule. We had to make the special SETSOCKOPT from z/OS the default because when we did not, IBM code had problems because they expected a stack that would allow multiple listeners on one port.
**********
XCOM uses the “one listener/multi-child” method across many platforms including z/OS, z/VSE and Windows to name a few.
While it is possible to run small volumes of work without multiple servers, a single-server configuration using the CSI stack is not able to support the XCOM documented and configurable task limits. This would leave us open to the possibility of being called on to support an environment that does not work due to limitations of the IP transport layer. There are no code changes we could make that would resolve the problems that could arise.
To be thorough and to control for the variable of the XCOM product itself, we also attempted to test with CSI’s TCP/IP Stack 1.5E .Although we certified the 1.5E version of CSI’s stack when we originally certified XCOM for z/VSE 3.1, that version of the CSI stack no longer functions with current levels of z/VSE. There are specific problems with the increased task identifiers in z/VSE, in addition to changes made to accessing z/VSE COMREG storage for cross-partition and cross-address-space communication. We no longer present any release of the CSI TCP/IP stack as a certified transport layer for use with XCOM for z/VSE.
As a result of the testing, the CSI TCP/IP 1.5F Stack will not be certified with XCOM for z/VSE.
* - the specific fixes applied to the CSI 1.5F stack are as follows:
CSI Service Pack 01.05 F(2013-11-27) has been applied. Pack status is GA
Fixes applied: 002, 003, 004, 005, 006, 007, 008, 009, 011, 012, 013
Fixes applied: 014, 015, 016, 018, 019, 021, 022, 024, 025, 026, 027
Fixes applied: 028, 029, 031, 035, 042, 068, 099, 103, 105, 106, 109
Fixes applied: 111, 115, 116, 118, 122, 123, 133, 134, 135, 143, 144
Fixes applied: 145, 147, 148, 149, 154, 160, 163, 164, 165, 168, 172
Fixes applied: 174, 177, 178, 179, 180, 185, 188, 189, 192, 193, 194
Fixes applied: 195, 197, 198, 200, 211, 213, 218, 220, 235, 238, 240
Fixes applied: 254, 257, 261, 263, 265, 266, 272, 273, 276, 279, 281
Fixes applied: 284, 285, 288, 289, 290, 291, 292, 293, 295, 297, 299
Fixes applied: 300, 303, 310, 314, 320 (Test), 329, 331, 332, 340, 341
Fixes applied: 343, 349, 354, 356, 362, 366, 368, 369, 374, 375, 384
Fixes applied: 391, 396, 397, 398, 402, 406, 407, 408, 409, 413, 414
Fixes applied: 415, 416, 417, 418, 419, 420, 424, 425, 427, 428, 429
Fixes applied: 430, 431, 432, 433, 434, 435, 436, 437, 438, 439, 441
Fixes applied: 442, 443, 445, 446, 447, 448, 449, 450, 451, 452, 453
Fixes applied: 454, 455, 456, 458, 459, 460, 461, 462, 463, 464, 465
Fixes applied: 466, 467, 468, 469, 470, 471, 473, 474, 475, 476, 477
Fixes applied: 478, 479, 480, 481, 482, 483, 484, 485, 486, 488, 489
Fixes applied: 491, 492, 496, 497, 498, 499, 506, 507, 511, 517, 520
Fixes applied: 524, 528, 529, 530, 532, 535, 537, 540, 551, 552, 553
Fixes applied: 556, 559, 560, 561, 562, 563, 564, 565, 566, 567, 568
Fixes applied: 569, 570, 571, 572, 573, 574, 575, 576, 577, 578, 579
Fixes applied: 580, 581, 583, 584, 585, 590, 591, 594, 595.
** - The maximum number of concurrent transfers for an XCOM for z/VSE 3.1 server is 28.
Additional Information
1. Information solution: MISCELLANEOUS ERRORS WHEN RUNNING WITH THE CSI 1.5X STACK
2. This article also gives an example of errors reported when the CSI TCP/IP stack was attempted to be used: XCOM for VSE transfer fails "Txpi 221: takesocket error 118"
Feedback
