| Author |
Message
|
| bruce2359 |
 Posted: Sat Sep 29, 2012 10:21 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| cicsprog wrote: |
| If I don't set the persistenance value to NO on the XMITq, then the reply msg never gets sent back. I don't understand how a Dynamic REPLY Q is getting generated by setting the XMITq persistenence value to NO. |
First, you have made quite a few assumption without the benefit source-code, and without understanding some WMQ fundamentals. You seem to have skipped over basic problem-determination steps frequently documented here to find the 'lost messages'.
Next, dynamic queues are not created by setting the persistence attribute of a queue. Rather, dynamic queues are created by the MQOPEN API call when the MQOD names a QModel object.
Changing the persistence attribute of a queue MAY cause the next MQPUT to set the persistence of the message to PERSISTENT. This is called persistence-as-defined-at-the-queue, and is a developer choice.
So, if the Windows app creates a temporary dynamic queue (NON-PERSISTENT MESSAGES ONLY), AND the inbound reply message from the IMS transaction is persistent (due to your fiddling with the xmit queue persistence attribute), then the now-persistent reply message would be sent from mf-to-windows, but could NOT be delivered to the non-persistent-only reply-to-queue on Windows. The reply message would instead be sent to the DLQ on Windows - presuming that a DLQ exists on Windows.
[edit]
Conversely, if your fiddling caused a non-persistent message to be put to the xmitq, AND the channel attribute NPMSPEED(FAST) is specified, AND the reply-to-queue on Windows is unavailable, AND the DLQ on Windows is unavailable, THEN the message will be undeliverable - and will be deleted by the Windows qmgr.
[/edit]
| cicsprog wrote: |
| They might be exploiting a hole in the API that may close one of these days. |
Not likely to be a hole in IBM code.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Last edited by bruce2359 on Sun Sep 30, 2012 6:54 am; edited 1 time in total |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Sat Sep 29, 2012 3:09 pm Post subject: Re: Dynamic REPLY Queue Generation Question |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| cicsprog wrote: |
| We have a Windows MQM (v6) connecting with mainframe MQM (v7). |
Version 7 dot what on WMQ for z/OS? v7.1?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Sep 29, 2012 7:08 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Moved to API support forum.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| cicsprog |
| Posted: Sun Sep 30, 2012 7:47 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
Bruce. The lack of MQ knowledge on one side of the many connections I support, my inability to drill into their configurations, the language and interpretation difference between cultures, and the fact that the developers are in a different time zone all contribute to making my job a difficult one. However, it’s one that I have done for 28 years. It is what it is. So never assume things are neat and tidy at all shops. I do the best I can with the tools I have and the personal that are willing to collaborate. I frequently run into “if its fixed no need to determine root cause” – sometimes a difficult pill to swallow. Again, it is what it is.
I’ll continue to try and figure out what’s happening here just for my own satisfaction. Whether I will or not find the issue is not always in my hands.
Nuff said and now back to debugging. |
|
| Back to top |
|
|
| cicsprog |
| Posted: Sun Sep 30, 2012 7:50 am Post subject: Re: Dynamic REPLY Queue Generation Question |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
| bruce2359 wrote: |
| cicsprog wrote: |
| We have a Windows MQM (v6) connecting with mainframe MQM (v7). |
Version 7 dot what on WMQ for z/OS? v7.1? |
7.01 on ZOS. I'll teach them to run the DSPMQMVER |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Sep 30, 2012 8:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
This looks more like an architectural miss.
Again the default would be for the service application to set the persistence of the reply message(whether the type is reply or datagram is irrelevant) to the persistence of the request message, UNLESS specifically directed by the architect to do differently. Your change in the attributes of the xmitq would then have absolutely no impact...
It is the responsibility of the requesting application, if they need their messages to be persistent, to provide a static standard queue for the reply messages as per default those would be persistent.
Go prepare some trout   
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Sep 30, 2012 5:06 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Oct 01, 2012 4:59 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
| The replying app in this scenario is not MQ aware. |
The replying application may or may not be MQ-aware. Lacking source-code, we don't know for sure.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| cicsprog |
| Posted: Mon Oct 01, 2012 9:30 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
Ok...so spent the AM writing code that creates temp queues and putting messages to them. Nothing I coded showed me away to send a message back to another MQM via a XMITq. No surprise.
So, its probably something, as Peter suggested, in the way IMS OTMA replies back to msgs. I checked the DRU exit. We don't have a DRU for this IMS. I will poke around the documentation on how IMS OTMA can reply back to messages. Stay tunned. |
|
| Back to top |
|
|
| cicsprog |
| Posted: Mon Oct 01, 2012 10:25 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
I turned on the channel message exit to log some messages. I see
<TRANSACTION xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="S:\wardoe\National SOP\Draft10National SOP XML Schema Draft 10.xsd"><SENDINFO><SENDDATA Sendtyp="SENDAPP">COFEE</SENDDATA></SENDINFO><TRANINFO><TRANDATA Trantyp="TRANID">FTTP ORD</TRANDATA><TRANDATA Trantyp="BUS"></TRANDATA><TRANDATA Trantyp="CONTRACT">NSOPLV5</TRANDATA><TRANDATA Trantyp="VERSION">1.0</TRANDATA></TRANINFO><REPLYINFO><REPLYDATA Replytyp="APP">Request Manager</REPLYDATA><REPLYDATA Replytyp="REPLY_Q">SSS.QD11.505E8B2B525B0E20 </REPLYDATA><REPLYDATA Replytyp="REPLY_Q_MGR">FHCDGW20</REPLYDATA>
So the ReplToQueue is imbedded in the msg payload. So that explains that. So the app MQPUTs directly to the XMITq of the ReplyToQueueManager. I was told that persistence is not being set. Therefore, it inherits the persistenence value from the XMITq - NO. So, MQ must know that the dest queue is a temporary dynamic queue and enforce that the XMITq be marked as NO persistence. Maybe enforce is a bad choice of words. The msgs probably ends up on the DLQ on the windows side and I’m not being told that.
I guess I’m done with this. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Oct 01, 2012 10:43 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| cicsprog wrote: |
So the ReplToQueue is imbedded in the msg payload. So that explains that. |
Ok.
| cicsprog wrote: |
| So the app MQPUTs directly to the XMITq of the ReplyToQueueManager. |
This is the usual way for a replying app to get the reply message to traverse the channel to the destination qmgr.
| cicsprog wrote: |
| I was told that persistence is not being set. Therefore, it inherits the persistenence value from the XMITq - NO. |
Again, if the app specifies persistence-as-q-def, then the message will take on the persistence specified at the queue.
| cicsprog wrote: |
So, MQ must know that the dest queue is a temporary dynamic queue and enforce that the XMITq be marked as NO persistence.
Maybe enforce is a bad choice of words. The msgs probably ends up on the DLQ on the windows side and I’m not being told that. I guess I’m done with this. |
Nope. Queue managers know nothing about object types belonging to another qmgr.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| cicsprog |
| Posted: Mon Oct 01, 2012 11:03 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
| Well maybe I should say that the Windows MCA won't allow a PERSISTENT msgs to be delivered to a temp dynamic queue on the windows box in this case - to the DLQ. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Oct 01, 2012 11:12 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| cicsprog wrote: |
| Well maybe I should say that the Windows MCA won't allow a PERSISTENT msgs to be delivered to a temp dynamic queue on the windows box in this case - to the DLQ. |
More precisely: the MCA will first attempt to put a persistent message to a temp-dynamic queue, and will fail; and then the MCA will attempt to put the message to the DLQ.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 01, 2012 3:56 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
| PeterPotkay wrote: |
| The replying app in this scenario is not MQ aware. |
The replying application may or may not be MQ-aware. Lacking source-code, we don't know for sure. |
If the app is fronted by the OTMA bridge, then there won't be any MQ API calls in the IMS application and therefore the app has no say in the persistence of the MQ reply message. The OTMA bridge is taking care of it using the rules in that link.
The people supporting that app may be MQ aware in that they know MQ messages are getting to them thru an OTMA bridge, but there is no MQ code in their app.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
