XCOMU0602E Unable to QUEUE: Cannot Create Data File or Queue is Full

Document ID : KB000009380
Last Modified Date : 14/02/2018
Show Technical Document Details
Introduction:

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

Background:

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.

Instructions:

To resolve XCOMU0602E Unable to QUEUE: Cannot Create Data File or Queue is Full messages:

  1. Although this is not the most likely cause, check the xcom.tid file.  Check this first because it is the easiest and quickest thing to check and correct. The xcom.tid file should have the next TID number. The number should be in a 6-digit format. If it is 0 or blank or not a number, delete the current xcom.tid file. (You may also put the next 6 digit transfer id number.) Stop and start xcomd.
  2. If the TID file looks fine, increase the value for the parameter MAX_QUEUE_ENTRIES and/or decrease the value for EXPIRATION_TIME in the XCOM.GLB. Stop and start XCOMD to reload the new parameter values.

What value should I set for 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, CA XCOM deletes the queue entry and any associated trace files.

You may clear the queue manually by typing xcomqm -R* on the command line. Any transfers waiting to start will need to be resubmitted if you do this.

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 CA XCOM.

What value should I set 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 XCOMTOOL 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? This can happen if your EXPIRATION_TIME is high, multiple local transfers are initiated and CA XCOM for UNIX OR LINUX is receiving multiple transfers from one 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 are queued, 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 xcomd stopping, one cause can be a lack of resources or memory. Lack of resources can cause xcomd to time out. The value for MAX_QUEUE_ENTRIES correlates to how much shared memory CA XCOM expects to access. If while in the process of managing many transfers, a memory intense application starts, than CA XCOM may not have enough memory to continue.

What else could this message indicate

  •  Another cause could be the queue still being full. Delete any completed transfers from the queue and stop and start xcomd. If the problem persists, then you will need to clear all of the transfers from the queue, xcomqm -R*, and then delete the 000026.idx file, and recycle xcomd again. The 000026.idx file is an index file used internally by CA XCOM for queue maintenance.
  • 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. To resolve this, increase the value for the parameter MAX_QUEUE_ENTRIES and/or decrease the value for EXPIRATION_TIME in the XCOM.GLB. Stop and start XCOMD to reload the new parameter values.