| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Triggered CICS transaction timeout issue |
« View previous topic :: View next topic » |
| Author |
Message
|
| Allan Mackay |
 Posted: Fri Jul 09, 2010 5:08 am Post subject: MQ Triggered CICS transaction timeout issue |
 |
|
Apprentice
Joined: 08 Jul 2010
Posts: 29
|
Hi,
Not sure if this is the right forum for this query but here goes...
The scenario: A batch job puts a message onto QueueA and then waits (for up to 60 seconds) for a reply on QueueB. QueueA triggers a CICS transaction (we'll call it XXXX). XXXX reads QueueA, in a loop (the exit from the loop being no more messages available). For each message received, XXXX will send a reply on QueueB. The get, that XXXX performs, has a 15 second wait...
Ok, on first use, what we're observing is that batch job does its put on QueueA, but XXXX takes a few seconds to respond (not 15, I hasten to add). However, no reply message is ever placed on QueueB and, eventually, the batch job gives up waiting. It's almost as if CICS' get on QueueA is timing out (although the message does eventually get consumed, somehow).
On subsequent uses, XXXX will receive a message as soon as it's been put on QueueA by the batch job and sends a reply instantly on QueueB which the batch job receives.
I thought this may be to do with commits and/or queue sharing so we're making sure that when the batch job puts a message on QueueA, it is committed before the batch job waits for a reply. QueueA and QueueB have both been made shareable. But still we have a first use delay and loss of message with everything subsequent to that working.
I should add that the "first use" scenario occurs after a significant period of non-activity (an hour or so) whereas the "success" scenarios can be seconds (more than 15, I hasten to add), even minutes, after the "first use" scenario.
It's like something goes to sleep after a period. Perhaps the CICS connection to the queue manager? Perhaps the CICS trigger monitor? Does anyone have any ideas on what I should look at?
Many thanks, in advance 
-Al. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Jul 09, 2010 5:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| it is committed before the batch job waits for a reply. |
This is the correct forum.
In order for a message to be consumed (and a reply returned), the message first must have been committed by the putting application. The triggering process also depends on the message being committed before the trigger will fire.
Since you didn't specify, I'm guessing that this is a new application. Yes?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Allan Mackay |
| Posted: Fri Jul 09, 2010 5:42 am Post subject: |
|
|
Apprentice
Joined: 08 Jul 2010
Posts: 29
|
No, this isn't a new application. It's an existing application that has come under scrutiny recently, which has brought this behaviour to light.
Admittedly, the batch side wasn't committing and I thought this might be the cause (although I couldn't explain why subsequent uses worked correctly). On my advice, the developer involved has added the commits but still no dice, we see no change in the behaviour. Most strange  |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Fri Jul 09, 2010 5:44 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
after it failed on the first time, and before it works on the second time, are the related queues all empty?
what must happen that a "subsequent time" becomes the "first time" agin? Cics restart? Mq restart? nn hours?
will the tx go back to sleep or will it stay alive? are the IPPROC and OPPROC for all queues = 0 after the failing fist time?
If batch job puts msg2, maybe he receives reply for msg1 (if queues are not empty). have you checked that? how do you make sure if you put msg2, you will exactpy get a reply for msg2, and for no other message?
edditing.... just read your post
you put mag1 and trigger but you do not commint, so cics tx fails and your batchjob times out
you put msg2 and trigger and cics tx reads msg1 and replies, and you read reply 1 and end
and so on ... ?!?
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Allan Mackay |
| Posted: Fri Jul 09, 2010 5:55 am Post subject: |
|
|
Apprentice
Joined: 08 Jul 2010
Posts: 29
|
| Mr Butcher wrote: |
| after it failed on the first time, and before it works on the second time, are the related queues all empty? |
Yep, both are empty
| Mr Butcher wrote: |
| what must happen that a "subsequent time" becomes the "first time" agin? Cics restart? Mq restart? nn hours? |
It seems to be time related - after an hour or so. A CICS restart does cause the same thing but that could be related to time still 
| Mr Butcher wrote: |
| will the tx go back to sleep or will it stay alive? are the IPPROC and OPPROC for all queues = 0 after the failing fist time? |
The transaction shuts down 15 seconds after the last message has been read from the queue (i.e. it trys to stay alive as long as there is data to process but if no messages arrive for a period of 15 seconds, the transaction stops until triggered again). The IPROC for both queues is 2 for the duration of the CICS transaction (15 seconds) and revert to 1 whilst the batch job is still active (60 seconds if no reply received).
| Mr Butcher wrote: |
| If batch job puts msg2, maybe he receives reply for msg1 (if queues are not empty). have you checked that? how do you make sure if you put msg2, you will exactpy get a reply for msg2, and for no other message? |
CorrelId is used to ensure the batch job is only waiting for a reply to a message it sent.
| Mr Butcher wrote: |
edditing.... just read your post
you put mag1 and trigger but you do not commint, so cics tx fails and your batchjob times out
you put msg2 and trigger and cics tx reads msg1 and replies, and you read reply 1 and end
and so on ... ?!? |
We are committing now And CorrelId will ensure that only the relevant reply will be accepted. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 09, 2010 5:59 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The scenario: A batch job puts a message onto QueueA and then waits (for up to 60 seconds) for a reply on QueueB. QueueA triggers a CICS transaction (we'll call it XXXX). XXXX reads QueueA, in a loop (the exit from the loop being no more messages available). |
Does the batch job really put one message at a time to QueueA, then wait 60 seconds for the one reply? Or does it (can it) put multiple messages to QueueA, then wait for replies (plural)?
The usual request-reply scenario is (for the requesting app - batch job): put to request queue (QueueA), commit the request message, do a get/wait on the reply-to-queue.
| Quote: |
| For each message received, XXXX will send a reply on QueueB. The get, that XXXX performs, has a 15 second wait... |
Does the cics transaction have MQI calls in it? That is, it the cics transaction MQ-aware?
Does the cics transaction definition specify INDOUBT(BACKOUT) or INDOUBT(COMMIT)?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Fri Jul 09, 2010 6:04 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
queue a should have ipprocs 1 (ciss) and opprocs 1 (batch)
queue b for the reply should have ipprocs 1 (batch job) and opprocs 1 (cics).
which queue has ipprocs 2? queue a? remember, if a queue is already openend for input no trigger message is created when a message is put (trigger first).
_________________
Regards, Butcher |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 09, 2010 12:11 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Also remember to check the behavior of the trigger and queue depth while the first batch is not yet committed. Timing is from the first put to the first commit.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jul 09, 2010 1:49 pm Post subject: Re: MQ Triggered CICS transaction timeout issue |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Allan Mackay wrote: |
Ok, on first use, what we're observing is that batch job does its put on QueueA, but XXXX takes a few seconds to respond (not 15, I hasten to add). |
Maybe XXXX takes that long to initialize itself. Establishing database connections, etc.
| Allan Mackay wrote: |
It's almost as if CICS' get on QueueA is timing out (although the message does eventually get consumed, somehow). |
Maybe the message expires if XXXX takes too long, and that's how it got "consumed". What expiry value does the batch job assign these messages?
| Allan Mackay wrote: |
The IPROC for both queues is 2 for the duration of the CICS transaction (15 seconds) and revert to 1 whilst the batch job is still active (60 seconds if no reply received).
|
That ain't right. Why is the Batch job opening the queue for Input if all its doing is a put (Output). If the batch job is in fact that 2nd IPROCS - maybe not and its just a coincidence. If there are things opening QueueA for Input other than the triggered app, then the trigger conditions are being interfered with and you can expect funky results.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gouda |
| Posted: Mon Jul 12, 2010 11:13 pm Post subject: |
|
|
Apprentice
Joined: 20 May 2001
Posts: 32
Location: Germany, Nuremburg
|
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Jul 13, 2010 1:04 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
before going for tools and other stuff (time consuming) i suggest the first thing he should make sure is, that the only consumer of queue"A" is the cics transaction. nobody else should open that queue for input. maybe thats all needed to solve the triggering issue.......
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Allan Mackay |
| Posted: Tue Jul 20, 2010 1:31 am Post subject: |
|
|
Apprentice
Joined: 08 Jul 2010
Posts: 29
|
Sorry I haven't been back in touch about this issue. It got dropped in priority but I thought I'd just quickly pop back and let you all know I'm not ignoring you and all that
I've taken onboard all your suggestions and I will be, soon, checking everything out and will return with my findings and, hopefully, a clear picture. Thank you all for your help so far
-Al. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
