Many xcommail.exe and cmd.exe processes active after transfers
Article ID: 262895
Updated On:
Products
Issue/Introduction
Unusual behaviour after upgrade of XCOM for Windows from r11.6 SP01 to r11.6 SP03 patch level 022110 .
Since the upgrade all these xcommail.exe and cmd.exe processes are active and building up in Windows Task Manager. XCOM became hung and is not processing transmissions.
After using taskkill to remove the xcommail and cmd.exe processes, XCOM recovered and is no longer hung and processing normally.
Sample screenshots below where the "User name" who owns all the process is the XCOM transfer userid:
The %XCOM_HOME%\xcom.glb , xcom.cnf and xcomntfy.bat files all use default values for mail and notification.
The remote partner sending the transfers is XCOM for AS400 where RMTNTFYL=A is set to trigger remote notifications.
Environment
- XCOM™ Data Transport® for Windows 11.6, SP01, SP03
- XCOM™ Data Transport® for Windows 12.0
- XCOM™ Data Transport® for AS/400 i5/OS
Resolution
The XCOM for AS400 setting RMTNTFYL=A is triggering the XCOM post-processing notification script after the transfer completes on the Windows side.
To stop the build up of xcommail.exe and cmd.exe processes the xcom.glb parameter XNOTIFYCMD was set to null instead of default "XNOTIFYCMD=%XCOM_HOME%\xcomntfy.bat" and the xcomd service restarted. That change prevents the xcommail.exe process from being called.
NOTE: Email notifications were not required in this environment and the extra xcommail.exe/cmd.exe process behaviour is just due to some change in behaviour after the upgrade.
Alternatively instead of making the XNOTIFYCMD change the xcomntfy.bat script could be modified to exit without doing anything by changing line 83 as follows:
FROM: if NOT /%use_pop%/ == /YES/ GOTO SKIP_POP
TO: if NOT /%use_pop%/ == /YES/ GOTO END
The advantage of modifying the script is that the xcomd service does not need to be restarted like it does for the change of XNOTIFYCMD to null in the xcom.glb file.
EXPLANATION OF BEHAVIOUR:
The xcomntfy.bat is an XCOM post-processing script and so gets executed under the transfer userid.
It is executed with this type of command (visible in the *_service.trc file):
cmd.exe" "/c" "C:\Program Files\CA\XCOM\xcomntfy.bat" -q 000092 -h M -u "xcomuser" -m MAPI"
The xcomntfy.bat section "EXEC_MAPI" then calls the xcommail.exe process as follows:
xcomqm -Dnnnnn | xcommail nnnnn xcomuser
When xcommail is executed if there is no email client program configured/installed an email dialog box like this will pop in the user session for the userid being used in the transfer:
The transfer userid needs to have an open session on the server to be able to see that dialog box and close it.
Not doing that is what is causing the xcommail.exe and cmd.exe processes to accumulate.
Regarding the change in behaviour between SP01 and SP03 without change in OS version, it is most likely due to vulnerability security fixes to enable XCOM exit scripts (including notify) to run under the user context as opposed to the system context. In SP01 the notify process was not able to invoke xcommail.exe when there is no active session for the transfer userid while in SP03 it is able to invoke xcommail.exe but without a session for that userid to acknowledge the email client dialog box the xcommail.exe process just stays running.
In summary the current SP03 behaviour is expected and working as designed so the best way forward is to either set XNOTIFYCMD to null in the xcom.glb file or modify the xcomntfy.bat script to exit without doing anything.
NOTE: Potentially the same symptoms could occur when upgrading from 11.6 SP01 to 12.0.
Additional Information
XCOM for AS400: RMTNTFYL
XCOM for Windows: 11.6: How to Use Processing Scripts, 12.0: Use the Processing Scripts
Feedback
