| Author |
Message
|
| kblv |
 Posted: Wed Oct 12, 2011 12:06 am Post subject: Connect to remote Queue manager in java |
 |
|
Novice
Joined: 11 Oct 2011
Posts: 23
|
Hi,
Is there a way in java code to connect queue-manager on a remote machine, without specify the QM name?
I have the channel-name (SVRCONN type), the machine ip, and the port.
The idea is to run a java program that will scan list the servers in my system. All of the QMs are configured the same way (port, channel etc.) but the information about the amount and names of the QMs been lost.
I know I can run DSPMQ on each server but there are too many servers and I'm looking for an auto solution to run from time to time.
I need a solution that will work for MQ ver 5.3, 6, 7 and WIN + LINUX platforms.
thanks. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Oct 12, 2011 1:24 am Post subject: Re: Connect to remote Queue manager in java |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| kblv wrote: |
Hi,
Is there a way in java code to connect queue-manager on a remote machine, without specify the QM name?
I have the channel-name (SVRCONN type), the machine ip, and the port.
The idea is to run a java program that will scan list the servers in my system. All of the QMs are configured the same way (port, channel etc.) but the information about the amount and names of the QMs been lost.
I know I can run DSPMQ on each server but there are too many servers and I'm looking for an auto solution to run from time to time.
I need a solution that will work for MQ ver 5.3, 6, 7 and WIN + LINUX platforms.
thanks. |
As you have all the specific information (hostname, channel, port) you don't HAVE to specify the qmgr name. What have you tried and to what result? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kblv |
| Posted: Wed Oct 12, 2011 1:50 am Post subject: |
|
|
Novice
Joined: 11 Oct 2011
Posts: 23
|
| If I don't specify the qmgr name, it connect to the default QMGR, but in some of my servers there are several QMGRs and I can't connect to a QMGR other than the default one. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 12, 2011 3:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kblv wrote: |
| If I don't specify the qmgr name, it connect to the default QMGR, but in some of my servers there are several QMGRs and I can't connect to a QMGR other than the default one. |
The hostname, channel name, and listener port specifies a unique address that identifies exactly one queue manager - since a listener is uniquely tied to a single queue manager and must be listening on a unique hostname/port combination.
If you are specifying the hostname, channel, port and you are connecting to a queue manager that is not the queue manager you are expecting, that is a 'default' qmgr, then the hostname, channel, and port belong to that queue manager.
If you are connecting to a default qmgr on the same machine as your program, when you do not specify a qmgr name, then you are NOT specifying a hostname, channel, and port. |
|
| Back to top |
|
|
| kblv |
| Posted: Wed Oct 12, 2011 3:38 am Post subject: |
|
|
Novice
Joined: 11 Oct 2011
Posts: 23
|
| Quote: |
| If you are specifying the hostname, channel, port and you are connecting to a queue manager that is not the queue manager you are expecting, that is a 'default' qmgr, then the hostname, channel, and port belong to that queue manager. |
If I specify a port+chl+ip it connect to the def-QM only if the port is correct, otherwise it's throw exception - although there is a qmgr (not the default one) listening to that port.
Basicly it's seems like the port+chl+ip combination it's only good enough to connect to the default qmgr and no other qmgr.
Please prove me wrong...
 |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 12, 2011 5:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kblv wrote: |
