IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

MQPMO-NO-SYNCPOINT


IBM Mainframe Forums -> Java & MQSeries
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam

PostPosted: Tue Dec 04, 2018 8:55 pm
Reply with quote

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
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Tue Dec 04, 2018 10:36 pm
Reply with quote

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
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam

PostPosted: Wed Dec 05, 2018 12:03 am
Reply with quote

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
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Wed Dec 05, 2018 12:14 am
Reply with quote

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
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Wed Dec 05, 2018 12:33 am
Reply with quote

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
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Wed Dec 05, 2018 1:38 pm
Reply with quote

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
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Wed Dec 05, 2018 7:43 pm
Reply with quote

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
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam

PostPosted: Thu Dec 06, 2018 12:12 pm
Reply with quote

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
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam

PostPosted: Thu Dec 06, 2018 12:14 pm
Reply with quote

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
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam

PostPosted: Thu Dec 06, 2018 12:15 pm
Reply with quote

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
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Thu Dec 06, 2018 1:03 pm
Reply with quote

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
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam

PostPosted: Thu Dec 06, 2018 1:13 pm
Reply with quote

[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
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Thu Dec 06, 2018 1:25 pm
Reply with quote

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
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam

PostPosted: Thu Dec 06, 2018 5:04 pm
Reply with quote

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
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Thu Dec 06, 2018 5:15 pm
Reply with quote

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
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Thu Dec 06, 2018 5:42 pm
Reply with quote

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
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Thu Dec 06, 2018 8:45 pm
Reply with quote

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
View user's profile Send private message
Daniel Prosser

New User


Joined: 05 Nov 2010
Posts: 57
Location: Amsterdam

PostPosted: Thu Dec 06, 2018 10:53 pm
Reply with quote

@All.

I discovered what the issue is. icon_biggrin.gif

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. icon_eek.gif
Back to top
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Fri Dec 07, 2018 1:42 am
Reply with quote

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
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Fri Dec 07, 2018 2:03 pm
Reply with quote

Daniel Prosser wrote:
@All.

I discovered what the issue is. icon_biggrin.gif

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. icon_eek.gif


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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> Java & MQSeries

 


Similar Topics
Topic Forum Replies
No new posts How to place SYNCPOINT in VSAM . CICS 2
No new posts TWA variable having junk value after ... CICS 1
No new posts Understanding Syncpoint : CICS 3
No new posts Error in CICS SYNCPOINT ROLLBACK CICS 4
No new posts Query on SYNCPOINT and SYNCORETURN CICS 2
Search our Forums:

Back to Top