XCOM "expecting a valid name" for xcom.glb when send file

Products

• XCOM Data Transport
• XCOM Data Transport - Windows

Issue/Introduction

Currently, receiving incoming XCOM transfers to Windows from AS/400 successfully, but facing an issue while sending files from Windows to AS/400. 
Seeing below errors:

"ERROR:  In C:\Program Files\CA\XCOM\config\xcom.glb, expecting a valid name, but found 'LOG_CONNECT_MSG'"
...
"XCOMN0473E Errors parsing xcom.glb;  The XCOMD Advantage CA-XCOM Scheduler Service cannot start."

Resolution

The messages "expecting a valid name, but found" and "XCOMN0473E Errors parsing xcom.glb ..." normally indicate:
EITHER: The file "C:\Program Files\CA\XCOM\config\xcom.glb" has some syntax errors or has become corrupt because it has been saved in an incorrect encoding after editing.
OR: The XCOM transfer ID file "C:\Program Files\CA\XCOM\config\xcom.tid" has become corrupt.
i.e. Error 473 starting XCOMD Scheduler Service and XCOMN0473E

However in this case the fact that the message shows "The XCOMD Advantage CA-XCOM Scheduler Service cannot start" is strange because the name "Advantage CA-XCOM" is from XCOM version r3.1 which is a very old release.

It seems there could be multiple versions of XCOM on the same machine because another directory "C:\Xcomnt\Config" was found and the file "C:\Program Files\CA\XCOM\config\xcom.glb" was copied into it.
However:
The XCOM_HOME environment variable is pointing to the correct directory  "C:\Program Files\CA\XCOM\".
Commands "xcomtcp -r" and "xcomqm -r" generate the expected version messages i.e. 
xcomtcp: CA XCOM Data Transport r11.6 22022 SP03 64bit for Windows Family (TCP/IP)
xcomqm: CA XCOM Data Transport r11.6 22022 SP03 64bit for Windows Family (CPIC & TCP/IP)

As incoming transfers are working it implies that the xcomd Windows service is started with the correct environment, but perhaps the locally initiated xcomtcp command is setting or picking up an incorrect environment via a transfer script or via the environment variables of the userid running the script.

Some changes were made to the transfer script which resolved the problem - the exact change details were not provided.