| Basicly it's seems like the port+chl+ip combination it's only good enough to connect to the default qmgr and no other qmgr. |
the port, channel, and IP specifies a unique address to a specific queue manager. It contains no notion of whether that queue manager is the default queue manager or not.
If you have defined a queue manager Q on host A with a listener on Port B and a SVRCONN C, and you properly establish an MQ client connection to C/TCP/A(B), and you have found that you are connected to qmgr X instead of qmgr Q, then you have NOT DONE THINGS CORRECTLY.
| kblv wrote: |
| Please prove me wrong.. |
I have nothing to prove to you.
I know that you are wrong.
I assert that you are wrong.
I assert that the documentation states that you are wrong. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 12, 2011 5:42 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| If you have defined a queue manager Q on host A with a listener on Port B and a SVRCONN C, and you properly establish an MQ client connection to C/TCP/A(B), and you have found that you are connected to qmgr X instead of qmgr Q, then you have NOT DONE THINGS CORRECTLY. |
In the same way if you perform this operation and instead of getting an connection you get an exception, something is not correct.
The key fact missing from your post is what exception you're getting when you fail to correct to a queue manager. There will be a linked exception containing the reason code being thrown; investigate this and resolve it.
Most likely it's a 2059 in which event the problem may not be your code. One theory which occurs to me from your description is that whereever you're running this Java, the network only allows access to the port of the default queue managers, hence that's the only one you're getting access to. This theory could be utterly, utterly wrong.
Investigate the problem. You are wrong that the port+chl+ip only works on default queue managers. The documentation does say this.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 12, 2011 7:40 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| kblv wrote: |
| Quote: |
| If you are specifying the hostname, channel, port and you are connecting to a queue manager that is not the queue manager you are expecting, that is a 'default' qmgr, then the hostname, channel, and port belong to that queue manager. |
If I specify a port+chl+ip it connect to the def-QM only if the port is correct, otherwise it's throw exception - although there is a qmgr (not the default one) listening to that port.
Basicly it's seems like the port+chl+ip combination it's only good enough to connect to the default qmgr and no other qmgr.
Please prove me wrong...
|
So what is the connection type (TCP MQ Client?)
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 12, 2011 8:25 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| kblv wrote: |
| Quote: |
| If you are specifying the hostname, channel, port and you are connecting to a queue manager that is not the queue manager you are expecting, that is a 'default' qmgr, then the hostname, channel, and port belong to that queue manager. |
If I specify a port+chl+ip it connect to the def-QM only if the port is correct, otherwise it's throw exception - although there is a qmgr (not the default one) listening to that port.
Basicly it's seems like the port+chl+ip combination it's only good enough to connect to the default qmgr and no other qmgr.
Please prove me wrong...
|
So what is the connection type (TCP MQ Client?) |
If it wasn't, could the OP even get to the default queue manager on a remote box?
Java. Bah Humbug.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 12, 2011 9:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| If it wasn't, could the OP even get to the default queue manager on a remote box? |
The OP hasn't clearly stated that "the default qmgr" is actually on a remote box. |
|
| Back to top |
|
|
| kblv |
| Posted: Fri Oct 14, 2011 3:43 am Post subject: |
|
|
Novice
Joined: 11 Oct 2011
Posts: 23
|
OK,
after recheck you all where right,
and I solved my problem.
(Much simpler than i thought)
Thanks.
 |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 14, 2011 4:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kblv wrote: |
| after recheck you all where right, |
It may not seem it sometimes, but we 3, we happy 3, we band of brothers, do know what we're talking about. Nearly always.
| kblv wrote: |
and I solved my problem.
(Much simpler than i thought) |
Well good for you!
Care to share for the benefit of future readers? This kind of audit task is a wheel most sites seem to reinvent constantly.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kblv |
| Posted: Sun Oct 23, 2011 10:16 pm Post subject: |
|
|
Novice
Joined: 11 Oct 2011
Posts: 23
|
Well my solution is very simple (maybe not the smartest one..), just to remind, what I needed is a scanner that gets ip and scan for the QMGRs on this machine (assuming that I know the QM ports range, and for each QMGR there is a server-connection channel with the same name).
| Code: |
public String scan(String host, int port, String channel){
String qmgr;
try {
PCFAgent agent = new PCFAgent(host,port,channel);
qmgr = agent.getQManagerName();
return qmgr;
} catch (MQDataException e) {
}
return null;
} |
for the momoent its works fine, but if anyone has some better solution I'll glad to here. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 24, 2011 4:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kblv wrote: |
| if anyone has some better solution I'll glad to here. |
One better solution is to have proper procedures round the creation of queue managers so that the information you're trying to extract exists in a document repository.
This is a simple extension of the procedures you'll need to make this solution work. As you correctly point out, if a queue manager on the estate doesn't follow the convention of a SVRCONN named for the queue manager (and in my experience such channels are named for the applications using them to make problems easier to handle) and/or doesn't use a port in the range you expect then your solution will fail to identify that queue manager.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kblv |
| Posted: Mon Oct 24, 2011 4:57 am Post subject: |
|
|
Novice
Joined: 11 Oct 2011
Posts: 23
|
Well there is no doubt that your way is the best way to work,
but the fact is that although we have such procedure to document each QMGR when its been created, we found out there is QMGRs that not in the QMGR-repository...
in my case I'm can be pretty sure that all of the QMGRs have configured correctly with chl+port. |
|
| Back to top |
|
|
|
|
