IBM Mainframe Forum

There are a few programs that write data into a TDQ and some programs read from it. TDQ locking occurs frequently in production environment. To avoid this, there are two approaches being discussed. One is to use ENQ/DEQ (right now programs does not use ENQ/DEQ) and other is to move writeQ to end of the processing. I'm not well-versed in CICS, so could not decide on which one to implement. Which one is better and what are the advantages in each of them? I appreciate any suggestions on other approaches as well.

Thanks,
LML

How will moving the WRITEQ TD to the end of processing help? You could STILL have locking issues because the read and write operations for a TD queue are independent.

I think I have not explained it clearly earlier. READ and WRITE are not in the same program. Programs A,B,C performs WRITE operations on the queue and Programs D,E,F consume data written into the queue.
Program A,B, C follow this structure
- perform some db operation
- perform WRITE into queue
- Perform some db operation (not related to QUEUE)
- terminate

As per my understanding, program holds lock on the queue during WRITE operation and the lock will not be released until that task terminates. Since we perform some db operation(independent of WRITEQ) between 'WRITEQ' & termination, it will unneccessarily hold lock on the queue. So if we could move WRITEQ operation just before the termination then locking time would go down a bit and this might minimize the locking time than compared to the current design.
On the other hand, if we use ENQ/DEQ immediately before/after WRITEQ, then the task will acquire and release lock explicitly which helps in minimizing the time for which the lock is held.
Correct me if I'm wrong.

I guess the final answer to your question depends upon what your goal is. If you want to end production TDQ locking, you will implement ENQ/DEQ for the programs involved. If you want to reduce the number of occurrences of production TDQ locking (but NOT eliminate them all), then you will move the WRITE TDQ to the end of the processing.

The advantages of ENQ/DEQ is that, properly implemented, there will be no TDQ locking. The trade-off is that you are serializing on a resource so that means you lose a certain amount of parallelism (which you probably are already losing without knowing it) and possibly forcing transactions to take longer.

The advantages of moving the WRITEQ TD are that you minimize the amount of time that TDQ locking could occur and possibly reduced coding effort. The trade-off is that you will not get rid of all TDQ locks since reducing the time a lock could occur does not mean that time is now zero.

These users thanked the author Robert Sample for the post:

letmelive (Sat May 11, 2013 12:32 am)

I have a couple of questions here
1) I understand that using ENQ/DEQ would make the task to wait until the resource is available. In other words the task is suspended until the resource becomes available and hence transaction will take longer time. But what will happen to the task if it does not use ENQ/DEQ on a resource?
i) If two or more tasks trying to write into a TD queue at the same time (when ENQ/DEQ is not used)what will happen?
ii) If task A writes into queue Q and at the same time task B wants to write into queue Q, won't task B gets suspended/wait until the transaction associated with task A is completed?

From IBM manual

The resource to be enqueued on must be identified by one of the following methods:
Specifying a data area that is the resource. It is the location (address) of the data area in storage that matters, not its contents.
Specifying a data area that contains a unique argument (for example, an employee name) that represents the resource. It is the contents of the data value that matters, not its location. LENGTH is required; the presence of the LENGTH option tells CICS to enqueue on the contents of the data value.

2) I believe, in my case I need to use ENQ on data-area and not the content.
If I give " ENQ RESOURCE (queue-name)" , will it serve the purpose?

Thanks,
LML