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 » WebSphere Message Broker (ACE) Support » Is it necessary to Create Qmgr when creating a broker

Post new topic  Reply to topic
 Is it necessary to Create Qmgr when creating a broker « View previous topic :: View next topic » 
Author Message
pandeg
PostPosted: Thu Jul 09, 2015 12:33 pm    Post subject: Is it necessary to Create Qmgr when creating a broker Reply with quote

Disciple

Joined: 21 Oct 2014
Posts: 195

Hi, I want to know that is it necessary that Broker should have associated Queue Manager with it and Input Node should point to local Queue. What if i want Input Node to point to Remote Q/ Xmit Q , rather than Local Queue.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Thu Jul 09, 2015 12:36 pm    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

You can't do an MQGet against a remote queue. You don't want to do an MQGet against an XMITQ, because the channel won't let you and even if it did, the channel wouldn't be able to send your messages.

You can use a queue manager that is not on the same machine as the broker with IIBv10 (unless I remember wrong). But you still won't be able to read from queues that aren't qlocals.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Jul 09, 2015 12:46 pm    Post subject: Reply with quote

Grand High Poobah

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

mqjeff wrote:
You can use a queue manager that is not on the same machine as the broker with IIBv10 (unless I remember wrong). But you still won't be able to read from queues that aren't qlocals.


Slightly wrong. IIBv10 allows MQ aware nodes to use client connections as with any other MQ aware application, so you can get and put from an remote queue manager not associated with the broker. See here.

If the OP is using IIBv9 or lower, you're entirely right and he's SOL.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Jul 09, 2015 12:48 pm    Post subject: Re: Is it necessary to Create Qmgr when creating a broker Reply with quote

Grand High Poobah

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

pandeg wrote:
What if i want Input Node to point to Remote Q/ Xmit Q , rather than Local Queue.


To underline the point made by my most worthy associate, nothing that isn't an MCA should ever point to an Xmitq. Not broker, not one of your apps, nothing.

Except in cases of dire emergency or you writing your own administration tool (which could be considered some kind of emergency).
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
inMo
PostPosted: Thu Jul 09, 2015 12:58 pm    Post subject: Reply with quote

Master

Joined: 27 Jun 2009
Posts: 216
Location: NY

Just mentioning that assuming v9 or lower, and the installation of the local, you would use MQ on the "remote" qmngr to get the message to the local where it would be read.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Is it necessary to Create Qmgr when creating a broker
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.