Author |
Message
|
hilltops |
Posted: Tue Sep 18, 2007 3:53 am Post subject: Can get amqsputc to use MQCHLLIB & MQCHLTAB to connect t |
|
|
Centurion
Joined: 01 Mar 2006 Posts: 112
|
I am trying to use the MQ client application amqsputc to connect to a queue manager using the channel definition table approach, but it is failing with error 2058. I am using MQ6. I set the env variables as follows;
export MQCHLLIB=/home/myname/channeltable
export MQCHLTAB=AMQCLCHL.TAB
The TAB file was copied from its default location to the directory given above. The channels were created on the queue manager as follows;
DEF CHANNEL(FDPD.SVRCONN.A) CHLTYPE(SVRCONN) TRPTYPE(TCP)
MCAUSER('myuser')
DEF CHANNEL(FDPD.SVRCONN.A) CHLTYPE(CLNTCONN) TRPTYPE(TCP)
CONNAME('A.B.C.D(10000)')
The user myuser has been given authorities to connect and access the queue manager and queues. There is also a listener running and listening on port 10000.
However, when I use the MQSERVER env variable, I am able to access the queue manager and queue. I set the MQSERVER variable as follows;
export MQSERVER=SYSTEM.DEF.SVRCONN/TCP/'A.B.C.D(10000)'
Incidentally, when I use a java code I wrote myself, targeting the exact same TAB file, I am able to connect to the queue manager. The java code has the code syntax to point to the TAB file;
java.net.URL chldefurl = null;
try
{
chldefurl = new URL("file:///home/myname/channeltable/AMQCLCHL.TAB");
}
catch(Exception e){
System.out.println("Malformed URL...Quiting");
System.exit(1);
}
try {
MQQueueManager qMgr = new MQQueueManager(qmgrName, chldefurl);
int openOptions = MQC.MQOO_OUTPUT ;
MQQueue reqQueue = qMgr.accessQueue(reqQName, openOptions);
MQMessage myMessage = new MQMessage();
myMessage.writeUTF("Testing");
Looks like there's something blindingly obvious I have missed out, but I just cannot put my finger on it. Can anyone spot it?
Thankx |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Sep 18, 2007 4:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Are you specifying the qmgrname on the invocation of amqsputc?
If you don't, then it can't find the qmgr by name and there might not be a default/wildcard specified in the chltab. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Sep 18, 2007 4:28 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Try adding a QMNAME parameter to the DEFINE CHANNEL. Your Java specifies which queue manager it's looking for, the channel atm does not. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
hilltops |
Posted: Tue Sep 18, 2007 5:00 am Post subject: |
|
|
Centurion
Joined: 01 Mar 2006 Posts: 112
|
Thanks guys,
I should have said the following;
1) I invoke the client application as such;
/opt/mqm/samp/bin/amqsputc TEST QMGRS
2) In my java code the queue manager name is actually blank.
I now invoked it without the queue manager field and it worked. I hadn't stopped to think about how to invoke it in view of the channel defintions.
/opt/mqm/samp/bin/amqsputc TEST
BTW, the queue manager name was deliberately left out of the channel definitions, so that this same TAB can be used to provide a fail-over to a secondary queue manager should the primary queue manager not be available.
Cheers guys. |
|
Back to top |
|
 |
