Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
CICS programming 1
- Thread starter dosscics
- Start date
- Thread starter
- #2
I have a tdq set up and running. Program 1 writes to the queue. Program 2 is set up to read the queue with a trigger of 1. It updates an online file and writes to another vsam file. My problem is that the queue backs up. During testing Program 1 creates 2 tdq entries back to back. Program 2 pops the first entry but not the second. If Program 1 creates another queue record (#3) program 2 pops out record #2. The cics manual refers to QZERO as a solution. I tried checking the READQ response for QZERO and ending Program 2, but I'm not sure how to loop back to read the next queue record. When I try to loop back I get an AICA runaway abend. Thanks for any help
-
1
- #3
QZERO means that there are no more items on the TDQ, so on receipt of such a response, program 2 should end.
Could the problem be that program 1 is not issuing a SYNCPOINT after writing an item to the tdq ? If this is the case, then any new items on the TDQ will not be available to program 2 until a SYNCPOINT is done (or program 1 ends)
Could the problem be that program 1 is not issuing a SYNCPOINT after writing an item to the tdq ? If this is the case, then any new items on the TDQ will not be available to program 2 until a SYNCPOINT is done (or program 1 ends)
- Thread starter
- #4
- Thread starter
- #5
Afjt, I have the queue popping all of the records now, after using qzero correctly. But program 2 does wait until program 1 goes to eoj before starting to read the queue. I don't see in the documentation (IBM CICS Programming Reference manual) where you use SYNCPOINT when writing to a transient data queue. I'm not linking program 1 to 2 I'm justing writing to the queue. Do you have any thoughts on how to commit these queue records? Thanks for the help. Larry
TDQ items only get committed when you do a SYNCPOINT, or when the task ends. From what you are describing, the commit is taking place when program 1 ends, and thus program 2 gets triggered, as only now is the item on the tdq. If you wish the item to be committed earlier than this, then put in a SYNCPOINT, but bear in mind that this will also commit anything else which is still held (including ending any BROWSE of a vsam file, if this is what you use). In other words, put the SYNCPOINT at the end of the logical-unit-of-work, otherwise you may end up with inconsistent data should you subsequently abend.
TDQ trigger gotcha #1
A TDQ-triggered task only gets initiated when the TDQ passes its trigger threshold, in this case 1. So if your triggered task doesn't read the queue down to zero every time it runs, it won't ever get triggered again because the queue is past its threshold.
As these things normally run in the background, you won't necessarily notice until DFHINTRA is full up, by which time it's usually too late. Consider having some kind of monitoring that alerts someone if task 2 abends before it gets the queue down to zero.
Steve
A TDQ-triggered task only gets initiated when the TDQ passes its trigger threshold, in this case 1. So if your triggered task doesn't read the queue down to zero every time it runs, it won't ever get triggered again because the queue is past its threshold.
As these things normally run in the background, you won't necessarily notice until DFHINTRA is full up, by which time it's usually too late. Consider having some kind of monitoring that alerts someone if task 2 abends before it gets the queue down to zero.
Steve
- Status
Similar threads
- Locked
- Question