Author |
Message
|
XK4 |
Posted: Wed Jul 28, 2010 8:41 am Post subject: message is left on the queue |
|
|
Newbie
Joined: 28 Jul 2010 Posts: 3
|
Hi!
I'll explain and show with detail what are we doing. This is a subrutine to inquiry an account from another part of the company and wait for the response into queue. In this process we commence with a sequence number and then put the corresponding message on the queue, wait for response and then get the message with the correlid and return this response to other program.
Below, I do some short explanation with the mosts importants parts of the code to help finding the cause that the message stays in the queue without being deleted.
---Begin
MOVE W-MSSG-SEQ-NBR TO WS-SAVE-CORRELID.
MOVE WS-SAVE-CORRELID TO MQMD-CORRELID.
MQPMO-OPTIONS = MQPMO-NO-SYNCPOINT
+ MQPMO-FAIL-IF-QUIESCING
+ MQPMO-SET-ALL-CONTEXT.
=> MQPUT1
MOVE MQMD-CORRELID TO WS-SAVE-CORRELID.
MQ-OPTIONS = MQOO-INPUT-AS-Q-DEF
+ MQOO-FAIL-IF-QUIESCING.
=> MQOPEN
MOVE WS-SAVE-CORRELID TO MQMD-CORRELID.
MQGMO-MATCHOPTIONS = MQMO-MATCH-CORREL-ID.
MQGMO-OPTIONS = MQGMO-WAIT
+ MQGMO-CONVERT
+ MQGMO-FAIL-IF-QUIESCING
+ MQGMO-ACCEPT-TRUNCATED-MSG.
+ MQGMO-ACCEPT-TRUNCATED-MSG
+ MQGMO-SYNCPOINT.
=> MQGET
(process)
=> MQCLOSE
(and return)
---End
My approach, i have to put an MQCMIT after the MQGET, but i'm not sure or we are doing something wrong with the CORRELID? Please if you need further clarification do not hesitate to let me know.
thanks in advance! |
|
Back to top |
|
 |
Vitor |
Posted: Wed Jul 28, 2010 9:43 am Post subject: Re: message is left on the queue |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
XK4 wrote: |
i'm not sure or we are doing something wrong with the CORRELID? |
It's a bit non-standard. It's generally the case that you let the queue manager generate id fields. Many problems arise from treating the id as if it's a number or a string when it's neither.
So I'd avoid using this sequence number as a correl id as a general principle & use a system generated one.
In your specific problem, what does the correl id of the message left on the queue appear to be? Does it match what you expect (this sequence number) or has the value changed? If so, how? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
XK4 |
Posted: Wed Jul 28, 2010 12:24 pm Post subject: Re: message is left on the queue |
|
|
Newbie
Joined: 28 Jul 2010 Posts: 3
|
Thank you for your response vitor.
Is possible that because i'm not matching the correl id the message stays on the queue and i'm still reading the last message?
But in sometime the queue will be full and the last message on the queue will be readed again and again till something reset the queue, it's this possible? when the queue will be reset?
How can i fix this... maybe trying to:
issuing a MQGET with:
MOVE MQMI-NONE TO MQMD-MSGID.
MOVE MQMI-NONE TO MQMD-CORRELID.
and
MQGMO-SYNCPOINT.
But first i have to inquiry the response by doing a the MQPUT with which options?
Thanks in advance. Sorry for the mix up! |
|
Back to top |
|
 |
Vitor |
Posted: Wed Jul 28, 2010 12:35 pm Post subject: Re: message is left on the queue |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
XK4 wrote: |
Is possible that because i'm not matching the correl id the message stays on the queue and i'm still reading the last message? |
It'll stay on the queue and your application will not get any message at all. Except if by blind luck another message has the right correl id. This is WMQ 101, basic stuff.
XK4 wrote: |
But in sometime the queue will be full and the last message on the queue will be readed again and again till something reset the queue, it's this possible? |
If nothing's reading the queue then yes it will fill up. The last message being read or not depends on how it's being read (see my comment above).
It sounds a lot like your code has a bug in it where if it doesn't actually read a message off the queue it ignores the error from WMQ & gives you a buffer with the last message in it. Ensure you clear the buffer between reads and then see if you think it's reading the last message over and over.
XK4 wrote: |
when the queue will be reset? |
When something starts reading messages or the WMQ administrator manually clears it. Unless you do somthing in your design to prevent it filling up in this scenario. As well as some basic WMQ from the Intercommunication manual, look up "message expiry"
XK4 wrote: |
How can i fix this... maybe trying to:
issuing a MQGET with:
MOVE MQMI-NONE TO MQMD-MSGID.
MOVE MQMI-NONE TO MQMD-CORRELID.
|
Well that would solve the "not reading a message" problem, but I thought you were after a specific message that was a specific reply?
XK4 wrote: |
and
MQGMO-SYNCPOINT. |
Why? How do you feel this would help?
XK4 wrote: |
But first i have to inquiry the response by doing a the MQPUT with which options? |
You can't inquire on anything with a MQPUT.
But something interesting and useful can be made to happen on the MQPUT. The Intercommunication manual talks a lot about request/reply scenarios like yours & is a valuable reference for you. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Jul 28, 2010 3:49 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
I'll be a bit more blunt.
WMQ offers a request/reply model; and if you follow it, your apps will work. The model is well-documented in the APG and APR manuals. I'd suggest that you take an app development course, too. IBM offers a 3-day WM50x for Win/UNIX/mainframe.
The model involves the requesting app asking the qmgr at mqput to create a unique MsgId. The MsgId is not a sequence number. Once the request message has been successfully mqput to the request queue, the requesting app then does an mqget with wait on the reply-to-queue with the CorrelId set to the MsgId of the request message.
Once the request message is mqput to the request queue, the replying app mqgets the request messages, does its back-end processing, then mqputs a reply message to the reply-to-queue with the inbound MsgId copied to the reply msg CorrelId.
Whether or not you use syncpoint or not is an app coding choice, and doesn't affect the request/reply model. _________________ 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 |
|
 |
gbaddeley |
Posted: Wed Jul 28, 2010 4:33 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
Quote: |
Whether or not you use syncpoint or not is an app coding choice, and doesn't affect the request/reply model. |
Although you do need to do a commit after putting the request message, before you attempt to get the reply message. _________________ Glenn |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Jul 28, 2010 4:43 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
Although you do need to do a commit after putting the request message, before you attempt to get the reply message. |
Of course.
(But you can attempt to get the reply any time. You will be more likely to succeed if the request msg has been committed.) _________________ 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 |
|
 |
Vitor |
Posted: Thu Jul 29, 2010 4:11 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
bruce2359 wrote: |
Quote: |
Although you do need to do a commit after putting the request message, before you attempt to get the reply message. |
Of course.
(But you can attempt to get the reply any time. You will be more likely to succeed if the request msg has been committed.) |
If and only if you've chosen to use transactionality, which the OP has.
(Though I suspect "chosen" is a strong term here & "copied from a sample" might be nearer the truth!)
Ah, those early days of WMQ, when it was all new & strange...  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Jul 29, 2010 6:11 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
If the symptom persists you might want to open a PMR. I believe I saw something about a problem like that in one of the notes IBM sent out.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
XK4 |
Posted: Thu Jul 29, 2010 11:09 am Post subject: |
|
|
Newbie
Joined: 28 Jul 2010 Posts: 3
|
Thanks for all to all!
----
So long and thanks for all the fish!
- Douglas Adams |
|
Back to top |
|
 |
|