Nigelg |
Posted: Tue Sep 18, 2007 8:28 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
Setting MQSERVER overrides the MQCHLLIB/TAB env vars. _________________ MQSeries.net helps those who help themselves.. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Sep 18, 2007 10:31 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
hilltops wrote: |
BTW, the queue manager name was deliberately left out of the channel definitions, so that this same TAB can be used to provide a fail-over to a secondary queue manager should the primary queue manager not be available. |
And the secondary queue manager listens on "A.B.C.D(10000)" as well does it? That's a trick!
If you've got an HA set up there are 2 main options:
1) Use HA software so "the queue manager" is presented on a single IP/port no matter where it happens to be running so the value in the TAB file is always true
2) Use the TAB file to define multiple instances of "THEQM" which identify QMA, QMB, etc,etc (I think this sounds more like you're attempting).
The Clients manual describes all this. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
hilltops |
Posted: Wed Sep 19, 2007 2:31 am Post subject: |
|
|
Centurion
Joined: 01 Mar 2006 Posts: 112
|
To complete the picture, I wanted to created a highly available gateway into our MQ infrastructure for MQ client applications without using a HA software like VCS. The gateway consists of two queue managers on two different servers, say QMGR_A and QMGR_B on server A and B respectively. QMGR_A will act as the primary gateway queue manager. Should QMGR_A become unavailable, QMGR_B should provide connectivity into the MQ network. Channels were defined as follows:
On QMGR_A, server A
DEF CHANNEL(FDPD.SVRCONN.A) CHLTYPE(SVRCONN) TRPTYPE(TCP)
MCAUSER('myuser')
DEF CHANNEL(FDPD.SVRCONN.A) CHLTYPE(CLNTCONN) TRPTYPE(TCP)
CONNAME('A.B.C.D(10000)')
DEF CHANNEL(FDPD.SVRCONN.B) CHLTYPE(CLNTCONN) TRPTYPE(TCP)
CONNAME('E.F.G.H(10000)')
On QMGR_B, server B
DEF CHANNEL(FDPD.SVRCONN.B) CHLTYPE(SVRCONN) TRPTYPE(TCP)
MCAUSER('myuser')
The TAB file from QMGR_A on server A is then located on the application machines where it is pointed to by the MQCHLLIB & MQCHLTAB env variable. The MQSERVER variable is left un-set.
Upon starting the client application, connection is achieved to QMGR_A, exactly as expected. When QMGR_A is shut down, connection is made to QMGR_B. That's why it is important not to specify the queue manager name in the channel definitions. Nor is it necessary to specify the queue manager name in the application code. MQ decides which queue manager to connect to based on the channel definitions.
Hope that makes it clearer. Conceptually, can anyone see any gotchas with this design?
Thankx
Last edited by hilltops on Wed Sep 19, 2007 2:42 am; edited 1 time in total |
|
Back to top |
|
 |
Vitor |
Posted: Wed Sep 19, 2007 2:35 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
hilltops wrote: |
MQ decides which queue manager to connect to based on the channel definitions. |
Are you saying it's now working then? You can connect to both queue managers?
hilltops wrote: |
Hope that makes it clearer. Conceptually, can anyone see any gotchas with this design? |
Nope, it's perfectly standard & I've done it myself. Typically including a QMNAME parameter but if it's working for you then well done!  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
hilltops |
Posted: Wed Sep 19, 2007 2:47 am Post subject: |
|
|
Centurion
Joined: 01 Mar 2006 Posts: 112
|
Yes, it is working fine now.
I thought it would be useful to flesh it out a bit in case it proved useful to someone else, or if there were any issues I have failed to consider in the design.
Thankx |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Sep 19, 2007 3:13 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
hilltops wrote: |
MQMessage myMessage = new MQMessage();
myMessage.writeUTF("Testing"); |
As an aside from the previous topic...
I hope that you are aware that the only method to read correctly the content of that message is myMessage.readUTF() ;  _________________ MQ & Broker admin |
|
Back to top |
|
 |
sebastia |
Posted: Mon Sep 24, 2007 9:31 am Post subject: |
|
|
 Grand Master
Joined: 07 Oct 2004 Posts: 1003
|
mr HillTops or Vitor !
Can you explain to me how does this work ?
(It is very very similar to what I need !!!)
1) First of all, lets make clear who's got which IP :
*) server A has IP = "A.B.C.D"
*) server B has IP = "E.F.G.H"
2) ok - we have deployed the "AMQCLCHL.TAB" file from the first server
into the Application's machine.
It's contents is at the end
3) server "A" is down,
and you say Applications Machine will connect to "server B".
The only way to do it is using statement [3] - am I right ?
mr hilltops : client will try connection to server A, [line [2]
then fail,
then auto-magically to server-B [line 3] ?
mr Vitor : why do you say
"And the secondary queue manager listens on "A.B.C.D(10000)" as well does it?"
============================
[1] DEF CHANNEL(FDPD.SVRCONN.A) CHLTYPE(SVRCONN) TRPTYPE(TCP)
MCAUSER('myuser')
[2] DEF CHANNEL(FDPD.SVRCONN.A) CHLTYPE(CLNTCONN) TRPTYPE(TCP) CONNAME('A.B.C.D(10000)')
[3] DEF CHANNEL(FDPD.SVRCONN.B) CHLTYPE(CLNTCONN) TRPTYPE(TCP) CONNAME('E.F.G.H(10000)') |
|
Back to top |
|
 |
hilltops |
Posted: Mon Sep 24, 2007 10:13 am Post subject: |
|
|
Centurion
Joined: 01 Mar 2006 Posts: 112
|
The idea is to provide a back-up queue manager in case the primary queue were unavailable. The TAB file is generated from the primary queue manager and copied to the machine hosting the MQ client application. The MQCHLLIB and MQCHLTAB are set to point to the directory and TAB file respectively. It is important to create the client end of the channel to the secondary queue manager on server B on the primary queue manager. That way, this end of client channel is contained in the TAB file. Also important not to populate the queue manager attribute when you define the channels.
The channel objects are defined are I set out above. Note that the two servers have different IP addresses. Vitor is wrong in stating that the IP are the same.
The channel selected for connections is by alphabetical order. Thus in my case FDPD.SVRCONN.A is select first and a connection attempt made. If that succeeds, then your applications has a connection to queue manager on server A. If this connection was not possible due to queue manager unavailability, channel FDPD.SVRCONN.B (which points to queue manager on server B) is selected and a connection attempt made to that queue manager.
The process is repeated until a successful attempt can be established. Or if no valid channels or connection can be made, then your application is refused connection altogether.
So it is important to tailor your channel names to reflect that order you want connections attempted.
Hope that helps. |
|
Back to top |
|
 |
sebastia |
Posted: Mon Sep 24, 2007 10:24 am Post subject: |
|
|
 Grand Master
Joined: 07 Oct 2004 Posts: 1003
|
Thanks, mr HillTop
Your sample has discovered to me the use of CLNTCONN !
I was happy living with MQSERVER envir var,
but that High Availability has opened my eyes.
Yes, there was a point in Vitor's message I did not understand ...
The IP's are OK as i said ?
There is another point I want to talk about :
*** the order the Table is scanned *** you say it is alphabetical ***
I wouldn't rely on this to define the cluster/system functioning ..
Here is what I have found :
( copy and paste from url = http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzak.doc/js02494.htm
The "line I want you to spot is "IN NO DEFINED ORDER" ...
Thanks again, to both of you.
==========================================
MQ client queue-manager groups:
If the specified name starts with an asterisk (*), the queue manager to which connection is made might have a different name from that specified by the application. The specified name (without the asterisk) defines a group of queue managers that are eligible for connection. The implementation selects one from the group by trying each one in turn (in no defined order) until one is found to which a connection can be made. If none of the queue managers in the group is available for connection, the call fails. Each queue manager is tried once only. If an asterisk alone is specified for the name, an implementation-defined default queue-manager group is used. |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Sep 24, 2007 10:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Sep 24, 2007 4:52 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
sebastia,
If you specify a blank QM name for the MQCONNX call, and the channel table was built with CLNTCONNs with blanks for the QMNames, then hilltops is correct, the channel will be searched by alphabetical order of the channel names.
Its this behaviour that allows the MQ admin to decide what will be the primary QM, what will be the secondary, etc. It is not random. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
|