ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » Can get amqsputc to use MQCHLLIB & MQCHLTAB to connect t

Post new topic  Reply to topic Goto page 1, 2  Next
 Can get amqsputc to use MQCHLLIB & MQCHLTAB to connect t « View previous topic :: View next topic » 
Author Message
hilltops
PostPosted: Tue Sep 18, 2007 3:53 am    Post subject: Can get amqsputc to use MQCHLLIB & MQCHLTAB to connect t Reply with quote

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
View user's profile Send private message
jefflowrey
PostPosted: Tue Sep 18, 2007 4:27 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Sep 18, 2007 4:28 am    Post subject: Reply with quote

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
View user's profile Send private message
hilltops
PostPosted: Tue Sep 18, 2007 5:00 am    Post subject: Reply with quote

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
View user's profile Send private message
Nigelg
PostPosted: Tue Sep 18, 2007 8:28 pm    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Sep 18, 2007 10:31 pm    Post subject: Reply with quote

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
View user's profile Send private message
hilltops
PostPosted: Wed Sep 19, 2007 2:31 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Sep 19, 2007 2:35 am    Post subject: Reply with quote

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
View user's profile Send private message
hilltops
PostPosted: Wed Sep 19, 2007 2:47 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Wed Sep 19, 2007 3:13 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
sebastia
PostPosted: Mon Sep 24, 2007 9:31 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
hilltops
PostPosted: Mon Sep 24, 2007 10:13 am    Post subject: Reply with quote

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
View user's profile Send private message
sebastia
PostPosted: Mon Sep 24, 2007 10:24 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
jefflowrey
PostPosted: Mon Sep 24, 2007 10:29 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

hilltops wrote:
Also important not to populate the queue manager attribute when you define the channels.


http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzaf.doc/amq25da.htm
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Mon Sep 24, 2007 4:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » General IBM MQ Support » Can get amqsputc to use MQCHLLIB & MQCHLTAB to connect t
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.