XCOMN0493E/XCOMU0493E "cannot generate internal transaction id"
search cancel

XCOMN0493E/XCOMU0493E "cannot generate internal transaction id"

book

Article ID: 28326

calendar_today

Updated On:

Products

XCOM Data Transport XCOM Data Transport - Windows XCOM Data Transport - Linux PC XCOM Data Transport - z/OS

Issue/Introduction

What does the error message XCOMN0493E or XCOMU0493E "cannot generate an internal transaction id" mean?

XCOMN0493E
XCOMU0493E

Environment

Release: 11.6
Component: XCOM Data Transport for AIX

Cause

This message generally means that the queue is full for XCOM for Windows or Linux or UNIX.

Resolution

To resolve this, increase the value for the parameter MAX_QUEUE_ENTRIES and/or decrease the value for EXPIRATION_TIME in the xcom.glb . Recycle xcomd to pick up the new parameter values.

Associated Error Codes: XCOMN0493E XCOMN0602E

Additional Information

Related article with more details about possible root causes and resolutions (queue cleanup or corrupt xcom.tid file): XCOMN0493E Cannot generate internal transaction id

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?

The value supplied can not exceed n, where n is the 'maximum shared memory segment divided by 512'. So this value is limited by the amount of shared memory that is available. The other consideration for this value is the total number of transfers that will be processed through this queue, especially locally initiated transfers within a given time. As the number of transfers in the queue increases so does the amount of memory used by XCOM. As the transfers are deleted from the queue the memory becomes available again. EXPIRATION_TIME is another parameter that will affect the value for MAX_QUEUE_ENTRIES.

What value should be chosen for EXPIRATION_TIME?

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. The primary 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. 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 this value 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.
You may need to clear out the queue - xcomqm --R* .

Why would I suddenly receive this error code?

If your EXPIRATION_TIME is high, multiple local transfers are initiated and Advantage CA-XCOM Data Transport for UNIX is receiving multiple transfers from 1 or many partners. Remember if EXPIRATION_TIME is high, transfers that have completed and you may be ignoring, 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 other related conditions can occur?

While there are other reasons for daemon stopping, one cause can be a lack of resources, memory. Lack of resource can cause the daemon to time out. The value for MAX_QUEUE_ENTRIES correlates to how much shared memory XCOM expects to access. If while in the process of managing many transfers a memory intense application starts XCOM may not have enough memory to continue.

What else could this message indicate?

If adjusting MAX_QUEUE_ENTRIES and EXPIRATION_TIME does not resolve the problem, then the queue may be corrupted. The xcom.tid file should have the next TID number. The number should be in a 6-digit format. Deleting the current xcom.tid file may resolve the problem. Another cause could be the queue being full. Delete any completed transfers from the queue and recycle the daemon. If the problem persists, then you will need to clear all of the transfers from the queue, xcomqm -R*, and then delete the Q file, and recycle xcomd again, xcomd -cy. The 000025.idx file is an index file contained within the Q file used internally by XCOM for queue maintenance. A table explaining options for xcomd and the xcomqm commands can be found in Chapter 2 of the User Guide. The User Guide is available at https://techdocs.broadcom.com/.
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.
This problem may also be caused by the user not having authority to the directory where Advantage CA-XCOM Data Transport for UNIX is installed.