| Author |
Message
|
| sleepyjamie |
 Posted: Thu Aug 06, 2015 1:29 pm Post subject: Specify QMGR on MQ Input node? |
 |
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| It appears in IIB9 that I cannot specify the QMGR for an MQ Input node, however on an MQ Output node the setting exists? |
|
| Back to top |
|
 |
| ganesh |
| Posted: Thu Aug 06, 2015 3:24 pm Post subject: |
|
|
Master
Joined: 18 Jul 2010
Posts: 294
|
| You cannot specify a QM for input node in IIB9. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Aug 06, 2015 10:24 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
The MQOutput properties are related to objects (queues and channels etc) that are defined in the Queue Manager that the Broker is running on top of.
If you want true client connectivity for both Input and Output then you will have to go to IIB10.
Here you can specify the connection details that will allow you to GET and PUT messages from remote queue manager without definnig SDR/RCVR channels between the various queue managers.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Aug 06, 2015 10:39 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The output QM name refers to a little known feature of MQ, whereby you can MQOPEN a queue referring to another QM, providing a transmit queue matching that QM name exists on your local QM. Then MQ builds the xmit header and puts the message on the xmit queue. Of course you need a sender channel to that QM as well.
A bit like a remote queue definition, without the definition.
IIB 10's client connection feature is interesting, but it also opens up the possibility for developers to do stupid things like connecting a production flow to a test queue manager by accident (or vice-versa).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 07, 2015 4:15 am Post subject: Re: Specify QMGR on MQ Input node? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sleepyjamie wrote: |
| It appears in IIB9 that I cannot specify the QMGR for an MQ Input node, however on an MQ Output node the setting exists? |
The MQOuput node is still connecting to the broker's queue manager (like the MQInput node), it just allows you (through the property you describe) to specify a destination for the message. You'll observe that, while you can enter a name, you can't provide any details (like host name) where the MQOutput node could find this queue manager. Because it's using the locally bound one.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Fri Aug 07, 2015 7:11 am Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| smdavies99 wrote: |
The MQOutput properties are related to objects (queues and channels etc) that are defined in the Queue Manager that the Broker is running on top of.
If you want true client connectivity for both Input and Output then you will have to go to IIB10.
Here you can specify the connection details that will allow you to GET and PUT messages from remote queue manager without definnig SDR/RCVR channels between the various queue managers. |
Yeah that's what I suspected. Seems odd this feature hasn't been available until IIB10. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 07, 2015 9:28 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sleepyjamie wrote: |
| Yeah that's what I suspected. Seems odd this feature hasn't been available until IIB10. |
Why "odd", especially given the product's history and what (traditionally) it's used the queue manager for? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Fri Aug 07, 2015 10:25 am Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| Vitor wrote: |
| sleepyjamie wrote: |
| Yeah that's what I suspected. Seems odd this feature hasn't been available until IIB10. |
Why "odd", especially given the product's history and what (traditionally) it's used the queue manager for? |
Odd because I come from other messaging products where these restrictions didn't exist. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 07, 2015 11:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sleepyjamie wrote: |
Odd because I come from other messaging products where these restrictions didn't exist. |
Fair point.
IIB used to be called WMB, and before that was called MQSI for MQSeries Integrator - it was a bolt on for a queue manager. It used the queue manager for a lot of things, including it's own internal support processes.
Unwrapping that has taken more than a little effort. You may also assume that if there had been a howl of protest about the lack of this ability from either the user community or the IBM architects, it would have started earlier and been done years ago.
But it wasn't. Make of that what you will.
IBM decided to reposition as a true integration product, with no pre-reqs. Not a howl, but a growl.
IIBv10 allows it, but still needs a queue manager for some functions (see the IIBv10 InfoCenter for details). We may anticipate that now the ball has started rolling we may assume the eventual decoupling of the products.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Fri Aug 07, 2015 11:09 am Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| Vitor wrote: |
| sleepyjamie wrote: |
Odd because I come from other messaging products where these restrictions didn't exist. |
Fair point.
IIB used to be called WMB, and before that was called MQSI for MQSeries Integrator - it was a bolt on for a queue manager. It used the queue manager for a lot of things, including it's own internal support processes.
Unwrapping that has taken more than a little effort. You may also assume that if there had been a howl of protest about the lack of this ability from either the user community or the IBM architects, it would have started earlier and been done years ago.
But it wasn't. Make of that what you will.
IBM decided to reposition as a true integration product, with no pre-reqs. Not a howl, but a growl.
IIBv10 allows it, but still needs a queue manager for some functions (see the IIBv10 InfoCenter for details). We may anticipate that now the ball has started rolling we may assume the eventual decoupling of the products. |
Yeah historically I could see the reasoning because of the tight coupling between the products.
It's good they are breaking them apart, and I certainly understand it takes time and is also extremely risky.
All the better reason to skip IIB9 and go to 10  |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Aug 07, 2015 11:26 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
[
IIBv10 allows it, but still needs a queue manager for some functions (see the IIBv10 InfoCenter for details). We may anticipate that now the ball has started rolling we may assume the eventual decoupling of the products. |
It would appear that IIB10 allows you to overcome the restrictions of some versions of broker that allowed only one Execution Group but you could have as many brokers on a server as the PVU's would support.
Now you can have more than one broker working with a single Queue Manager.
Laws of unintended consequences and all that?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Aug 07, 2015 12:34 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
IIB 10 still comes with a license to use MQ on the same host.
Why not use the best transactional messaging product?
Of course if you want to lose or duplicate your data, go ahead and use http or ftp.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Mon Aug 10, 2015 5:43 am Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| For my case the requirement for connecting to another QMGR is because we have a few QMGRs on other networks behind firewalls for PCI compliance. So running IIB and MQ on the same machine is not feasible. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 10, 2015 5:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sleepyjamie wrote: |
| For my case the requirement for connecting to another QMGR is because we have a few QMGRs on other networks behind firewalls for PCI compliance. So running IIB and MQ on the same machine is not feasible. |
IIBv9 & below you're hosed. The broker won't even start without a queue manager. Unless you put IIBv9 behind the firewall as well.
More abstractly, the fact that you have PCI data behind a firewall is irrelevant. If you connect to those queue managers with any of the other products you mention (or IIBv10), then conceptually you're doing the same as a sender/receiver channel between these queue managers and the IIBv9 queue manager. There will of course be a claim that messages with PCI data could now be sitting in the IIBv9 queue manager outside the firewall, but that presents mostly the same security challenges as PCI data over a client connection ; no more, no less.
Security (and protecting data) is a strategy, not a product. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
