CSI TCP/IP Stack Testing Status for CA XCOM for z/VSE 3.1

Document ID : KB000029104
Last Modified Date : 14/02/2018
Show Technical Document Details

The attempt to certify the CSI TCP/IP 1.5F Stack for z/VSE (subsequently referred to as “the CSI stack”) has completed.  The results of the certification tests showed that the current state of the CSI stack is inadequate for our 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)      CA 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

 

Our research came across the following message board which describes the problem with the CSI stack:

http://bit.listserv.vse-l.narkive.com/RP58a8ug/tcp-ip-listeners

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.

 

CA 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 our 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 CA XCOM for z/VSE.

As a result of our testing, the CSI TCP/IP 1.5F Stack will not be certified with CA 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.