| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Problem with rollback MQGET, from COBOL,on z/Os, using RRSAF |
View previous topic :: View next topic |
| Author |
Message
|
| advokaat |
 Posted: Mon Jul 02, 2007 11:11 pm Post subject: |
 |
|
Novice
Joined: 02 Jul 2007
Posts: 14
|
ALL PREVIOUS MAIL CAN BE REPLACED BY THE FOLLOWING.
-----------------------------
Assume: all returncodes are OK.
What are the possible reasons a message read with MQGET isn’t put back on the queue (or never removed) after a program abend?
or) option MQGMO-NO-SYNCPOINT
or) a commit is done before the abend
or) ???
----------------------------------------------------------------------------------------
More specific, I didn’t get the following right.
Context:
- I’m working in test-environment and I am the only one using this queue.
- I use RRSAF because of using DB2 and MQ.
- Lked-cards:
INCLUDE OBJECT(GW05700)
INCLUDE LOAD(DSNRLI)
INCLUDE LOAD(DSNHADDR)
INCLUDE SYSLIB(ATRSCSS)
INCLUDE SYSLIB(CSQBRSTB) - MQ (BATCH)
NAME GW057(R)
- The program has been extensively tested and this problem is the only one left.
- What struck me in the beginning is that I had to mention DB2 to RRSAF, but that I didn’t have to mention MQ to RRSAF….
step 0: start debugger
step 1: put on queue (queue-mgr SQ1O) a message with following properties:
correlation-id C, unlimited lifetime, persistent.
step 2: check that the message is indeed on the queue (‘tso mq’, pq)
step 3: start COBOL-batchprogram (EXEC PGM=GW057, parm)
step 4: manipute with debugger the program so it uses correlation-id C
step 5: the program executes
- OPEN with option MQOO-INPUT-AS-Q-DEF
step 6: check just before the MQGET that the message still is on the queue
step 7: the program executes
- MQGET with option MQGMO-SYNCPOINT and MQMO-MATCH-CORREL-ID
step 8: check just after the MQGET the queue: the message isn’t there any more
step 9: the program isn’t happy with the message and forces an immediate abend
(just SRRBACK, setting of return-code, goback)
(also tried: “CALL 'ILBOABN0' USING W-COMP-CODE” with w-comp-code containing 17.)
step 10: check just after the SSRBACK the queue: the message isn’t there.
IT SHOULD HAVE BEEN THERE !! WHY ISN’T IT????
step 11: check just after the ending of the program the queue: the message isn’t there.
IT SHOULD HAVE BEEN THERE !! WHY ISN’T IT????
SO IN CONTRARY TO THE MANUALS, THE MESSAGE ISN’T LEFT ON THE QUEUE AFTER A ROLLBACK (AND ONLY REMOVED WITH A COMMIT) |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jul 03, 2007 12:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| advokaat wrote: |
Assume: all returncodes are OK.
What are the possible reasons a message read with MQGET isn’t put back on the queue (or never removed) after a program abend?
or) option MQGMO-NO-SYNCPOINT
or) a commit is done before the abend
or) ???
|
Nothing that's not already been mentioned. Except the message is never "removed" by a MQGET, just tagged as unreadable by other MQ applications. Removal occurs at commit (even messages not under a unit of work are committed, it's just kinda unconditional in that instance..  )
Can you explain the paradox of "all return codes are OK" and "the program abends"? Keeping in mind my expereince with this RRS gadget, would you not get a system code in that job step if the application abends (I say job step as you've linked the batch adapter)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| advokaat |
| Posted: Tue Jul 03, 2007 1:54 am Post subject: |
|
|
Novice
Joined: 02 Jul 2007
Posts: 14
|
Indeed would be clearer than "all returncodes are OK" the followwing
"All returncodes of all calls are checked in the program."
It abends because, say "0 countries" were returned, which should be impossible. In that case the program ends with a condition code, 17, or 1001. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 03, 2007 2:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| advokaat wrote: |
| It abends because, say "0 countries" were returned, which should be impossible. In that case the program ends with a condition code, 17, or 1001. |
Now be clear with your terms here. Does the application abend in the strict sense, or does it complete normally with a condition code? You'll get different behaviours from these 2 situations.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| advokaat |
| Posted: Tue Jul 03, 2007 4:13 am Post subject: |
|
|
Novice
Joined: 02 Jul 2007
Posts: 14
|
I'm not sure whether we use the same definition:
I use:
abending:
* neat, with explicit rollback and condition-code <> 0
(setting return-code, doing a goback)
* neat, with condition-code <> 0
(setting return-code, doing a goback)
* not neat, with dump
(calling ilboabn0) |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 03, 2007 4:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| advokaat wrote: |
I'm not sure whether we use the same definition:
I use:
abending:
* neat, with explicit rollback and condition-code <> 0
(setting return-code, doing a goback)
* neat, with condition-code <> 0
(setting return-code, doing a goback)
* not neat, with dump
(calling ilboabn0) |
I would say the situation where you set a non-zero return code and issue a goback is not an abend. The message will be committed unless you issue an explicit rollback because your application has finished normally.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| advokaat |
| Posted: Tue Jul 03, 2007 4:44 am Post subject: |
|
|
Novice
Joined: 02 Jul 2007
Posts: 14
|
OK, OK, I do a USER-abend, not a system-abend.
I also do an explicit rollback, so I did the right thing to get the message back on the queue, didn't I?
(I didn't rely on system-defaults) |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 03, 2007 4:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| advokaat wrote: |
| OK, OK, I do a USER-abend, not a system-abend. |
It's at this point we dance on the head of a pin. When is an abend not an abend? When the system doesn't think it's an abend and trigger an abend handler. Problem programs can legitimatly set return codes to indicate various conditions and still be considered to complete normally.
| advokaat wrote: |
I also do an explicit rollback, so I did the right thing to get the message back on the queue, didn't I?
(I didn't rely on system-defaults) |
This touches back to the earlier point about participation in the unit of work. If you're explicitly issuing rollback via RSS and the message is not being rolled back onto the queue then it's not receiving the rollback signal. If this is your situation, issue an MQ rollback in the same place & see what happens then. If the message rolls back when MQ is explicitly triggered to do so, then there's a problem in the RSS<->MQ connection.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ramprasath_kumar |
| Posted: Tue Jul 03, 2007 5:02 am Post subject: |
|
|
Newbie
Joined: 03 Jul 2007
Posts: 4
Location: INDIA
|
try using MQGMO-MARK-SKIP-BACKOUT
in the MQGET options
i think this'll make the message to remain in the queue, if the program abends while processing it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 03, 2007 5:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ramprasath_kumar wrote: |
| i think this'll make the message to remain in the queue, if the program abends while processing it. |
No it doesn't.
The message remaining on the queue if the program abends is standard syncpoint processing. The point of this thread is that it's not going back on the queue in response to an abend/rollback.
Check out the APG/APR.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| advokaat |
| Posted: Tue Jul 03, 2007 5:48 am Post subject: |
|
|
Novice
Joined: 02 Jul 2007
Posts: 14
|
HUH?
I try MQBACK and get MQRC_ENVIRONMENT_ERROR.
So first I have to solve this.
Strange, all other mq-calls work fine. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 03, 2007 5:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Did you start the unit of work with an MQBEGIN, i.e. start a locally coordinated unit of work?
Also, from the APR:
| Quote: |
In environments where the queue manager does not coordinate the unit of work, use the appropriate back-out call instead of MQBACK. The environment might also support an implicit back out caused by the application terminating abnormally.
On z/OS, use the following calls:
Batch programs (including IMS batch DL/I programs) can use the MQBACK call if the unit of work affects only MQ resources. However, if the unit of work affects both MQ resources and resources belonging to other resource managers (for example, DB2(R)), use the SRRBACK call provided by the z/OS Recoverable Resource Service (RRS). The SRRBACK call backs out changes to resources belonging to the resource managers that have been enabled for RRS coordination.
|
Again this points to the MQ queue manager being identified to RSS as a controlled resource, like you said DB2 had been.
If you believe you have done this, or don't need to do this, and the message isn't being rolled back in response to an SRRBACK call then you're in PMR country. An indicator will be the same environment error from an MQBEGIN - this will indicate the queue manager has detected an external resource controller to which it has deferred.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| advokaat |
| Posted: Tue Jul 03, 2007 6:08 am Post subject: |
|
|
Novice
Joined: 02 Jul 2007
Posts: 14
|
I found for the environment error:
An MQCMIT or MQBACK call was issued, but the application has been linked with the RRS batch adapter CSQBRSTB. This adapter does not support the MQCMIT and MQBACK calls.
It is a lot of work for me to throw rrs (and db2 as well) out of the program to test with mqback only.
I rather wait till thursday when someone in the company here will have a look at it.... |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 03, 2007 6:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| advokaat wrote: |
I found for the environment error:
An MQCMIT or MQBACK call was issued, but the application has been linked with the RRS batch adapter CSQBRSTB. This adapter does not support the MQCMIT and MQBACK calls.
It is a lot of work for me to throw rrs (and db2 as well) out of the program to test with mqback only.
I rather wait till thursday when someone in the company here will have a look at it.... |
No need - you've proved your point.
I repeat - if you're clear in your own mind MQ is properly linked with RSS then you need to raise a PMR.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| advokaat |
| Posted: Tue Jul 03, 2007 6:44 am Post subject: |
|
|
Novice
Joined: 02 Jul 2007
Posts: 14
|
OK.
I wait a few days for the company-specialist to have a look at it.
And then I try a PMR with IBM.
But if there is a person around who has experienced the same problem.... |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
