| Author |
Message
|
| jefflowrey |
 Posted: Fri Sep 17, 2004 8:19 am Post subject: MS0B doesn't need QM name? |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I've been playing around with MS0B - the Java PCF classes.
I have found, accidentally almost, that none of these classes seem to need a queue manager name.
This seems... odd... to me. It would imply that either the classes are doing something very strange and talking directly to the command server (which wouldn't then use PCF Messages...?).
Or you don't need a queue manager name from Java.
Am I missing something? Or confused about the importance of a queue manager name when making a connection?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri Sep 17, 2004 8:44 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You don't need a QM name if the QM on the server is designated as the default queue manager. Are your apps only connecting to default QMs? If yes, no QM name is required on the MQCONN.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bower5932 |
| Posted: Fri Sep 17, 2004 8:53 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
I'm not an MS0B expert, but I just looked at the DumpBroker.java program on:
http://www.developer.ibm.com/tech/sampmq.html
The prologue indicates that it needs both MS0B and MA0C. It has the following code at the beginning:
| Code: |
qMgr = new MQQueueManager (qMgrName);
brokerQueue = qMgr.accessQueue (commandQueue,
MQC.MQOO_OUTPUT, "", "", "mqm");
|
So, it needs the (optional) qMgrName to know where to connect. If none is specified (ie, ""), then you get the default. The classes are then used to build messages which are put againt the brokerQueue.
Is this what you were asking? |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Sep 17, 2004 8:59 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
True, for the PCFMessageAgent class in client mode you don't specify the queue manager name but in binding mode you do.
I figured Chris knows what he's doing, so I haven't torn apart the PCF jar files.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Sep 17, 2004 9:34 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm gonna put one message with three replies...
Peter - it doesn't matter if the queue manager is the default or not, as long as I use a client connection (as Roger said). I can get the right values connecting to either of the queue managers on my machine (only one of which is a default) WITHOUT specifying a queue manager name.
Ron - That's not what I was asking. That's the option with MS0B to manage the Queue Manager connection yourself, rather than having the PCFAgent manage the connection.
Roger - That's still just plain weird, and is the heart of my question. If one is making a Java client connection, does one need to specify a Queue Manager name or not? If not ... is that also true of the regular client?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 17, 2004 9:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I guess a Java Client is very specific about what it wants to connect to, prior to issuning the MQCONN, in that it needs to specify the MQEnvironment class. In that class is a port number and channel name, the combination of which can only exist on one QM on that server. Actually, the port number alone is specific enough.
So maybe a Java client (and probably a .NET client?) by specifying the port # to go to is satisfying the need to specify which QM adequatly, and thus the QM name is optional? But in bindings mode, that is not true, so you need the QM name?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Sep 17, 2004 9:42 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If specifying the host, port and channel is sufficient to uniquely identify a queue manager (which, you know, it really *should* be), then it should be true of all the clients and not just one.
Also, I think the .Net client is not a standalone implementation yet, it's still just a wrapper for the C client.
The MQSERVER environment variable tends to support this theory - in that it only specifies a SVRCONN/PROTOCOL/host(port).
Time to play around with amqsputc.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| clindsey |
| Posted: Fri Sep 17, 2004 2:20 pm Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
| Quote: |
Time to play around with amqsputc.
|
You may want to play with amqscnxc as well. It does an MQCONNX call which may be closer to using MQEnvironment. I just tested this and the connection is also based on the port number.
The only required parm is -x host(port). The default svrconn channel is SYSTEM.DEF.SVRCONN. Queuemgr is also optional. If you have two queue managers running, just vary the port in the conname parm and you will alter the qmgr that is connected.
Charlie |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Sep 17, 2004 4:29 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
That bears out what I saw with amqsputc.
Ergo, if you're making a client connection, you don't need a queue manager name, at all, ever.
If you're making a bindings connection, you do. At least in some cases. I would think that if there were only one queue manager on the machine, you wouldn't... but I bet that the APIs don't let you do that unless the single queue manager is also the default queue manager.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 17, 2004 6:11 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I wonder if that is documentd somewhere, because it would be nice to tell developers that they can eliminate that parameter from their ini file, if only we could know that IBM specifically intended this (and documented it).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Sep 18, 2004 4:01 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I recall seeing something vague in one of the manuals about always using blank for the queue manager name for client connections. But it didn't click at the time and I don't remember where it was.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| KeeferG |
| Posted: Fri Dec 03, 2004 3:02 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
You have never needed to specify a queue manager name with a client connection as the connection is always performed on the channel. If yyou specify a queue manager name then when the channel starts the client will see if it is the correct queue manager and if not then close the channel. Leaving the queue manager name blank simply removes this final check.
The reason for this is that this allows a single channel name to talk to multiple queue managers. Adding the queue manager name to the connection would prevent this feature
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
|
|
