| Author |
Message
|
| George Carey |
 Posted: Tue Sep 11, 2012 2:35 pm Post subject: C++ and XMS and MI QMGRS |
 |
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Have customer with C++ clients talking to MQ QMGR using XMS API.
All is working fine. They have switched to MI Qmgrs and wish to test how to switch back and forth between the two instances of the QMGRs.
How, and what is best/easiest way to allow the C++ client to switch from one QMGR to the other QMGR on a failover. Can then hardcode something into the Connection Factory attributes/options to do it ? Can they use CCDT table file (not sure JMS API recognizes a CCDT table does it?)
Any thoughts, suggestion appreciated.
TIA
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Sep 11, 2012 4:51 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| If they're not using an XMS Managed Connection, then the MQ client will handle the automatic reconnect for them, provided they've built their app against at least 7.0.1 XMS libs. |
|
| Back to top |
|
|
| George Carey |
| Posted: Tue Sep 11, 2012 5:30 pm Post subject: xms managed connection |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Please expound on that ... they will be using v7.1 libraries.
How do the C++ XMS clients know to reconnect to a different IP address unless directed via a CCDT or MQSERVER env variable or some such mechanism.
MI has active QM_A on IP1 Port1 and passive QM_A on IP2 Port1 where/how is the IP2 found for the reconnect?
Also what is a managed XMS connection ... we are not talking any app servers here.
TIA
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Sep 11, 2012 6:49 pm Post subject: Re: xms managed connection |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| George Carey wrote: |
Please expound on that ... they will be using v7.1 libraries.
How do the C++ XMS clients know to reconnect to a different IP address unless directed via a CCDT or MQSERVER env variable or some such mechanism.
MI has active QM_A on IP1 Port1 and passive QM_A on IP2 Port1 where/how is the IP2 found for the reconnect?
Also what is a managed XMS connection ... we are not talking any app servers here.
TIA |
There is a new parm for the connection factory that allows for MI.
Otherwise the right channel tab should make it work too. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| George Carey |
| Posted: Tue Sep 11, 2012 7:11 pm Post subject: new MI con factory parm |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Great this new parm is part of the XMS API? Not a standard JMS/XMS thing I would think.
Happen to have a link?
Also what does 'the right channel tab ...  ', mean ... you think or you know?
Can normal Java programs using JMS API use CCDT ? If so XMS should.
Rgrds
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Sep 11, 2012 7:18 pm Post subject: Re: new MI con factory parm |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| George Carey wrote: |
Great this new parm is part of the XMS API? Not a standard JMS/XMS thing I would think.
Happen to have a link?
Also what does 'the right channel tab ... ', mean ... you think or you know?
Can normal Java programs using JMS API use CCDT ? If so XMS should.
Rgrds |
JMS can use a CCDT since MQ V6! Welcome to progress...
What I meant by right channel tab is one created with V7.01 and having the failover info...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| George Carey |
| Posted: Tue Sep 11, 2012 8:06 pm Post subject: java coder |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
| Quote: |
| JMS can use a CCDT since MQ V6! Welcome to progress... |
Obviously I am not a Java Developer. Do have to code a test program or two in Java from time to time, however, but haven't use CCDT with it. I thought JMS clients could use CCDT but not having done it ... couldn't recall for sure. Thanks for the version feature memory refresh. I will have to read up on details.
What about the MI parm in connection factory ... does it afford the functionality in my original question? (i.e. switching between two different IPed QMGRs?)
Finally, customer is using v7.1 you typed v7.01 assumedly meaning 7.0.1 ... anything significantly pertinent to this discussion that is relevant to 7.0.1 as opposed to 7.1.x ?
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Tue Sep 11, 2012 8:54 pm Post subject: xms |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
XMS Connection Factory parameters, have nothing about and MI parameter,
but there is this ... is this what you are referring to ?
XMSC_WMQ_CONNECTION_NAME_LIST
Data type:String
Property of:ConnectionFactory
This property specifies the hosts to which the client attempts to reconnect to after its connection are broken.
The connection name list is a comma-separated list of host/ip port pairs. The default setting for this property is WMQ_CONNECTION_NAME_LIST_DEFAULT.
For example,127.0.0.1(1414),host2.example.com(1400)
The default setting of this property is localhost(1414).
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Tue Sep 11, 2012 9:13 pm Post subject: other parms |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Apparently a few other params that go with this as well:
CCDTURL , and others.
http://www-01.ibm.com/support/docview.wss?uid=swg21508357
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed Sep 12, 2012 3:07 pm Post subject: input |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
So we are done responding on any of these questions prior to my last two updates?
Rgrds
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 12, 2012 4:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
No, but you were doing very well finding the correct answers by yourself.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed Sep 12, 2012 9:48 pm Post subject: a quick non sequitur |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
A quick non-sequitur:
A client security concern(thinking outloud) ... for an XMS, JMS or whatever type of MQ client, if I am an admin(call me Badmin) on some box windows, linux what have you on a network that can get access(ping) some box that I know has a QM by some known name say ABC, then I can get cart blanche access to every QMGR object on that ABC QM if the MQ admin leaves the SYSTEM.DEF.SVRCONN without a blocking MCAUSER name.
OAM settings on the objects or not would be meaningless. As the Badmin could just create a user called 'mqm' and client connect via SYSTEM.DEF.SVRCONN and do what ever his code may wish to do on any ABC object.
I haven't thought about the full impact of that for some time.
That is true is it not ??
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 13, 2012 5:13 am Post subject: Re: a quick non sequitur |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| George Carey wrote: |
| That is true is it not ?? |
Except at v7.1 and later where channels are secured against remote administration by default. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 13, 2012 5:16 am Post subject: Re: a quick non sequitur |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| George Carey wrote: |
| I can get cart blanche access to every QMGR object on that ABC QM if the MQ admin leaves the SYSTEM.DEF.SVRCONN without a blocking MCAUSER name. |
In the same way someone can get carte blanche access to your house if you don't bother to close or lock the door.
| George Carey wrote: |
| OAM settings on the objects or not would be meaningless. As the Badmin could just create a user called 'mqm' and client connect via SYSTEM.DEF.SVRCONN and do what ever his code may wish to do on any ABC object. |
If the admin for the box has not taken the correct precautions to properly secure the queue manager. Again, if you lock the door of your house but leave a window wide open you'll still give people carte blanche access.
| George Carey wrote: |
| That is true is it not ?? |
It's less true in QMQv7.5 where mqm access is less godlike, but even in that it relies on security being set up properly. If the admin opens up mqm access you're back where you started.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu Sep 13, 2012 8:48 pm Post subject: v7.1 |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Yes, 7.1 has much better security features.
Can one in v7.1 block all incoming IPs excepting some ?
Kind of like the setmqaut syntax "-all +inq +connect" for authorizations.
I read in the doco that one can only block a list of IPs.
TIA
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
|
|
