| Author |
Message
|
| mqjeff |
 Posted: Tue Jul 24, 2012 6:32 am Post subject: |
 |
|
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 |
|
 |
| zpat |
| Posted: Tue Jul 24, 2012 6:33 am Post subject: |
|
|
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 |
|
|
| mqjeff |
| Posted: Tue Jul 24, 2012 6:35 am Post subject: |
|
|
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 |
|
|
| Vitor |
| Posted: Tue Jul 24, 2012 6:48 am Post subject: |
|
|
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 |
|
|
| bruce2359 |
| Posted: Tue Jul 24, 2012 8:33 am Post subject: |
|
|
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 |
|
|
| Vitor |
| Posted: Tue Jul 24, 2012 8:37 am Post subject: |
|
|
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 |
|
|
| mqjeff |
| Posted: Tue Jul 24, 2012 8:43 am Post subject: |
|
|
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 |
|
|
| Vitor |
| Posted: Tue Jul 24, 2012 8:48 am Post subject: |
|
|
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 |
|
|
| bruce2359 |
| Posted: Tue Jul 24, 2012 9:06 am Post subject: |
|
|
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 |
|
|
| bernard_fay |
| Posted: Tue Jul 24, 2012 9:32 am Post subject: |
|
|
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 |
|
|
| mqjeff |
| Posted: Tue Jul 24, 2012 9:42 am Post subject: |
|
|
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 |
|
|
|
|
