We have written our own MQ CICS listener (Cobol pgm). This listener is a long running task that "gets" (non destructive) a message with a browse-first and continues to browse-next until the queue is empty and starts back at the beginning. It then dispatches to the real application by starting a CICS transaction that does the "get" desturctive. Our application is so fast that it starts back at the beginning and thinks it has a new message. How Can we differentiate that it is a not a new message, that the secondary application still has not "gotten" the message. We do have an internal ECB table that is passed to the 2nd program that "posts" when the message is retreived but it never gets to post on time.
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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How to diffenriciate 2 msgs with the same msg-id and correl-id? 1
- Thread starter fredmath
- Start date
-
1
- #2
fredmath
Why do you feel it is necessary to continually loop back to the beginning again? EXEC CICS START is pretty reliable, so there is no reason to assume that the started transaction will fail to execute normally, and remove the message from the queue. If your listener uses the wait option on the browse, it won't get a response from the get next until a new message arrives, or the system is quiesced. If you are really worried about missing messages, set a 30 second timeout on the wait, and only loop back to the beginning when your get next times out. This should give you plenty of time for your started transactions to finish and post your ECB table.
Also (design note here) using what amounts to shared memory (your ECB table) imposes restrictions on processing should you need to go for a multi-region configuration at at later date.
Why do you feel it is necessary to continually loop back to the beginning again? EXEC CICS START is pretty reliable, so there is no reason to assume that the started transaction will fail to execute normally, and remove the message from the queue. If your listener uses the wait option on the browse, it won't get a response from the get next until a new message arrives, or the system is quiesced. If you are really worried about missing messages, set a 30 second timeout on the wait, and only loop back to the beginning when your get next times out. This should give you plenty of time for your started transactions to finish and post your ECB table.
Also (design note here) using what amounts to shared memory (your ECB table) imposes restrictions on processing should you need to go for a multi-region configuration at at later date.
- Thread starter
- #3
stevexff
Thank you, for your reply, really good.
Only one concern, if I'm not going back at the begining of the Queue (Browse First)and I have a message that is rollback by started transaction, am I gonna be able to get it back with the Browse Next?
Is there any potential problem of not going back at the top with a Browse First?
Thank you.
Thank you, for your reply, really good.
Only one concern, if I'm not going back at the begining of the Queue (Browse First)and I have a message that is rollback by started transaction, am I gonna be able to get it back with the Browse Next?
Is there any potential problem of not going back at the top with a Browse First?
Thank you.
fredmath
Why is your transaction going to roll back here? If it does, do you really want to try it again? What are you doing that isn't going to work first time? Is it likely to be a transient problem, i.e. if you retry it, what's the chance it won't fail with the same thing over (and over) again?
That's why I suggested a 30-second timeout on the BROWSE NEXT. If it times out, you can always reset the browse with a BROWSE FIRST. If it doesn't time out, then just keep going...
Why is your transaction going to roll back here? If it does, do you really want to try it again? What are you doing that isn't going to work first time? Is it likely to be a transient problem, i.e. if you retry it, what's the chance it won't fail with the same thing over (and over) again?
That's why I suggested a 30-second timeout on the BROWSE NEXT. If it times out, you can always reset the browse with a BROWSE FIRST. If it doesn't time out, then just keep going...
- Thread starter
- #5
Hi Stevexff
I want to retry because the main application may be temporarily unavailable to to non-related MQ problems and we do not want to penalize MQ customers that send persistant messages. The problem is not necessarily with the MQ message.
I want to retry because the main application may be temporarily unavailable to to non-related MQ problems and we do not want to penalize MQ customers that send persistant messages. The problem is not necessarily with the MQ message.
Ok, seems reasonable.
1. BROWSE FIRST
2. BROWSE NEXT, with 30-sec timeout
3. if RC = OK, start transaction, loop back to 2
4. if not, if a timeout has occurred, go back to 1
This scheme allows your transaction to listen on the queue for up to 30 seconds to see if any new messages arrive. When things get slow, it times out and loops back to the top of the queue, retrying any that haven't processed for any reason.
1. BROWSE FIRST
2. BROWSE NEXT, with 30-sec timeout
3. if RC = OK, start transaction, loop back to 2
4. if not, if a timeout has occurred, go back to 1
This scheme allows your transaction to listen on the queue for up to 30 seconds to see if any new messages arrive. When things get slow, it times out and loops back to the top of the queue, retrying any that haven't processed for any reason.
- Status
Similar threads
- Locked
- Question