| Author |
Message
|
| cicsprog |
 Posted: Thu Sep 27, 2012 8:00 am Post subject: Dynamic REPLY Queue Generation Question |
 |
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
| We have a Windows MQM (v6) connecting with mainframe MQM (v7). Sender and Receiver pair of channels. Windows side use a QREMOTE to deliver a message to a QLOCAL OTMA IMS queue on the mainframe were msg is processed by IMS app. A REPLY msg is generated. On the mainframe side, the only thing defined is the XMITq and the SENDER channel back to the WINDOWS MQM. 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. Thanks for any replies. |
|
| Back to top |
|
 |
| cicsprog |
| Posted: Thu Sep 27, 2012 11:05 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
| From the reading I've done, the windows application must be creating a temporary dynamic queue. They pass that queue name along with the reply to mqm on the request msg. When the message arrives on the mainframe and is processed by IMS, the temporary dynamic reply Q is not on the mainframe. However, there is a matching XMITq for the message to go back to the reply to MQM. Why the XMITq has to be non-persistenent to maintain the temporary dynamic queue is not clear to me and I can't find anything saying that needs to be the case in Application Programming Guide or Intercommunication Guide. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Sep 28, 2012 5:48 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Yes, the requesting app (on whatever platform) creates a (dynamic) reply-to-queue, and specifies its name in the MQMDs reply-to-queue; and usually specifies the qmgr where the reply is to be sent. It is most often the same qmgr as the one where the requesting app executes. An xmitq with the same name as the qmgr at the other end of the sender channel is the usual naming convention.
Persistence defined at the queue (xmit or otherwise) is only used to determine the persistence of a message IF the developer specified persistence-as-q-def (persistence as defined at the queue). It is not a default.
I doubt that your fiddling with the persistence attribute of the queue is suppressing the replying application. Are you absolutely sure no messages are being produced and sent? Stop the channel, then try again. I suspect that messages will be in the xmitq waiting to be sent.
It is possible, but unlikely, that the requesting app is checking the persistence field in the reply message, and ignoring messages with the 'wrong' persistence value.
_________________
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: Fri Sep 28, 2012 6:01 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
| The toggling of the persistence value on the mainframe XMITq did make the difference. I was working with the app several hours yeaterday. I think I need to pose the question to IBM. Since temporary dynamic Q's can't be persistent, my guess is this has something to do with it. It might not be documented. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Sep 28, 2012 6:12 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
For clarity, exactly where is the dynamic queue? On z/OS? Or on Windows?
And, you are toggling the persistence attribute of the xmit queue from z/OS to Windows, yes?
And, you stopped the channel? And, you verified that messages arrived in the xmitq with defpsist attribute of the xmit queue set to NO and YES?
FYI, dynamic queues can be either PERMANENT - allowing for both persistent and non-persistent messages, and TEMPORARY - allowing only non-persistent messages.
I'm guessing that your fiddling with the xmitq attribute generated persistent messages that were rejected (with a ReasonCode) by the qmgr on windows.
_________________
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: Fri Sep 28, 2012 6:18 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
For clarity, exactly where is the dynamic queue? On z/OS? Or on Windows? Windows
And, you are toggling the persistence attribute of the xmit queue from z/OS to Windows, yes? YES
And, you stopped the channel? And, you verified that messages arrived in the xmitq with defpsist attribute of the xmit queue set to NO and YES? Didn't do that
FYI, dynamic queues can be either PERMANENT - allowing for both persistent and non-persistent messages, and TEMPORARY - allowing only non-persistent messages. Temporary
I'm guessing that your fiddling with the xmitq attribute generated persistent messages that were rejected (with a ReasonCode) by the qmgr on windows.
I'm asking the app for their code. So, keep you posted[/b] |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Sep 28, 2012 6:20 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
You weren't doing this in production, were you?
_________________
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: Fri Sep 28, 2012 6:27 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
| yes...but these were some new servers being added and app team was doing verification with test accounts before releasing to end users. There are other servers in their application that are doing this very thing and not having an issue. But, when I defined the XMITq for these instances, they never got their replies because of the persistence value of YES on the XMITq. It just took me a while to find the needle in the hay stack. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Sep 28, 2012 6:33 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
When you clone a qmgr, use the same exact object attributes.
_________________
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: Fri Sep 28, 2012 7:09 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
Via the channel logging exit here's the message coming into the mainframe:
2012-09-28 10:53:08 CML@V2R7: Message via 'FHCDGW19.MQ04.00' on 'MQ04'
MQXQH: RemoteQName='SOP.VGINSOP' RemoteQMgrName='MQ04'
MQMD: Version=1 Report=0 MsgType=8(Datagram) Expiry=180000(1/10secs)
Feedback=0 Encoding=x222 CCSID=37 Format="MQIMS"
Priority=0 Persistence=0(No) BackoutCount=0 PutApplType=11(Windows)
MsgId=x414D512046484344475731392020202038FC6350200DA921
CorrelId=x414D512046484344475731392020202038FC6350200DA922
ReplyToQ='' ReplyToQMgr='FHCDGW19'
And here is a reply going back. Note the RemoteQName:
2012-09-28 10:59:54 CML@V2R7: Message via 'MQ04.FHCDGW19.00' on 'MQ04'
MQXQH: RemoteQName='SSS.QD8.5063FC3802C80D20' RemoteQMgrName='FHCDGW19'
MQMD: Version=1 Report=0 MsgType=8(Datagram) Expiry=-1(Unlimited)
Feedback=0 Encoding=x311 CCSID=500 Format="MQSTR"
Priority=0 Persistence=0(No) BackoutCount=0 PutApplType=3(IMS)
MsgId=xC3E2D840D4D8F0F44040404040404040CA3D497BD699642E
ActToken=x18D5E2D6D7E9D6C740E2D6D74040404040004641050000000000000000000000
So, I guess I'm wrong on were the temp Q gets defined. But, still not understanding the persistence requirement or how the Windows side knows what reply Q to use. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Sep 28, 2012 6:42 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Are the two messages you posted then entire contents sent to, and received from z/OS WMQ? Was there no IIH header with the message from the Windows app? Was there no application data?
I ask because both messages are message-type of datagram - neither is a request nor reply.
_________________
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 |
|
|
| fjb_saper |
| Posted: Fri Sep 28, 2012 8:35 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| cicsprog wrote: |
| The toggling of the persistence value on the mainframe XMITq did make the difference. I was working with the app several hours yeaterday. I think I need to pose the question to IBM. Since temporary dynamic Q's can't be persistent, my guess is this has something to do with it. It might not be documented. |
Guys verify your API's and what not. It states clearly that when you attempt to receive a persistent message on a temporary dynamic queue, the message will fail and be routed to the DLQ with reason code: wrong persistence attribute! Working as designed!
The application on the MF should respect the persistence attribute of the request message and set the same on the response. Unless directed to do specifically something different by the project architects. This way changing the default persitency of a queue (xmitq) would have no effect as the persistency is set at application level.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Sep 29, 2012 5:24 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Attempts to MQPUT a persistent message in a temporary dynamic queue will fail with MQCC_FAILED and ReasonCode 2048 (0800) (RC2048): MQRC_PERSISTENT_NOT_ALLOWED. No message is created.
_________________
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: Sat Sep 29, 2012 7:09 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
| bruce2359 wrote: |
Are the two messages you posted then entire contents sent to, and received from z/OS WMQ? Was there no IIH header with the message from the Windows app? Was there no application data?
I ask because both messages are message-type of datagram - neither is a request nor reply. |
It was there, I just didn't want to disclose that msgs data. |
|
| Back to top |
|
|
| cicsprog |
| Posted: Sat Sep 29, 2012 7:18 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
I might not get the code from the Windows application side. They aren't very MQ savey and they are in India and might not reply back since it works with the PERSISTENCE set to NO on the MF XMITq. I will pester them again on Monday.
I will need to get the MF code also. I do see a MODEL queue object in the MF's MQM defs. I don't see how creating a TEMP DYNAMIC on the MF and doing a MQPUT of a REPLY msg back to the XMITq would work either.
Very confusing senario. If I get some time and no help from the applications, I'll write a small app to reproduce the senario. They might be exploiting a hole in the API that may close one of these days. |
|
| Back to top |
|
|
|
|
