XCOM Windows server reporting 10038 and 10060 socket errors
search cancel

XCOM Windows server reporting 10038 and 10060 socket errors

book

Article ID: 368121

calendar_today

Updated On:

Products

XCOM Data Transport XCOM Data Transport - Linux PC XCOM Data Transport - Windows

Issue/Introduction

Over a weekend socket connect errors intermittently impacted XCOM for Windows production servers.

Socket errors are of two types:

#XCOMN0298E Unable to allocate remote transaction program: Txpi  215: Socket send error return value = 10038
#XCOMN0298E Unable to allocate remote transaction program: Txpi  211: Socket connect error return value = 10060

The remote server is running XCOM for Linux.

Environment

  • XCOM Data Transport for Windows
  • XCOM Data Transport for UNIX/Linux

Resolution

1. The initial incident just had 10038 errors on their own and that was resolved by the remote Linux server restarting the xcomd service.

2. The second incident had a mixture of 1038 and 10060 errors.
The 10038 errors are preceded by SSL error "XCOMN0780E Txpi  308: TxpiInitSSL Failed msg = <error:00000000:lib(0):func(0):reason(0)> value = 4294967295

XCOM Engineering advised:
All errors 10060 and 10038 are related to Windows outgoing transfers.

  1. 10060 is timeout and this error will only occur if the remote XCOM server, here the Linux machine, doesn't reply to the TCP socket connection request. This can be due to the network not forwarding the request from Windows or the Linux server being down.
  2. 10038 is typically reported if an XCOM TCP connection request with SSL is sent to the Linux system where xcomd is not running.

In summary the root cause is not due to XCOM and for these types of problems the administrators of the Linux machine and possibly network personnel need to be involved.
For a 10060, try a simple ping from Windows. For a 10038, the Linux administrator should verify that XCOM is running. Also see Additional Information.

In this scenario it was determined that maintenance activities were taking place at the remote Linux server and/or on the network connection between the 2 servers.

Additional Information

On Windows, a relatively simple network test to the remote Linux server secure port 8045 (SSL transfers) can also be done a few different ways:

1. Using the Telnet Client:
The "Telnet Client" can be enabled from Control Panel/Programs and Features > "Turn Windows features on or off" which for a Windows Server will redirect to Server Manager > "Add Roles and Features Wizard" ("Telnet Client" is listed under Features).
From a command prompt:
telnet linux_server 8045
a. If the connection is successful the command prompt window should clear and then have to use the escape key 'CTRL]' to get to the "Microsoft Telnet>" prompt. Then use 'q' to exit.
b. If the connection is unsuccessful then this type of message will appear:
Connecting To linux_server...Could not open connection to the host, on port 8045: Connect failed

2. Using a Powershell command which is simpler:
Test-NetConnection -computername linux_server -Port 8045
That would return True/False depending on successful/unsuccessful connection e.g.
ComputerName : linux_server
RemoteAddress : xxx.xxx.xxx.xxx
RemotePort : 8045
InterfaceAlias :
SourceAddress :
TcpTestSucceeded : True