ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » Configur remote q to link an alias q

Post new topic  Reply to topic Goto page Previous  1, 2, 3, 4, 5, 6  Next
 Configur remote q to link an alias q « View previous topic :: View next topic » 
Author Message
hughson
PostPosted: Sat Jan 26, 2019 2:39 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Sat Jan 26, 2019 3:29 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
hisham.rakha
PostPosted: Sun Jan 27, 2019 7:39 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Sun Jan 27, 2019 8:12 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
hisham.rakha
PostPosted: Sun Jan 27, 2019 10:20 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Sun Jan 27, 2019 10:28 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
hisham.rakha
PostPosted: Sun Jan 27, 2019 11:56 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Sun Jan 27, 2019 1:26 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
hughson
PostPosted: Sun Jan 27, 2019 5:34 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
  • QMgr: T24MQDC1 aka QMD

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
View user's profile Send private message Visit poster's website
hisham.rakha
PostPosted: Sun Jan 27, 2019 7:09 pm    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Sun Jan 27, 2019 7:24 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
hisham.rakha
PostPosted: Sun Jan 27, 2019 7:56 pm    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Sun Jan 27, 2019 8:05 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
bruce2359
PostPosted: Sun Jan 27, 2019 8:16 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
hughson
PostPosted: Sun Jan 27, 2019 8:52 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2, 3, 4, 5, 6  Next Page 4 of 6

MQSeries.net Forum Index » Clustering » Configur remote q to link an alias q
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.