| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Configur remote q to link an alias q |
« View previous topic :: View next topic » |
| Author |
Message
|
| hughson |
 Posted: Sat Jan 26, 2019 2:39 pm Post subject: |
 |
|
Padawan
Joined: 09 May 2013
Posts: 1948
Location: Bay of Plenty, New Zealand
|
| hisham.rakha wrote: |
The real QMGRs names are as follow, QMA is ESBMQ01STGDC1, QMB is ESBMQ02STGDC1, QMC is GWYMQ01STGDC1 and QMD T24MQDC1
Yes I do want to workload balance the reply.
Yes I do want the reply to go back to the queue manager that sent the request message wich is ESBMQ01STGDC1 and ESBMQ02STGDC1 |
Hmm, questions 2 and 3 were mutually exclusive. Either you want the reply to go back to the queue manager that sent the request, or you want it workload balanced to one of the two queue managers. You can't have both.
| hisham.rakha wrote: |
before executing the following command what the QMC refers to in below syntax ?
amqsput AQ_T24_OUT QMC 8208 0 GWYMQ01STGDC1 |
Now that you have told us the real names of your queue managers, the command would look like:-
| Code: |
| amqsput AQ_T24_OUT GWYMQ01STGDC1 8208 0 GWYMQ01STGDC1 |
| hisham.rakha wrote: |
Would you please tell me how to De-code the hex-dump of message into the DLH fields or if using certain tool please provide its name.  |
Several tools can do that. You could use Q, MO71, or MQEdit from my particular tool box, but lots of others do it too.
I await the answer to questions 2 & 3 before advising further.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Sat Jan 26, 2019 3:29 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9442
Location: US: west coast, almost. Otherwise, enroute.
|
| hisham.rakha wrote: |
| Would you please tell me how to De-code the hex-dump of message into the DLH fields or if using certain tool please provide its name. |
Google is your friend. A quick google search for 'how to view an mq dead letter header' resulted in many answers. My favorite https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.explorer.doc/e_properties_message.htm#e_properties_message__dlq
The MQExplorer is the easiest tool for decoding a DLH.
Browse your dead-letter-queue.
Right-click on a message in your dead-letter-queue.
Select Properties.
In the Navigator pane, click Dead-letter header.
The Content pane will have the decoded meaning of the DLH fields.
_________________
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 |
|
|
| hisham.rakha |
| Posted: Sun Jan 27, 2019 7:39 am Post subject: |
|
|
Apprentice
Joined: 13 Nov 2018
Posts: 39
|
| hughson wrote: |
| hisham.rakha wrote: |
The real QMGRs names are as follow, QMA is ESBMQ01STGDC1, QMB is ESBMQ02STGDC1, QMC is GWYMQ01STGDC1 and QMD T24MQDC1
Yes I do want to workload balance the reply.
Yes I do want the reply to go back to the queue manager that sent the request message wich is ESBMQ01STGDC1 and ESBMQ02STGDC1 |
Hmm, questions 2 and 3 were mutually exclusive. Either you want the reply to go back to the queue manager that sent the request, or you want it workload balanced to one of the two queue managers. You can't have both.
| hisham.rakha wrote: |
before executing the following command what the QMC refers to in below syntax ?
amqsput AQ_T24_OUT QMC 8208 0 GWYMQ01STGDC1 |
Now that you have told us the real names of your queue managers, the command would look like:-
| Code: |
| amqsput AQ_T24_OUT GWYMQ01STGDC1 8208 0 GWYMQ01STGDC1 |
| hisham.rakha wrote: |
| Would you please tell me how to De-code the hex-dump of message into the DLH fields or if using certain tool please provide its name. |
Several tools can do that. You could use Q, MO71, or MQEdit from my particular tool box, but lots of others do it too.
I await the answer to questions 2 & 3 before advising further.
Cheers,
Morag |
Sorry for confusing youbI want the reply to go back to the queue manager that sent the request |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jan 27, 2019 8:12 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9442
Location: US: west coast, almost. Otherwise, enroute.
|
| hisham.rakha wrote: |
| Sorry for confusing youbI want the reply to go back to the queue manager that sent the request |
How does your testing create a Request Message? A Request Message will need MessageType MQMT_REQUEST, and ReplyToQueue and ReplyToQueueManager fields populated in the MQMD. How does your testing accomplish this?
If you are trying to confirm the route (and name-resolution) your message is taking, look at dspmqrte IBM-supplied program.
_________________
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 |
|
|
| hisham.rakha |
| Posted: Sun Jan 27, 2019 10:20 am Post subject: |
|
|
Apprentice
Joined: 13 Nov 2018
Posts: 39
|
| bruce2359 wrote: |
| hisham.rakha wrote: |
| Sorry for confusing youbI want the reply to go back to the queue manager that sent the request |
How does your testing create a Request Message? A Request Message will need MessageType MQMT_REQUEST, and ReplyToQueue and ReplyToQueueManager fields populated in the MQMD. How does your testing accomplish this?
If you are trying to confirm the route (and name-resolution) your message is taking, look at dspmqrte IBM-supplied program. |
I just need to find a solution to make the QA works fine and all things will gonna be ok with me, I have no problem with the request as the MQMD already has the ReplyToQueue and ReplyToQmanager properly, I wnat to know why the msg landing in DLQ with mentioned error. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jan 27, 2019 10:28 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9442
Location: US: west coast, almost. Otherwise, enroute.
|
For clarity, is it the RequestMessage that ends up in DLQ? Or is it the ReplyMessage that ends up in 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 |
|
|
| hisham.rakha |
| Posted: Sun Jan 27, 2019 11:56 am Post subject: |
|
|
Apprentice
Joined: 13 Nov 2018
Posts: 39
|
| bruce2359 wrote: |
| For clarity, is it the RequestMessage that ends up in DLQ? Or is it the ReplyMessage that ends up in DLQ? |
The response |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jan 27, 2019 1:26 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9442
Location: US: west coast, almost. Otherwise, enroute.
|
| hisham.rakha wrote: |
What I want to do send the response of msg from QM D to QM A or QM B through the GTWY QM so I defined RQ on QM D as mentioned above to send the respone to the defined QA as mentioned above to locate it in the LQ LQ_OUT which defined on QM A & B |
This confuses me. I may have misunderstood. From your prior posts: QMD originated the RequestMessage, and QMA or QMB processed it. Am I incorrect?
Please use MQ technical terminology from here on, such as: RequestMessage, ReplyMessage.
Please confirm my understanding:
- the RequestMessage originates from app on QMD (qmgr not in cluster),
- is sent down SENDER-RECEIVER channel from QMD to QMC (the cluster gateway)
- QMC gateway will forward the RequestMessage to QMA (or QMB, based on cluster workload algorithm).
- RequestMessage arrives on QMA (or B) where
- consuming app will create a ReplyMessage
- ReplyMessage will be forwarded to QMC (gateway),
- QMC gateway will send the ReplyMessage back to QMD (not in cluster) via SENDER-RECEIVER channel
Is this correct?
_________________
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 |
|
|
| hughson |
| Posted: Sun Jan 27, 2019 5:34 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1948
Location: Bay of Plenty, New Zealand
|
You have told us that you have three queue managers in a cluster called 'GTWYCLUSTER'
- QMgr: ESBMQ01STGDC1 aka QMA
- QMgr: ESBMQ02STGDC1 aka QMB
- QMgr: GWYMQ01STGDC1 aka QMC - the gateway QMgr
and one queue manager outside the cluster, which connects in through the Gateway QMgr
You showed us some of the pertinent definitions you are trying to use.
| hisham.rakha wrote: |
QM D:
DEFINE QREMOTE (RQ_ESB) RNAME(AQ_OUT) RQMNAME(GWYMQSTG) XMITQ(TQ_IN) CLUSTER(' ') REPLACE ;
QM C:
DEFINE QALIAS(AQ_OUT) TARGQ(LQ_OUT) CLUSTER(GTWYCLUSTER) |
You say that when you try to test a message by putting to queue RQ_ESB on QMgr QMD it lands on the Dead-letter queue on QMC with the following header.
| Code: |
[ 174 bytes] Dead Letter Queue Header (MQDLH)
StrucId :'DLH '
Version :1
Reason :2082 (Unknown alias base queue.)
Dest. Queue :'AQ_T24_OUT '
Dest. QMgr :'GWYMQ01STGDC1 '
MQEncoding :0x'222' (Reversed)
CCSID :1208 (UTF-8)
Format :'MQSTR '
PutApplType :6 (UNIX)
PutApplName :'amqrmppa '
Put Date :'20190123'
Put Time :'06055861' |
This means that when the receiver channel on QMC tried to put the message it was delivering, it was trying to put it to a queue called:-
| Code: |
Queue Name: AQ_T24_OUT
QMgr Name: GWYMQ01STGDC1 |
The queue manager resolves the AQ_T24_OUT queue name part from the alias queue definition that is on QMC.
| hisham.rakha wrote: |
QUEUE(AQ_T24_OUT) TYPE(QALIAS)
ALTDATE(2019-01-22) ALTTIME(15.05.37)
TARGET(LQ_T24_OUT) CLUSNL( )
CLUSTER(GTWYCLUSTER) CLWLPRTY(0)
CLWLRANK(0) CUSTOM( )
DEFBIND(NOTFIXED) DEFPRTY(0)
DEFPSIST(NO) DEFPRESP(SYNC)
DEFREADA(NO) DESCR( )
GET(ENABLED) PUT(ENABLED)
PROPCTL(COMPAT) SCOPE(QMGR)
TARGTYPE(QUEUE) |
So after this queue name resolution, the receiver channel on QMC is effectively trying to put the message to a queue called:-
| Code: |
Queue Name: LQ_T24_OUT
QMgr Name: GWYMQ01STGDC1 |
There is no queue called LQ_T24_OUT on queue manager GWYMQ01STGDC1 (aka QMC) and so the put that the receiver channel is trying to do fails and the message lands up on the Dead-letter queue.
The reason it fails is because of the queue manager name. You actually want the receiver channel to be doing a put to a queue called:-
| Code: |
Queue Name: LQ_T24_OUT
QMgr Name: blank |
If the Queue manager name field is blank, then queue name resolution can look in the cluster to find queues called LQ_T24_OUT advertised in the cluster, and route the message to one of them. When the queue manager name is filled in rather than being blank, clustering cannot route it somewhere else because it has to go to the specified queue manager name.
So, you could solve the problem of having the queue manager name populated by defining some queue manager alias definitions.
HOWEVER, before you do that, in answer to my questions, you said:-
| hughson wrote: |
2. Do you really want to workload balance the reply?
3. Do you want the reply to go back to the queue manager that sent the response message? |
| hisham.rakha wrote: |
| I want the reply to go back to the queue manager that sent the request |
So, doing a put to remote queue definition RQ_ESB on QMD is not going to send the reply back to the queue manager that sent the request. If we solve the problem of the queue name resolution by getting the queue manager name blanked out so that cluster name resolution can kick in, that will work-load balance the message between the two queue managers that host LQ_T24_OUT. That is not what you want.
So, given that you want the reply to go back to the queue manager that sent the request, the application running on QMD should be putting the reply message to the MQMD.ReplyToQ and MQMD.ReplyToQMgr fields. Is this the case? Presumably this means that the application is doing a put to a queue called:-
| Code: |
Queue Name: LQ_T24_OUT
QMgr Name: ESBMQ01STGDC1 |
This put on QMD will fail unless you set up a QREMOTE to resolve the queue manager name that QMD doesn't know because it is in the cluster. You need to tell QMD that if it sees the queue manager name ESBMQ01STGCD1 it should simply route it to the transmission queue for the gateway. One simple way to do this is to define a remote queue on QMD like this for each queue manager needed to be resolved.
| Code: |
| DEFINE QREMOTE(ESBMQ01STGCD1) RNAME(' ') RQMNAME(ESBMQ01STGCD1) XMITQ(TQ_IN) |
Hopefully, I've understood correctly what you are trying to do?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| hisham.rakha |
| Posted: Sun Jan 27, 2019 7:09 pm Post subject: |
|
|
Apprentice
Joined: 13 Nov 2018
Posts: 39
|
T24 Application has configuration file that must be filled with below, so what suppose to type in MQQUEUE OUT field the QR name ESBMQ01STGDC1 or the LQ_T24_OUT
MQMANAGER: T24STGDC1
MQQUEUE IN: LQ_T24S_IN
BACKOUTQUEUE: N/A
MQQUEUE OUT: ???
DEADLETTERQUEUE: DLQ
Is the above QR defination that you advised will route the respone via gateway QMgr |
|
| Back to top |
|
|
| hughson |
| Posted: Sun Jan 27, 2019 7:24 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1948
Location: Bay of Plenty, New Zealand
|
| hisham.rakha wrote: |
T24 Application has configuration file that must be filled with below, so what suppose to type in MQQUEUE OUT field the QR name ESBMQ01STGDC1 or the LQ_T24_OUT
MQMANAGER: T24STGDC1
MQQUEUE IN: LQ_T24S_IN
BACKOUTQUEUE: N/A
MQQUEUE OUT: ???
DEADLETTERQUEUE: DLQ |
Are you telling us that the T24 application does not use the MQMD.ReplyToQ and MQMD.ReplyToQMgr fields when sending its reply back and instead always puts the response message to the queue in the configuration file attribute MQQUEUE OUT?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| hisham.rakha |
| Posted: Sun Jan 27, 2019 7:56 pm Post subject: |
|
|
Apprentice
Joined: 13 Nov 2018
Posts: 39
|
| hughson wrote: |
| hisham.rakha wrote: |
T24 Application has configuration file that must be filled with below, so what suppose to type in MQQUEUE OUT field the QR name ESBMQ01STGDC1 or the LQ_T24_OUT
MQMANAGER: T24STGDC1
MQQUEUE IN: LQ_T24S_IN
BACKOUTQUEUE: N/A
MQQUEUE OUT: ???
DEADLETTERQUEUE: DLQ |
Are you telling us that the T24 application does not use the MQMD.ReplyToQ and MQMD.ReplyToQMgr fields when sending its reply back and instead always puts the response message to the queue in the configuration file attribute MQQUEUE OUT?
Cheers,
Morag |
Yes T24 application uses these configuration before send the response |
|
| Back to top |
|
|
| hughson |
| Posted: Sun Jan 27, 2019 8:05 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1948
Location: Bay of Plenty, New Zealand
|
| hisham.rakha wrote: |
| hughson wrote: |
| hisham.rakha wrote: |
T24 Application has configuration file that must be filled with below, so what suppose to type in MQQUEUE OUT field the QR name ESBMQ01STGDC1 or the LQ_T24_OUT
MQMANAGER: T24STGDC1
MQQUEUE IN: LQ_T24S_IN
BACKOUTQUEUE: N/A
MQQUEUE OUT: ???
DEADLETTERQUEUE: DLQ |
Are you telling us that the T24 application does not use the MQMD.ReplyToQ and MQMD.ReplyToQMgr fields when sending its reply back and instead always puts the response message to the queue in the configuration file attribute MQQUEUE OUT?
Cheers,
Morag |
Yes T24 application uses these configuration before send the response |
Well then there is no way to send the reply message back to the application which sent it. If you hard code the queue that replies go back to then it can't change depending on where it came from. Do you understand this?
Now that we know this about your application I think we need to ask you this question again.
Q) Where do you want these reply messages to go, EXACTLY.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jan 27, 2019 8:16 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9442
Location: US: west coast, almost. Otherwise, enroute.
|
| hughson wrote: |
| Are you telling us that the T24 application does not use the MQMD.ReplyToQ and MQMD.ReplyToQMgr fields when sending its reply back and instead always puts the response message to the queue in the configuration file attribute MQQUEUE OUT? |
| hisham.rakha wrote: |
| Yes T24 application uses these configuration before send the response |
So, you are really not implementing the usual request-reply model where the RequestMessage is unique (based on MQMD.MsgId), and the requesting app waits for the ReplyMessage with MQMD.CorrelId (of ReplyMessage) == MQMD.MsgId (of RequestMessage).
How does the requesting app on QMD understand which reply (response) goes with the request? Is that built into both requesting and responding apps? Do the apps keep track of requests send and replies received? How does it deal with missing or duplicate response?
Is this a new application? Has it ever worked?
_________________
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 |
|
|
| hughson |
| Posted: Sun Jan 27, 2019 8:52 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1948
Location: Bay of Plenty, New Zealand
|
| bruce2359 wrote: |
| How does the requesting app on QMD understand which reply (response) goes with the request? |
Hmm, interesting, I had read the OP as suggesting that QMD was the responding app, not the requesting app.
Hisham, can you confirm which way round is the setup.
Is it:-
- QMD is requesting app, then either QMA or QMB is responding app
- QMA or QMB is requesting app, QMD is responding app
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| 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
|
|
|
|
