Author |
Message
|
nandu24m |
Posted: Mon Jul 13, 2009 1:26 am Post subject: How to use MQCOMMIT/MQROLLBACK on AIX for COBOL application? |
|
|
Newbie
Joined: 13 Jul 2009 Posts: 2
|
Hi all,
I am a novice with the MQ. I have a query regarding the usage of the MQCOMMIT and MQROLLBACK. I have MQ Client on AIX installed for the COBOL-based application and i send messages to the queue(third party) whenever certain conditions meet,for this i use MQCONN,MQOPEN,MQPUT,MQCLOSE inside the application. Currently, i do not use MQCOMMIT and MQROLLBACK. Here's my problem: FOr a successful transaction inside the application, there is no issue related to MQ as i get to know that the transaction gets commited after certain time-out in the queue. However, there are certain transactions which fail after the MQ message is sent to the queue. I want to use the MQCOMMIT/MQROLLBACK inside my application to overcome that but i do not find sample COBOL code of calling MQCOMMIT and MQROLLBACK as i always find the things related to the CICS/Mainframes etc., can anyone please refer me the links to the sample codes. Also, i want to know that for using the MQCOMMIT and MQROLLBACK, do i have to open the MQ again? Because for the transaction that has happened, i have opened, sent and closed the connection. |
|
Back to top |
|
 |
Vitor |
Posted: Mon Jul 13, 2009 1:49 am Post subject: Re: How to use MQCOMMIT/MQROLLBACK on AIX for COBOL applicat |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
nandu24m wrote: |
do i have to open the MQ again? Because for the transaction that has happened, i have opened, sent and closed the connection. |
You shouldn't be doing that anyway. Connecting and disconnecting is an expensive operation and it's inefficient to do it for each message. Connect at the start of processing, disconnect at the end.
The samples you've found should illustrate this. COBOL is the same on non-mainframe as it is on AIX.
Note that the standard client doesn't support externally coordinated transactions, only UOW on the queue manager. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
exerk |
Posted: Mon Jul 13, 2009 1:54 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
I suggest that you read through the Application Programming Guide (APG), paying especial attention to the areas to which you have questions, and then come back and maybe ask the questions again, but in a more focussed way.
And I do hope that you are not doing MQCONN -> MQOPEN -> MQPUT -> MQCLOSE for every message... _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
zpat |
Posted: Mon Jul 13, 2009 1:56 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Should use MQDISC for each case of MQCONN.
Samples do not always exhibit ideal behaviour.
If you issue MQCLOSE on a queue, the current transaction is closed.
However it won't be open unless you coded SYNCPOINT on the MQGET or MQPUT.
What you want is something like this
MQCONN
Check MQRC
MQOPEN
Check MQRC
MQGET with CONVERT, SYNCPOINT, FAIL IF QUIESCING (and maybe WAIT)
Check MQRC
Process the data
if OK then
MQCOMMIT
else
MQBACK
loop back to MQGET for next message unless MQRC 2033 (empty queue).
MQCLOSE
MQDISC |
|
Back to top |
|
 |
Vitor |
Posted: Mon Jul 13, 2009 2:01 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
zpat wrote: |
MQGET with CONVERT, SYNCPOINT, FAIL IF QUIESCING (and maybe WAIT)
|
In the poster's case, MQPUT with relevent options. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
exerk |
Posted: Mon Jul 13, 2009 2:04 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
zpat wrote: |
...loop back to MQGET for next message unless MQRC 2033 (empty queue)... |
I wouldn't normally pick up on this, but as this guy is a newbie...
MQRC 2033 MQRC_NO_MSG_AVAILABLE can occur because the queue is empty of all messages, or there are messages on the queue but unavailable for GET, i.e. uncommitted messages, or the GET is criteria based, e.g. CORRELID, and the message does not arrive within the WAIT period. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
nandu24m |
Posted: Mon Jul 13, 2009 4:01 am Post subject: |
|
|
Newbie
Joined: 13 Jul 2009 Posts: 2
|
Hi all, i have been using the below mentioned options when i am putting the message to the queue...so i will be able to open the queue again..isnt it?
MOVE UTMQIOCA-MSGID TO MQMD-MSGID
MOVE MQMT-REPLY TO MQMD-MSGTYPE
MOVE UTMQIOCA-MQ-REPLYTOQMGR
TO MQOD-OBJECTQMGRNAME.
MOVE UTMQIOCA-MQ-NAME TO MQOD-OBJECTNAME.
MOVE MQCI-NONE TO MQMD-CORRELID.
MOVE SPACES TO MQMD-REPLYTOQ.
MOVE SPACES TO MQMD-REPLYTOQMGR.
COMPUTE MQPMO-OPTIONS = MQPMO-SYNCPOINT +
MQPMO-DEFAULT-CONTEXT.
CALL "MQPUT" USING WS-OUT-HCONN
WS-INQ-HANDLE
MESSAGE-DESCRIPTOR
PMOPTIONS
UTMQIOCA-MSG-LENGTH
UTMQIOCA-MSG
WS-COMPLETION-CODE/local variable
WS-REASON. /local variable |
|
Back to top |
|
 |
Vitor |
Posted: Mon Jul 13, 2009 4:14 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
nandu24m wrote: |
Hi all, i have been using the below mentioned options when i am putting the message to the queue...so i will be able to open the queue again..isnt it? |
You need to spend a lot more time reading the APG. Then you'd understand why that question doesn't make any sense.
You also need to be very certain you want to be deliberately setting a message id. This is almost certainly uncessesary and always a bad ida. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|