ERROR: "XCOMM0790E TCP/IP TASK LIMIT EXCEEDED ON INCOMING ACCEPT-TRANSFER TERMINATED"
Article ID: 26337
Updated On:
Products
Issue/Introduction
XCOM for z/OS Message XCOMM0790E says to increase or remove the limit specified by TCPSESS. But which TCPSESS should be changed, and why?
Environment
XCOM™ Data Transport® for z/OS
Cause
XCOMM0790E is issued by XCOM for z/OS whenever there's an incoming TCP/IP transfer request from a remote partner and the number of current connections to that particular partner is equal to the value of the XCOMDFLT or Config Member parameter TCPSESS. The text of XCOMM0790E still refers to the days when TCPSESS was a parameter only in XCOMDFLT.
TCPSESS in XCOMDFLT or the Config Member controls the number of simultaneous connections, and sets the default for outgoing and incoming. But for outgoing you may also use TCPSESS in XCOMCNTL's DEST members to adjust the value on an individual basis, though you may never exceed the XCOMDFLT or Config Member setting. The TCPSESS parameter in XCOMDFLT or the Config Member is meant to regulate concurrent TCPIP transfers coming in to, or going out of, the z/OS server per IP address.
Resolution
Contrary to what might be expected, it is TCPSESS in XCOMDFLT or the Config Member that needs to be changed. TCPSESS in XCOMDFLT CAN be a factor in remotely-initiated transfers. So the correct action is to increase TCPSESS in XCOMDFLT if you want all the transfers to be serviced.
F XCOM,INQ,MAX shows what the TCPSESS value currently specified in XCOMDFLT or the Config Member is. This value can be changed dynamically via the command
F XCOM,DFLT,TCPSESS,nnn where nnn is a value between 0 and 128.
For example, if TCPSESS in XCOMDFLT is set to 4, then with 3 different partners there can be 12 IP transfers going (4 each to/from the 3 different IP partners). TCPSESS in the DEST member however allows to set the number of IP sessions for a particular IP partner.
The TCPSESS value set in a DEST member must be equal to or less than the TCPSESS value set in XCOMDFLT or the Config member. The idea is that TCPSESS in XCOMDFLT or Config Member (which is global) should be set to a value that is the maximum number of sessions that an IP partner can handle, and then TCPSESS in the XCOMCNTL DEST member can be used for an IP partner that cannot handle those maximum sessions.
The XCOM for z/OS server can handle a large number of incoming and outgoing sessions, but a partner may not have the capacity to handle the number of IP transfers from z/OS to it (Windows for example). In that case, code a DEST member for the Windows partner and limit the TCPSESS.
So TCPSESS in XCOMDFLT or the config member should equal the maximum number of sessions that are to be allowed for each IP partner. TCPSESS in the destination member for a partner does not need to be specified unless there is a need to limit IP transfers from z/OS to that partner.
BUT: setting TCPSESS in XCOMDFLT to a large value opens the possibility of a 'rogue' partner initiating many transfers to the mainframe.
TCPSESS in a destination member should never affect an incoming transfer.
Setting a Limit on the partner platform
The TCPSESS equivalent can be set on the remote partner as well but it only regulates what is going in to and out of the remote partner. For example, you can set xcom.ses on Windows to 10. This means you can have 10 IP sessions in to and out of your Windows machine, but this does not regulate how many IP sessions a z/OS partner can have.
Examples:
For example: if on z/OS we have TCPSESS=4 in XCOMDFLT, it is saying that it can only handle 4 IP sessions to each partner even though the Windows xcom.ses says it can handle 10. Now, if you set TCPSESS=10 for the Windows DEST member, you still cannot do more than 4 IP sessions because the TCPSESS in XCOMDFLT is global and TCPSESS in the DEST member may only be equal to or less than the TCPSESS in XCOMDFLT. It cannot be higher and will not be honoured if it is higher. It can be used only to limit the IP session to that DEST member. In this case, if you set TCPSESS to 2 in the DEST member for Windows, then it will be honoured by z/OS and it will allow only 2 concurrent sessions to the Windows machine even though TCPSESS=4 in XCOMDFLT and xcom.ses is 10 on Windows. The Windows machine can have 10 IP transfers going with, say, a UNIX partner that has its own xcom.ses set to 20. Each platform sets its own IP session limit. Thus the Windows machine in this example has xcom.ses set to 10 and cannot dictate to z/OS which has set TCPSESS to only 4 in the XCOMDFLT. In the same manner, if z/OS has TCPSESS set to 100 it cannot initiate more than 10 IP transfers to this Windows machine because it will reject transfers 11 to 100 even though z/OS will initiate 100 IP transfers to it.
Take another example, this time with TCPSESS=4 in XCOMDFLT and TCPSESS=3 in the DEST member: initiating 6 transfers on z/OS to that destination, XCOM will start 3 as the value in the DEST member overrides the TCPSESS in XCOMDFLT. But initiating 6 transfers on the Windows machine to z/OS ( with xcom.ses set to 10) only 4 will get started and 2 will get the message saying session exceeded. Thus the TCPSESS in XCOMDFLT is in control.
It gets even more complicated when different formats of IPNAME are taken into account. Taking yet another example: if the XCOMDFLT table has TCPSESS=4 and the DEST member has TCPSESS=3 with IPNAME=DEST1, XCOM is supposed to allow only 3 transfers to DEST1. But XCOM may allow 7 transfers with DEST1 (3 outgoing and 4 incoming) because the incoming will be running with IPNAME=nnn.nnn.nnn.nnn which does not match IPNAME=DEST1. All incoming transfers will be running as IPNAME=nnn.nnn.nnn.nnn and limited by TCPSESS in XCOMDFLT. Thus, in this example, XCOM will allow 3 outgoing for IPNAME=DEST1 because the DEST member overrides TCPSESS=4 in XCOMDFLT. For the incoming, XCOM will allow 4 for IPNAME=nnn.nnn.nnn.nnn which XCOM is not aware is the same as IPNAME=DEST1, giving a total of 7. If the DEST member specified IPNAME=nnn.nnn.nnn.nnn, then only 3 transfers will be allowed by XCOM (incoming and outgoing) because XCOM will be able to match the IPNAME.
Feedback
