[Zowe TSO] Performance issue when use TSO command to search user details with "LU"

Hello Zowe Team,

We have been a recurring issue related to searching RACF account details using TSO command "LU OMVS TSO". Occasionally, Zowe task is consuming a lot of MIPS degrading the server and, when it happens, our support team has to restart Zowe.

We have noted a pattern during our troubleshooting: the first "LU" execution after Zowe restart causes this problem, and 30 minutes later the client service finishes with the message below:

HTTPSConnectionPool(host='host', port=443): Max retries exceeded with url: /zosmf/tsoApp/tso/ (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f21885c6550>: Failed to establish a new connection: [Errno 111] Connection refused',))

During this period of retry, we saw in the mainframe HTTP Logs that was sent more than one thousand of requests to reestablish the connection. However, if we try to search or even modify a user, during the retry, the service can process normally, with a new TSO session.

In the attached files we are providing the HTTP logs from the RACF server. Here we have the class used to handle those sessions and run TSO commands.

We need to understand why the "LU" command, for some cases, is consuming a lot of resources from the server, and if has an way to decrease the connection timeout.

• The environment
  Red Hat Enterprise Linux release 8.7 (Ootpa)
  pip 20.3.3 from /opt/zato/3.2.0/code/lib64/python3.6/site-packages/pip (python 3.6)
  zowe==0.2.0
  zowe-core-for-zowe-sdk==0.5.0
  zowe-zos-console-for-zowe-sdk==0.0.1
  zowe-zos-files-for-zowe-sdk==0.5.0
  zowe-zos-jobs-for-zowe-sdk==0.5.0
  zowe-zos-tso-for-zowe-sdk==0.0.1
  zowe-zosmf-for-zowe-sdk==0.0.1
  GNU bash, versão 4.4.20(1)-release (x86_64-redhat-linux-gnu)
  zosmfServer (z/OSMF 2.4.0/wlp-1.0.68.cl220920220815-1900) on IBM J9 VM, version 8.0.7.16 - pmz6480sr7fp16-20220830_01(SR7 FP16) (en_US)

HTTPLOG_07082023_a_13082023.zip

Start with the linked racf_tso_connection.py class and the attached RACF HTTP logs, focusing on the first LU request and the repeated failed connections to /zosmf/tsoApp/tso/. Trace how retries and connection timeouts are handled in the Python SDK. Done means the LU behavior has a documented cause and the connection retry or timeout behavior is bounded or configurable.