"XCOMN0288E System function failed, RC=1314" executing CA XCOM post-processing scripts
search cancel

"XCOMN0288E System function failed, RC=1314" executing CA XCOM post-processing scripts


Article ID: 217906


Updated On:


XCOM Data Transport XCOM Data Transport - Windows


Recently migrated working CA XCOM for Windows r11.6 SP03 UAT server environment to the Production server.
For a file transfer from z/OS to Windows, the transfer is successful, but this RC error is being returned from the execution of 2 customised post-processing scripts xcompp.bat and xcomend.bat:

XCOMN0288E System function failed, RC=1314

This error does not occur on the UAT server.


Release : 11.6

Component : CA XCOM Data Transport for Windows


From Windows > Apps > Win32 > Desktop Technologies > Diagnostics > Debugging and Error Handling > Error Handling > System Error Codes (1300-1699)

RC=1314 indicates:

1314 (0x522)

A required privilege is not held by the client.


After setting XTRACE=10 in file xcom.glb file and restarting the XCOM service, the resulting *.TRA file showed the RC=1314 error when trying to create a process (CreateProcessAsUser) for the transfer userid being used to run the post-processing scripts xcompp.bat and xcomend.bat:
 ntsuid    537: NT_ProcessCmd: CA-XCOM-Batch Desktop found.
 ntsuid    945: In RemoveSid
 ntsuid    949: RemoveSid: SID buffer free OK
 ntsuid    548: calling CreateProcessAsUser; token: 436
 ntsuid    563: NT_ProcessCmd: CreateProcessAsUser failed rc=1314
 ntsuid    641: NT_ProcessCmd: About to remove ACE from windowstation,desktop
 ntsuid    654: NT_ProcessCmd: RemoveTheAceWindowStation OK.
 ntsuid    668: NT_ProcessCmd: RemoveTheAceDesktop OK.
Per the trace, the "CA-XCOM-Batch-Interactive" group exists and is being found and the transfer userid also belongs to it.
NOTE: The "CA-XCOM-Batch-Interactive" group just prevents the system from eventually running out of ACEs if XCOM continuously adds entries and enables ACE reuse once added, so it should not be relevant to this error.

The RC=1314 problem is only expected to occur if the XCOM service "Log on as" user has been changed from the default of  "Local System account".
If the XCOM service has "Log on as" set to a different user then that user has to have Admin rights (belong to the Administrator group) because the XCOM service starts programs running under another (transfer) userid. Of course the XCOM service user also needs to have User Right "Log on as a service" to be able to start the service.
Although most of the following user rights are implicit for a user with Admin rights, after testing on Windows Server 2019 XCOM Engineering advises that all these permissions are required to be set for the XCOM service user in the Local Security Policy (Local Policies > User Rights Assignment):
Act as part of the operating system
Adjust memory quotas for a process
Allow log on locally
Create a token object

Log on as a batch job
Log on as a service
Replace a process level token

In addition to the above if "Increase quotas" exists as a user right it also needs to be added - it does not exist under Windows Server 2019, but may exist under earlier versions.
"Replace a process level token" is specifically required to send jobs to Windows or run XCOM pre-processing or post-processing exits

For this particular scenario it was found that after comparing the XCOM service user permissions on the working UAT server to the Production server, it was found that "Log on as a batch job" was missing from the Production server.

Additional Information

1. The userid being used for the transfer needs only "Allow log on locally" user rights.

2. Related articles/documentation:
What do CA XCOM messages XCOMN0288E/XCOMU0288E indicate - was the transfer successful?
CA XCOM Data Transport for Windows 11.6 Service Packs > Administrating > Operating Environment > The XCOMD CA XCOM Scheduler Service
CA XCOM Data Transport for Windows 11.6 Service Packs > Administrating > How to Configure CA XCOM Data Transport > Create the CA XCOM Batch Interactive Group