You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
Thank you for creating a bug report.
We will investigate the bug and evaluate its impact on the product.
If you haven't already, please ensure you have provided steps to reproduce the bug and as much context as possible.
Hey @ebz-jeaanmichel,
Thank you for reporting the performance concern on the TSO command.
I'm afraid that we no longer support the v0.x version of this project. However, we are diligently working towards making the v1.0.0 Beta pre-release easier to install and consume.
The final goal is to make the v1.x downloadable from the PyPi registry.
We will keep you posted with any developments on this front.
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.
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
The text was updated successfully, but these errors were encountered: