XCOMN0493E Cannot generate internal transaction id
Article ID: 28294
Updated On:
Products
Issue/Introduction
Getting Message "#XCOMN0493E Cannot generate internal transaction id" when sending file to XCOM for Windows partner.
NOTE - # indicates a retryable transfer.
Environment
Release: 11.6, 12.0
Component: XCOM Data Transport for Windows
Cause
The XCOMN* error prefix indicates that the problem is occurring on the remote XCOM for Windows partner side.
This message can have more than one cause. The two most common ones are:
1) The transfer id number file (xcom.tid) on the remote partner may be corrupted.
2) The queue is full for XCOM for Windows.
XCOMN0493E
Resolution
1) The xcom.tid file may be corrupted.
- The xcom.tid file can be found in the Config subdirectory "%XCOM_HOME%\Config" i.e. by default "C:\Program Files\CA\XCOM\Config".
- It should contain the next transfer id number. The number should be in a 6-digit format. If it is not, delete the xcom.tid file and restart xcomd. XCOM will create a new xcom.tid file.
Alternatively, examine the xcom.log and determine what the next transfer id should be and edit the file with notepad and type that number into the file and save. Restart xcomd.
2) Otherwise, the queue on XCOM for Windows is full.
- As an emergency measure, clear the queue manually by typing xcomqm -R* at the command prompt. WARNING: If this is done any transfers waiting to start will need to be resubmitted.
- To resolve: Increase MAX_QUEUE_ENTRIES and/or decrease EXPIRATION_TIME in the xcom.glb file and restart xcomd. The xcom.glb file can be found in the Config subdirectory "%XCOM_HOME%\Config".
The values set for the EXPIRATION_TIME and MAX_QUEUE_ENTRIES xcom.glb parameters depend on the maximum number of transfers that could be present in the queue at any one given time. NOTE: Transfers are not removed from the queue until the time specified in the EXPIRATION_TIME parameter passes.
For example, if there are 100 transfers at 6 pm and another 100 ten minutes later an EXPIRATION_TIME larger than 600 (10 Minutes) will require you to have a parameter setting of at least MAX_QUEUE_ENTRIES=200.
Or if the EXPIRATION_TIME is set to less than 600 (10 Minutes) then the Queue size will be sufficient. It is a balance between both parameters and your workload.
Resolution: Increase MAX_QUEUE_ENTRIES and/or decrease EXPIRATION_TIME. This allows more transfers to be stored and processed in the Queue at any point in time.
3) If a transfer is retryable (its parameter NUMBER_OF_RETRIES has been set to > 1 or it is a retryable error on a remotely initiated transfer) and fails then its Queue entry will not be cleared by EXPIRATION_TIME, but instead by AGE_TIME which defaults to 5 days, so that fact also has to be taken into account to avoid the queue becoming full.
Additional Information
Manage the XCOM Data Transport for Windows Queue
NOTE: It is also possible that manually deleting the .MBR files from the queue subdirectory "%XCOM_HOME%\q" will resolve the problem. To do that file deletion the xcomd service must first be stopped and then restarted after the deletion.
What is the purpose of the queue? The queue is designed to keep track of all incoming and outgoing transfers. Each transfer in the queue requires 512 bytes of shared memory. Each transfer is supplied a unique TID, or Transaction Identifier. All trace information associated with a transfer is identified by the TID and is available for the length of time that the transfer is in the queue. A brief history of every transfer is also written in the log.
What value should be used for the parameter MAX_QUEUE_ENTRIES? This value is the maximum number of transfers that will be need to be held in the queue. This is not the maximum number of concurrent transfers, because transfers are held in the queue after they complete (either successfully or unsuccessfully) until EXPIRATION_TIME passes. At this point, XCOM deletes the queue entry and any associated trace files.
Allow extra entries to account for times when a partner may be down and transfers are held in the queue waiting for the partner to become available again. Also the number of transfers does tend to increase over time, so this number should be reviewed on a regular basis. The value supplied can not exceed n, where n is the maximum shared memory segment divided by 512. This value is limited by the amount of shared memory that is available. As the number of transfers in the queue increases so does the amount of memory used by XCOM.
What value should be chosen for EXPIRATION_TIME? EXPIRATION_TIME is specified in seconds. Since this value represents the maximum time that the transfer will be held in the queue after execution, you need to consider why you need to retain a transfer after it is finished. One reason for retaining a TID is to access the associated trace information. There is also detailed information regarding each specific transfer accessible through the GUI and the XCOMQAPI. If most of your transfers are handled automatically or at off-peak hours then this information may be extraneous because each transfer will have information regarding its status recorded in the log.
It is also important to realize that as this value is reduced the associated TID's become free and therefore the same number of entries can handle more transfers. This is particularly true if EXPIRATION_TIME is reduced drastically and the transfers are sent in a steady continuous pattern. Reducing the EXPIRATION_TIME may be necessary if you need to dramatically increase the value of MAX_QUEUE_ENTRIES. If you do not need to access information about completed transfers in the queue, you may set EXPIRATION_TIME as low as 1, raising it temporarily if you need to troubleshoot. The transfer information will still be available in the xcom.log.
Why would I suddenly receive this error code? If your EXPIRATION_TIME is high, multiple local transfers are initiated and XCOM for Windows is receiving multiple transfers from 1 or many partners. Remember if EXPIRATION_TIME is high, transfers that have completed are still reserving TID's . If enough TID's are reserved at the time the new transfers hit the queue then you may see this error condition. Another possibility would be multiple partners sending multiple transfers at the same time. This can occur if a partner system has been down for some time and now is sending an inordinate amount of transfers while it completes its backlog of work.
What else could this message indicate? Another possible cause for this error condition would be a remote system being down. If the partner system can not process any of the transfer requests, this could cause the queue to reach capacity prematurely. Check the value for Remote System Name on the pending transfers. A single partner or group of partners may not be accessible due to network conditions.
Please contact Broadcom Support if you need assistance in resolving this problem.
Feedback
