XCOM SCHEDULED TRANSFERS KEEP QUEUED ALONG MANY HOURS
Article ID: 130611
Updated On:
Products
XCOM Data Transport
XCOM Data Transport - Windows
XCOM Data Transport - Linux PC
XCOM Data Transport - z/OS
Issue/Introduction
We are engaging you due to a problem we faced with some SCHEDULED transmissions that were queued and started to be transmitted after 9 hours. We did not find any trouble that could explain that delay. During those 9 hours, there was not an error message referring to these request numbers. We have tracked reqnum 78700 as an example of the behavior we see. Please let us know your thoughts about this behavior.
Environment
XCOM r12.0 for z/OS, XCOM r11.6 SP00 for Linux
Resolution
After reviewing the provided documentation it has been suggested the following:
Many factors can come into play here for possible reasons for this problem...
XCOM processes with whatever resources are available. There must be sufficient CPU, network and DASD (I/O) resources to service the request. Was the dataset archived? Was the partner UNIX system healthy at that time? Why were the same other transfers retrying over and over for that same UNIX partner?
- Suggested applying fix SO05349 for XCOM for Linux if running XCOM r11.6 SP00 64 bit..
- Suggested that they use packing for the transfers. It will improve the performance.
- If running XCOM r11.6 SP00 32 bit they need to upgrade since support for that version has ended as of 2/28/2018.
- Have them check for the values of the CACHE_READ_SZ= and CACHE_WRITE_SZ= in the xcom.glb. Make sure it is set to 0. Once change is done to the xcom.glb the xcomd deamon has to be stopped/started.
- Based on what was in the XCOMLOG from z/OS, their seem to have TCPIP or network issues and need to address those in order to clear the TXPI messages received that were pointed out.
- If XCOM is upgraded to SP01, then the License messages will be suppressed.
Many factors can come into play here for possible reasons for this problem...
XCOM processes with whatever resources are available. There must be sufficient CPU, network and DASD (I/O) resources to service the request. Was the dataset archived? Was the partner UNIX system healthy at that time? Why were the same other transfers retrying over and over for that same UNIX partner?
- Suggested applying fix SO05349 for XCOM for Linux if running XCOM r11.6 SP00 64 bit..
- Suggested that they use packing for the transfers. It will improve the performance.
- If running XCOM r11.6 SP00 32 bit they need to upgrade since support for that version has ended as of 2/28/2018.
- Have them check for the values of the CACHE_READ_SZ= and CACHE_WRITE_SZ= in the xcom.glb. Make sure it is set to 0. Once change is done to the xcom.glb the xcomd deamon has to be stopped/started.
- Based on what was in the XCOMLOG from z/OS, their seem to have TCPIP or network issues and need to address those in order to clear the TXPI messages received that were pointed out.
- If XCOM is upgraded to SP01, then the License messages will be suppressed.
Feedback
Yes
No
Powered by
