"XCOMN0288E System function failed, RC=0" for RECEIVE file
Article ID: 252902
Updated On:
Products
Issue/Introduction
Have encountered a second of these errors in the past month for transfers between z/OS and Windows:
XCOMN0288E System function failed, RC=0
Would like to investigate further as a precaution to prevent further occurrences.
Environment
Release : 11.6
Resolution
RC=0 is the Windows return code which, per Windows System Error Codes (0-499), actually means "The operation completed successfully."
The spreadsheet with xcom.log extracts and other data shows a mixture of SEND FILE and RECEIVE FILE transfers between Windows and MVS.
Problem Transfer Number 161153 shows RECEIVE FILE fails with message: "XCOMN0288E System function failed, RC=0"
A customised pre/post-processing script failing or a SEND JOB failing is normally the root cause of this type of problem: Understanding message XCOMN0288E or XCOMU0288E
However in this case no pre/post-processing script has been customised apart from xcomlp.bat which is only used for a SEND REPORT transfer which is not being used in this scenario.
From the spreadsheet:
1. The "XCOMN0288E System function failed, RC=0" Transfer Number=161153 (RECEIVEFILE) spent 34 seconds before failure i.e. START=22290073009, END=22290073043
2. The previous Transfer Number=161152 (RECEIVEFILE) started at the same time as Transfer Number=161153 and although it was successful, it spent 33 seconds to transfer an empty file ("XCOMN0011I Transfer ended; 0 records (0 bytes) transmitted in 33 seconds (0 bytes/second)") i.e. START=22290073009, END=22290073042. That time delay to transfer 0 bytes would indicate a potential issue in either network or system resources.
XCOM Engineering were able to recreate "XCOMN0288E System function failed, RC=0" by adding a "pause" statement at the end of the xcompp.bat post-processing script and killing the cmd process that runs it from task manager. NOTE: The xcompp.bat gets executed on incoming transfers (RECEIVEFILE).
Therefore XCOM Engineering believe there maybe a transient resource problem which is causing the exit processing process to sometimes be killed or crash. That would also explain the very infrequent problem occurrence.
To prevent the error recurring, as we know that no pre/post-processing script apart from xcomlp.bat has been changed, the suggestion is to edit the xcom.glb file and set all CMD parameters to have no value apart from XLPCMD i.e.
CURRENT CMD PARAMETERS:
===
XENDCMD=%XCOM_HOME%\Xcomend.bat
XPRECMD=
XLPCMD=%XCOM_HOME%\Xcomlp.bat
XNOTIFYCMD=%XCOM_HOME%\xcomntfy.bat
XPPCMD=%XCOM_HOME%\xcompp.bat
===
PROPOSED CMD PARAMETERS:
===
XENDCMD=
XPRECMD=
XLPCMD=%XCOM_HOME%\Xcomlp.bat
XNOTIFYCMD=
XPPCMD=
===
NOTE: After the above changes to the xcom.glb file the XCOM for Windows service needs to be restarted to pick up those changes.
Additional Information
There is potentially another solution which is to modify the "%XCOM_HOME%\config\xcom.ses" file to have parallel sessions set for the remote system name in question instead of the default single session: Set Session Control Parameters
Feedback
