| Author |
Message
|
| advokaat |
 Posted: Mon Jul 02, 2007 2:27 am Post subject: Problem with rollback MQGET, from COBOL,on z/Os, using RRSAF |
 |
|
Novice
Joined: 02 Jul 2007
Posts: 14
|
step 0: start debugger
step 1: put on queue A.GW00.AA.REPLY_SQ1O (queue-mgr SQ1O) a message with correlation-id C
step 2: check that the message is indeed on the queue (‘tso mq’)
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
setp 9: the program isn’t happy with the message and forces an immediate abend
(just SRRBACK, setting of return-code, goback)
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 |
|
 |
| fjb_saper |
| Posted: Mon Jul 02, 2007 3:08 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Are you sure you're the only one to have the queue open in input mode?
After you roll back the message is a free for all who try to do a get on it....
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 02, 2007 3:08 am Post subject: Re: Problem with rollback MQGET, from COBOL,on z/Os, using R |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| advokaat wrote: |
setp 9: the program isn’t happy with the message and forces an immediate abend
(just SRRBACK, setting of return-code, goback)
|
Ok, now bear with me (it's been a while since I got hands dirty with z/OS) but doesn't a goback in COBOL issue an implicit commit? Surely you'd need to explicitly rollback to get the message back on the queue? Unless you actually fire a system level abend which you don't seem to be doing if I'm reading your post correctly?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Mon Jul 02, 2007 3:42 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
Vitor, yes, a goback is a "normal" return but the SSRBACK should to the backout work (which is like a MQBACK but under control of RRS).
advokaat - did you follow all the rules for RRs applications that are written in the application programmers reference? what stub did you link?
if you think your program is fine i would perform these tests:
read a message and then abend. message should be on queue.
read a message and then issue the ssrback. message should be on queue
manipulate the program to read the "c" message, then issue the ssrback. message should be on queue.
just to figure out if anything of the special actions like manipulating the program causes this situation.
and - as the others wrote - make sure nobody else is taking the message after backout.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 02, 2007 3:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Mr Butcher wrote: |
Vitor, yes, a goback is a "normal" return but the SSRBACK should to the backout work (which is like a MQBACK but under control of RRS).
|
I did think that was a bit obvious to be the solution... 
My defence is I've never used RRS. Not a good defence, but there you go.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| advokaat |
| Posted: Mon Jul 02, 2007 3:57 am Post subject: additions |
|
|
Novice
Joined: 02 Jul 2007
Posts: 14
|
Thanks for the replies! Additions:
I’m working in test-environment and I am the only one using this queue.
Goback alone will do an implicit commit, but now I do a high-level rollback (rrsaf because of using DB2 and MQ in the samen programma) before doing a goback…. Another solution is “CALL 'ILBOABN0' USING W-COMP-CODE” which will cause an abend plus dump, but this solution can not be considered very friendly.
Lked-cards:
INCLUDE OBJECT(GW05700)
INCLUDE LOAD(DSNRLI)
INCLUDE LOAD(DSNHADDR)
INCLUDE SYSLIB(ATRSCSS)
INCLUDE SYSLIB(CSQBRSTB) - MQ (BATCH)
NAME GW057(R)
I tested very extensively, but I can try another abend. |
|
| Back to top |
|
|
| advokaat |
| Posted: Mon Jul 02, 2007 4:22 am Post subject: |
|
|
Novice
Joined: 02 Jul 2007
Posts: 14
|
In step 9, I did “CALL 'ILBOABN0' USING W-COMP-CODE” with w-comp-code containing 17.
The message? Was still gone from the queue…… |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 02, 2007 4:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| advokaat wrote: |
In step 9, I did “CALL 'ILBOABN0' USING W-COMP-CODE” with w-comp-code containing 17.
The message? Was still gone from the queue…… |
Now we've established I don't know this RRS thing from a hole in the ground so anything I say needs to be viewed in this context.
But it does sound a lot like MQ is not participating in the coordinated unit of work and is unconditionally commiting. My brief spin through the documentation indicates that you've linked the right stub - are you missing a configuration step to link RRS with the queue manager?
I do know that if you try this using CICS as a resource manager it commits or rolls back as indicated in the manuals, so there's not a fundamental problem.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Mon Jul 02, 2007 4:40 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
okay. now devide something by zero directly after the mqget without doing any rrs stuff or calling someone. is the message still there?
did you tripple check there is no later MQGMO_NO_SYNCPOINT in the code? or that there are two mqgets in the program? or a hidden commit? or......
sorry for focusing on the program and the testing procedure, but a failing backout is really a no-no and should not happen. try a different program if you really can prove it - report to ibm
@vitor - defence accepted, same here. just theorethical. never had to program it 
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 02, 2007 4:42 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Mr Butcher wrote: |
sorry for focusing on the program and the testing procedure, but a failing backout is really a no-no and should not happen. try a different program if you really can prove it - report to ibm
|
It's unprecidented in my experience, but my experience doesn't include RRS!
Probably better moved to the Mainframe section? Is there a moderator in the house? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Mon Jul 02, 2007 4:54 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
advokaat, maybe have a look at this one
http://www.redbooks.ibm.com/redbooks/pdfs/sg246864.pdf
it hase some information about rrs and rrs programming, maybe this helps, maybe rrs is not set up properly, or it helps you to check the tread in rrs .... i had a quick look at the ispf panels in our system - i see the queuemanagers, i see the inflight threads, so maybe this helps.
no more ideas right now....... let us know what you find....
_________________
Regards, Butcher |
|
| Back to top |
|
|
| advokaat |
| Posted: Mon Jul 02, 2007 5:03 am Post subject: |
|
|
Novice
Joined: 02 Jul 2007
Posts: 14
|
Yes, this problem was known to another programmer working on another project……
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…. Is that necessary? I didn’t find it in the manuals. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Mon Jul 02, 2007 5:08 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| Vitor wrote: |
| Probably better moved to the Mainframe section? Is there a moderator in the house? |
yup, consider it done...  (Moved to Mainframe and CICS Forum)
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 02, 2007 5:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| advokaat wrote: |
| 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…. Is that necessary? I didn’t find it in the manuals. |
This is what I was getting at - is the queue manager one of the managed resources? It's behaving like it isn't. And given the strong family resemblance between DB2 & MQ (especially on z/OS) if you need to explictly identify one I'd expect you'd need to identify the other.
But my previous comments regarding RRS knowledge & experience still apply. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 02, 2007 2:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I don't suppose any of your messages are on the edge of expiring so that the roll back would have them expire and the background job would just clear them.... ??
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
