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 » General IBM MQ Support » sending messages without using remote queue definition

Post new topic  Reply to topic Goto page Previous  1, 2
 sending messages without using remote queue definition « View previous topic :: View next topic » 
Author Message
mqjeff
PostPosted: Tue Jul 24, 2012 6:32 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

bernard_fay wrote:
There is thousands of queues on the target QM. We would like to avoid to define each one of them on the source QM.

bruce2359 wrote:
A qmgr alias is a QRemote definition.


It's *one* qremote, not *one* qremote for *each* qlocal on the remote qmgr.

And a cluster doesn't make sense with two queue managers, or with only one instance of each destination queue.
Back to top
View user's profile Send private message
zpat
PostPosted: Tue Jul 24, 2012 6:33 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5867
Location: UK

Actually I described a xmit queue with the same name as the remote QMGR.

Whereas a QMgr alias is a remote queue with the same name as the remote queue manager. This is not needed for the method I described to work.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Jul 24, 2012 6:35 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

zpat wrote:
Actually I described a xmit queue with the same name as the remote QMGR.

Whereas a QMgr alias is a remote queue with the same name as the remote queue manager. This is not needed for the method I described to work.


Well, okay, there is that.
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Jul 24, 2012 6:48 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

bernard_fay wrote:
There is thousands of queues on the target QM. We would like to avoid to define each one of them on the source QM.


You see having the definitions of thousands of target queues coded into 1-n applications where you'll never find them again as a better solution? Where any change to the WMQ topology risks application stability?

You're saving time in the short term perhaps but at what cost? What will be your strategy when one of the application people comes to you and complains that the application sent a message and it never arrived? Tell them it's their responsibility to send the message & as WMQ admins it's nothing to do with you?

Also, you're not going to define thousands of remote queues. You're going to produce 1 script that defines thousands of remote queues.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Jul 24, 2012 8:33 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.

Vitor wrote:

Also, you're not going to define thousands of remote queues. You're going to produce 1 script that defines thousands of remote queues.

Creating QRemote definitions one-at-a-time is one possibility.

But, as Vitor suggests, you could build a script that reads as input the QLocal definitions (on the target qmgr), and creates as output QRemote definitions for use on the other 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
View user's profile Send private message
Vitor
PostPosted: Tue Jul 24, 2012 8:37 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

bruce2359 wrote:
But, as Vitor suggests, you could build a script that reads as input the QLocal definitions (on the target qmgr), and creates as output QRemote definitions for use on the other qmgr.




We can also postulate that whoever administers the other queue manager didn't define thousands of local queues one at a time. They could have accumulated over the years of course, but it's a sporting chance all or some of them are generated. It's a basis to work from.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Jul 24, 2012 8:43 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

bernard_fay:

You are highly encouraged to take a more analytical and systematic approach to this. You should spend a couple of hours at least sitting down and working out at least the skeleton of a deployment procedure for each solution as it affects the source queue manager.

This should integrate and be inline with your existing deployment procedures, and can potentially include things like scripts that process deployment descriptors and then automatically define relevant qremotes or etc.

If the concern is raised that you are not spending your time producing solutions, explain that you are spending a small amount of time up front to significantly reduce the amount of time every new solution takes.
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Jul 24, 2012 8:48 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

mqjeff wrote:
can potentially include things like scripts that process deployment descriptors and then automatically define relevant qremotes or etc.




Just be be absolutely clear, when I said "generated" this was exactly what I had in mind; a process that generates runmqsc script.

Of course, they could have all the scripts used over the years to build all the local queues. They could certainly obtain one....
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Jul 24, 2012 9:06 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.

The same scripting techniques could be used to back-up an existing qmgr, or to clone a new qmgr, for example.
_________________
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
bernard_fay
PostPosted: Tue Jul 24, 2012 9:32 am    Post subject: Reply with quote

Apprentice

Joined: 24 Jul 2012
Posts: 30

I am a bit confused here:

mqjeff, you said earlier:
Quote:
It's *one* qremote, not *one* qremote for *each* qlocal on the remote qmgr.


I understand from this that I could have one definition of a qremote to send messages to queues on the remote QM. Am I correct?

Then you said I could have a script to define relevant qremotes:
Quote:
include things like scripts that process deployment descriptors and then automatically define relevant qremotes


Why should I have a script, if I only need one qremote?

What we would like to have is a kind of passthru.

Understand that I am not the only one in the decision-making process for our MQ solution.

Thanks everyone for your help.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Jul 24, 2012 9:42 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

setting it up as a passthrough solves a simple problem - how to create lots of qremotes, but leaves a much larger problem of "what happens when something changes later".

So, yeah, you *can* just create a passthrough.

It makes it much harder to manage in the long run, and particularly makes it much harder to secure.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » General IBM MQ Support » sending messages without using remote queue definition
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.