XCOM high CPU usage and connections to decommissioned XCOM server
Article ID: 272174
Updated On:
Products
Issue/Introduction
The XCOM started Task was using 10% CPU.
From the XCOMLOG, XCOM keeps trying to establish a connection to a decommissioned XCOM server on IP www.xxx.yyy.zzz.
Resolution
It appears that scheduled transfers to the decommissioned XCOM server are causing the behaviour. The connection to the decommissioned XCOM server is retried every 7 minutes which matches the XCOMLOG ERRINTV=7 (error interval), so the failed transfers are continuously being retried.
1. To check what transfers are still in the queue use this SHOW command and look for IP www.xxx.yyy.zzz:
/F xcomstc,SHOW
If the transfers show as active, then use the CANCEL command:
/F xcom_stc,CANCEL,www.xxx.yyy.zzz,IMMED
If the transfers show as not active, then use the DELETE command to remove them one by one:
/F xcom_stc,DELETE,nnnnnn
where 'nnnnn' is the transfer ID reported by the SHOW command
2. Alternatively, recycle the started task (only once) adding QSTART=COLD to the JCL PARM. This parameter causes XCOM to remove all pending transfers from the queue during startup.
The SHOW command in #1 was used and found:
===
XCOMM0013I SHOW
XCOMM0389I REQ#=942705,STATUS=NET ERR ,USER=AUTOM ,IP=www.xxx.yyy.zzz
XCOMM0389I REQ#=943566,STATUS=NET ERR ,USER=AUTOM ,IP=www.xxx.yyy.zzz
XCOMM0389I REQ#=944474,STATUS=NET ERR ,USER=AUTOM ,IP=www.xxx.yyy.zzz
XCOMM0389I REQ#=945345,STATUS=NET ERR ,USER=AUTOM ,IP=www.xxx.yyy.zzz
XCOMM0012I SHOW COMMAND PROCESSING SUCCESSFUL
===
The transfers were removed using the DELETE command one by one and the XCOMLOG shows no more errors.
Moving forward:
There is a DEST member for the decommissioned XCOM server IP named AIXTEST with writer AIXTEST1.
Member AIXTEST is NOT automatically enabled during startup (it is not mentioned in XCOMLOG messages XCOMM0559I xxxxxxxx ENABLED SUCCESSFULLY). Therefore it is not used and may be deleted from the XCOMCNTL library.
If this member was enabled in the past, it caused XCOM to try to send to www.xxx.yyy.zzz any SYSOUT from the JES2 queues having AIXTEST1 as the writer name. In terms of JCL, this means that the DD statement specified SYSOUT=(class,AIXTEST1). This is a possible origin of the transfer requests that were in the XCOM queue. This will never happen again because this destination is not enabled.
Additional Information
Feedback
