I have a program that does a WRITEQ to a TDQ, trigger level=1. When the trigger is reached a second transaction is started and its program does a READQ. The READQ returns a QZERO condition as if the Queue is empty but it's not. When I CEBR the TDQ it has records in it which continue to stack up because the READQ has not been performed to delete them from the Queue.Both the Queue and programs run in the same CICS regions so what do you think could cause a READQ to return a QZERO condition on a TDQ that has data in it? I'm stumped.
I wonder if you have got a bit of a complication due to the nature of the CICS UnitOfWork processing. You will get the empty Q condition if the putter's UoW is still active when you try to read the TDQ. I suggest just putting in a short wait in the reader transaction to cope with this situation. So if you get an empty Q issue a 1s wait (say, up to 5 goes) before re-reading the TDQ after each wait.
CICS Technical Strategist -- CICS expert at Search390.com
Editor's note: Do you agree with this expert's response? If you have more to share, post it in one of our .VO7aaqqaAFk.0@/search390>discussion forums.
Dig Deeper on IBM system z and mainframe systems
Related Q&A from Robert Crawford
For better mainframe capacity planning, how do I convert CPU hours to MIPS? And is there a way to calculate the relationship between MIPS and MSUs? Continue Reading
I have two years of experience in mainframe technology, currently working as a mainframe developer. I want to change to Java technology. Continue Reading
I want to replicate DB2 from the mainframe to an AIX box since it's cheaper and the copy can be used for testing. Is this possible? Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.