|
View previous topic :: View next topic
|
| Author |
Message |
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
Hi,
I am having an issue trying to PUT a request and GET a response within a single IMS transaction (Unit of work)
I have a transaction which does a PUT using the put option MQPMO-NO-SYNCPOINT
It waits.
The GET always then returns a 2033 no matter how long I wait.
I can do a GET with the returned message ID and read the response in a second transaction but I thought that using the MQPMO-NO-SYNCPOINT would allow me to do this within a transaction (unit of work)
I'm running z/OS IMS.
Can anyone point me in the right direction?
Dan. |
|
| Back to top |
|
 |
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
If may I ask and understand the situation in a different way.Did you try with MQPMO_SYNCPOINT? Why do you need to get the same message what just being PUT? if any other client wants to get the message then Commit is needed else it won't be visible until UOW is completed.
| Code: |
MQPMO_SYNCPOINT
Put a message with syncpoint control. The request is to operate within the normal unit of work. The message is not visible outside the unit of work until the unit of work is committed. If the unit of work is backed out, the message is deleted. This option applies to MQSeries® client calls only.
Note: A unit of work is committed by an MQDISC function call, a tx_commit function call from a local application, or an MQCMIT function call from the client program over a server connection channel. It is backed out by an MQBACK or tx_rollback function call.
MQPMO_NO_SYNCPOINT
Put a message without syncpoint control. The request is to operate within the normal unit of work. The message is available immediately and it cannot be deleted by backing out the unit of work. This option applies to MQSeries client calls only. |
|
|
| Back to top |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
Hi,
well I PUT the msg which I want to be immediately picked up by another application which does some processing and sends back a reply - it is this reply I am trying to GET.
So I explicitly want my message to be available outside the UOW. I don't want to wait for the commit for my message to be available to the downstream system.
I am currently trying to perform a MQDISC between the PUT and GET as I think this might be the solution. The MQCMIT is not an option in an online IMS transaction.
Dan |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
| Quote: |
| I am currently trying to perform a MQDISC between the PUT and GET as I think this might be the solution |
Yes and as always the case, since The message is not visible outside the unit of work until the unit of work is committed. |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
| Don't MQICM_SEND_THEN_COMMIT do a commit than using MQDISC, I am not sure ? Also I wonder why CHKP can't be issued? |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1205
Location: Dublin, Ireland
|
|
|
|
| Quote: |
| Yes and as always the case, since The message is not visible outside the unit of work until the unit of work is committed. |
Where MQPMO-NO-SYNCPOINT is used, the message put is visible immediately, regardless of the unit of work status.
There is no need to MQDISC and MQCONN between the MQPUT & the MQGET. What settings have you got in the MQGET (e.g. is MQMQD.Correlid set to the value of the MQMD.MsgId that is set after the MQPUT)? Is the other application successfully retrieving the message and setting MQMD.Correlid of its reply to the MQMD.MSgId of the retrieved message? Is the other application using MQPMO-NO-SYNCPOINT or issuing a commit /syncpoint? Are you sure any channels that might be between the applications are running (both directions)?
Garry |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
Garry, You are right about MQPMO-NO-SYNCPOINT and that's being the default value I guess.
I am not sure why one of the manual says this which lean towards above understanding.
| Code: |
MQPMO_NO_SYNCPOINT
Put a message without syncpoint control. The request is to operate within the normal unit of work. The message is available immediately and it cannot be deleted by backing out the unit of work. This option applies to MQSeries client calls only. |
|
|
| Back to top |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
| Quote: |
Where MQPMO-NO-SYNCPOINT is used, the message put is visible immediately, regardless of the unit of work status.
|
Yes this was my assumption and what is causing me a problem.
As you pointed out there indeed is no need to do a DISC, it had no effect.
The GET is working, I take the returned MSG-ID from the PUT and use that as the CORR-ID on the GET. This code is working correctly if I call the transaction for a second time.
The other app is receiving the message - processing it and writing a reply - this is all working correctly.
I can PUT - fail to GET. I can immediately see the msg on the queue - I can then run the GET and retrieve the message.
I will have to check the options used by the receiving application but I think they are using the options I pass - it's not running on z/OS. |
|
| Back to top |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
| Rohit Umarjikar wrote: |
| Don't MQICM_SEND_THEN_COMMIT do a commit than using MQDISC, I am not sure ? Also I wonder why CHKP can't be issued? |
It's not allowed to do a MQCMT inside an online IMS transaction - you get a 2012 RC. |
|
| Back to top |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
| Rohit Umarjikar wrote: |
Garry, You are right about MQPMO-NO-SYNCPOINT and that's being the default value I guess.
I am not sure why one of the manual says this which lean towards above understanding.
| Code: |
MQPMO_NO_SYNCPOINT
Put a message without syncpoint control. The request is to operate within the normal unit of work. The message is available immediately and it cannot be deleted by backing out the unit of work. This option applies to MQSeries client calls only. |
|
MQPMO-SYNCPOINT is the default. |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1205
Location: Dublin, Ireland
|
|
|
|
| Quote: |
| I can PUT - fail to GET. I can immediately see the msg on the queue - I can then run the GET and retrieve the message. |
Have you allowed sufficient WaitInterval and MQGMO-WAIT ?
Garry. |
|
| Back to top |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
[quote="Garry Carroll"][quote]
| Quote: |
| Have you allowed sufficient WaitInterval and MQGMO-WAIT ? |
Well I believe so. I have a process which does a GET waits and tries again. I currently have it set to waiting a total of 40 seconds.
Though I have MQGMO-WAIT set to 1. |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1205
Location: Dublin, Ireland
|
|
|
|
| Quote: |
| Though I have MQGMO-WAIT set to 1. |
MQGMO_WAIT is set to 1 by IBM. Have you included it in the MQGMO_OPTIONS
and set MQMD.WaitInterval to 40000?
Your process shouldn't do MQGET then WAIT & then try MQGET again. It should set the WaitInterval to the max time to wait for the reply & issue the WAITed MQGET. There is no need to issue a second MQGET (assuming the WaitInterval is sufficient).
Garry. |
|
| Back to top |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
| Garry Carroll wrote: |
| Quote: |
| Though I have MQGMO-WAIT set to 1. |
MQGMO_WAIT is set to 1 by IBM. Have you included it in the MQGMO_OPTIONS
and set MQMD.WaitInterval to 40000?
Your process shouldn't do MQGET then WAIT & then try MQGET again. It should set the WaitInterval to the max time to wait for the reply & issue the WAITed MQGET. There is no need to issue a second MQGET (assuming the WaitInterval is sufficient).
Garry. |
Well it's true that's a neater way.
I tied this but this also does not work. These are the options I am now using
Just for clarity.
I PUT1 to Q1 (with a reply to q name Q2) and Open and GET from Q2.
| Code: |
COMPUTE MQPMO-OPTIONS = MQPMO-NEW-MSG-ID +
MQPMO-NO-SYNCPOINT
|
I am opening the response queue with MQOO-INPUT-AS-Q-DEF
Then:
| Code: |
COMPUTE MQGMO-OPTIONS = MQGMO-NO-SYNCPOINT +
MQGMO-WAIT +
MQGMO-ACCEPT-TRUNCATED-MSG |
The thing is - I can wait 1 second and immediately do the GET and it works - this method using the TXN 2 times happens in much less than 40 seconds.
The message is just not being released until the UOW is completed and the transaction finishes. |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1205
Location: Dublin, Ireland
|
|
|
|
| Quote: |
| The message is just not being released until the UOW is completed and the transaction finishes. |
Can you show your MQPMO-OPTIONS, the MQGMO.WaitInterval in your code ?
Which message is not being release until the UOW finishes? If you can see the reply message increment the reply-to-queue depth while your applicaiton is running, then the put message has been released and has been processed by the other application. If the other application isn't using MQPMO-NO-SYNCPOINT and hasn't committed/syncpointed, then the message is "unavailable" on the reply queue.
Garry |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1205
Location: Dublin, Ireland
|
|
|
|
| Quote: |
| The message is just not being released until the UOW is completed and the transaction finishes. |
Can you show your MQPMO-OPTIONS, the MQGMO.WaitInterval in your code ?
Which message is not being release until the UOW finishes? If you can see the reply message increment the reply-to-queue depth while your applicaiton is running, then the put message has been released and has been processed by the other application. If the other application isn't using MQPMO-NO-SYNCPOINT and hasn't committed/syncpointed, then the message is "unavailable" on the reply queue.
Garry |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
| Quote: |
| MQPMO-SYNCPOINT is the default. |
| Code: |
| If MQPMO_NO_SYNCPOINT and MQPMO_SYNCPOINT are not specified, the inclusion of the put request in unit-of-work protocols is determined by the environment running the queue manager and not the environment running the application. On z/OS, the put request is within a unit of work. |
MQPMO options (MQLONG)
I just check my programs which I am working on and the trigger transaction is perfectly able to do MQGET before commit/syncpont.
| Code: |
COMPUTE MQPMO-OPTIONS = MQPMO-SYNCPOINT
+ MQPMO-FAIL-IF-QUIESCING
MOVE MQMI-NONE TO MQMD-MSGID
MOVE MQCI-NONE TO MQMD-CORRELID
MOVE MQFMT-STRING TO MQMD-FORMAT |
|
|
| Back to top |
|
|
Daniel Prosser
New User
Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam
|
|
|
|
@All.
I discovered what the issue is. 
I was using the same MQMD datastructure for the PUT and the GET. (obviously I was setting the values correctly for each call.)
This was fine when doing just the GET with a CORREL ID
But this does not work when you PUT then GET with the Correl ID.
I think there are some values which are being set by MQ in the MD that were preventing the MQGET.
Thanks for all your help. It's been a real struggle though a learning moment.  |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
| Quote: |
| But this does not work when you PUT then GET with the Correl ID. |
This is what my MQ GET calls look like and had no problems with it so far. But glad it worked for you.
| Code: |
COMPUTE MQGMO-OPTIONS = MQGMO-WAIT
+ MQGMO-SYNCPOINT
+ MQGMO-FAIL-IF-QUIESCING
END-COMPUTE
MOVE 2000 TO MQGMO-WAITINTERVAL
MOVE MQMI-NONE TO MQMD-MSGID
MOVE MQCI-NONE TO MQMD-CORRELID |
|
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1205
Location: Dublin, Ireland
|
|
|
|
| Daniel Prosser wrote: |
@All.
I discovered what the issue is.
I was using the same MQMD datastructure for the PUT and the GET. (obviously I was setting the values correctly for each call.)
This was fine when doing just the GET with a CORREL ID
But this does not work when you PUT then GET with the Correl ID.
I think there are some values which are being set by MQ in the MD that were preventing the MQGET.
Thanks for all your help. It's been a real struggle though a learning moment. |
I always recommend using separate MDMD structures for request and reply. You may not have reset MQMD.MsgId to MQMI-NONE? The incoming reply will most likely have a different MsgId to the request sent.
Garry |
|
| Back to top |
|
|
|
|
