Error #TCP TYPE=CREATE , OUTPUT TCP=........ when using AT-TLS

Products

XCOM Data Transport - z/OS

Issue/Introduction

We have integrated the sample CBXGSAMP(XCOMTRNG) into our Policy Agent server for AT-TLS, changing only the following:

Jobname - We had set our XCOM server STC.
Cipher- Originally tried the same ciphers as the sample but we got an error that ICSF is not available (correct), then we tried to use only TLS_RSA_WITH_AES_128_CBC_SHA and this message was no longer received.

Port number, changed from the one in the sample.
Keyring- we use a shared keyring, so I entered it in the following format: acid/keyring (as used in other existing rules)

Next, we have set the following in our XCOMDFLT member:

AT-TLS=ALLOW

AT-TLS_PORTS=08xxx

8xxx was the port that we have previously used for basic SSL secured transfers. Now, we have set SSLPORT=08yyy for those transfers.

XCOM server STC came up successfully.

But when we submitted a job aiming to transfer a file from the mainframe to iteslf, via the loopback address, the following appeared on the STC log:

21339 11:06:21.3 XCOM 001205 SCHEDULE XCOMM0300I REQUEST # 001205 PROCESSED SUCCESSFULLY

21339 11:06:21.3 XCOMM0168E XCOM SCIP UNBIND TYPE 01 00000000 RECEIVED

21339 11:06:21.3 XCOMM0151I XCOM SESSION ENDED CID=4E000006

11:06:21 <ip-self> 001205 T73XSSL XCOMM0785I STARTING TCP/IP CONNECTION TO PORT=08xxx, IP=<ip-self>

11:06:21 <ip-self> 001205 T73XSSL XCOMM0786I TCP/IP CONNECTION ESTABLISHED WITH DEST=ISLF , PORT=08xxx, IP=<ip-self>

21339 11:06:21.8 XCOMM0795I FOLLOWING FMH7 SENT TO CONVERSATION PARTNER, IP=<ip-self>

21339 11:06:21.8 #TCP TYPE=CREATE , OUTPUT TCP=........

11:06:21 <ip-self> 001205 T73XSSL XCOMM0127E FMH7 SENSE 08890000 - GDS MSG FOLLOWS

11:06:21 <ip-self> T73XSSL XCOMM0805I TCP/IP CONNECTION ENDED WITH IP=<ip-self>

Then, we tried to initiate a transfer specifying IPPORT=8044 - the same error appears.

Environment

Release : 12.0

Component : XCOM Data Transport for z/OS

Cause

1. In both the TYPE=SCHEDULE and TYPE=EXECUTE tests, the same error return code information from the ioctl SIOCTTLSCTL function call is received.
This error information is the same for both and can be seen in the XCOM trace:

CATOTXPI 4042 ioctl(sock, SIOCTTLSCTL, (char *)&ioc) <rc=0, errno=138, errnojr=0x11B3005A>
CATOTXPI 4194 EDC5138I No such device or address. (errno2=0x11B3005A)

The ERRNO 138 (ENXIO) means the device or driver was not found.

The ERRNOJR (005A) indicates that the "file system" is not initialized. In this case the "file system" would have to be the IBM LE runtime
which is responsible for supporting the SIOCTTLSCTL extension to the ioctl function. This in all likelihood points to an issue with the LE
runtime you are using.

2. The XCOM trace also shows the following message:

CATOTXPI 312 TCPSTACK=TCPIP
CATOTXPI 321 Error in setibmopt call, rc=1, errno=138, (errno 138 is OK)

Resolution

1. Some writings have been seen related to this error and have suggested a firewall problem, IP address problem, or in one case, there is an
IBM LE APAR which corrects a problem in LE when IP addresses have trailing blanks.

Please debug this with your network team and/or IBM support since this seems specific to a system configuration.

We use this specific ioctl function to validate that an AT-TLS connection was established, and to extract specific information about the
connection so that it can be reported in the XCOM log. This is the proper (read: ONLY) way that specific information related to the socket
connection can be retrieved. If this function fails, the connection cannot be validated, thus the reason it is rejected by XCOM.

2. If you don't have more than one TCP/IP stack running on the system where these transfers run, then it is suggested that XCOM be configured without the TCPSTACK= parameter being set. That will prevent the error.