| Author |
Message
|
| mqrules |
 Posted: Thu Sep 21, 2006 11:44 am Post subject: CLNTCONN channel question |
 |
|
Centurion
Joined: 01 Jun 2005
Posts: 100
Location: US
|
Hi All,
MQ5.3 on Windows and Solaris...
I have 3 apps (there will be more) on the same server (windows 2000) that will Client-connect to the QM1 qmgr on Solaris. They will send and recive 10MB msgs.
I have to give each app a different SVRCONN channel (this is a requirement).
I have created 3 SVRCONN channels called APP1-CL, APP2-CL, APP3-CL on QM1 and set the MAXMSGL=10mb. On the MQClient machine, I don't want to use MQSERVER as it limits the msg length to 4MB. I don't think I can use channel table as all of the channels are pointing to the same qmgr.
So, if I create 3 CLNTCONN channels on QM1 with the same name as the SVRCONN channels (.i.e. APP1-CL, APP2.CL, APP3.CL), and set the MAXMSGL to 10MB on CLNTCONN channnels and let the app specify only, like "channel-name=APP1-CL, TRPTYPE=TCP, CONNAME=connectionName and port number)" in MQCD, would it pick the MAXMSGL form the CLNTCONN definition on QM1?
Or should I forget about defining the CLNTCONN channel and let it be defined in the MQCD?
What is the best way to handle this?
Your help would be much appreciated.
Thanks!!!!
MR |
|
| Back to top |
|
 |
| mqrules |
| Posted: Thu Sep 21, 2006 11:48 am Post subject: |
|
|
Centurion
Joined: 01 Jun 2005
Posts: 100
Location: US
|
I made a spelling mistake in the SVRCONN and CLINETCONN channels. But, please assume that they match  . Thx!!!
MR |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Sep 21, 2006 12:46 pm Post subject: Re: CLNTCONN channel question |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqrules wrote: |
Or should I forget about defining the CLNTCONN channel and let it be defined in the MQCD?
What is the best way to handle this? |
CLNTCONN channel defs are on the client. ( Yes, you can create them on the server, but that's not where they're used... unless in the special case where the client and server are the same machine  )
1. Please explain again why you can't use a client channel definition table containing the 3 CLNTCONN defs. I didn't understand why you chose not to do that.
2. Yes you can programmatically use MQCD in the apps. But then your apps will either have to hard-code connectivity details or else read them from a database or filesystem somewhere for future extensibility.
Hope this helps. |
|
| Back to top |
|
|
| mqrules |
| Posted: Thu Sep 21, 2006 1:00 pm Post subject: |
|
|
Centurion
Joined: 01 Jun 2005
Posts: 100
Location: US
|
Thanks mvic for the response.
I was not quite sure about the need for the the use of chanel table as all the CLient channels will be pointing to the same qmgr. I have used chltab for connecting to different qmgrs... I think I was a bit confused. Now that I am thinking a bit clearly, I think I should create a channel tab. Then the app should specify the Channel-name and qmgr name to connect. Right? If I specify the qmgrName in the CLNTCONN channel then, all app to do is specify the channel-name (e.g. APP1.CL) not the qmgr name as the qmgr name will be in the channel definiton. Correct?
Thanks again.
MR |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Sep 21, 2006 1:16 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqrules wrote: |
| If I specify the qmgrName in the CLNTCONN channel then, all app to do is specify the channel-name (e.g. APP1.CL) not the qmgr name as the qmgr name will be in the channel definiton. Correct? |
Even Grand Masters need to check the manuals...
Try http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzaf.doc/amq25ds.htm
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzaf.doc/amq25da.htm
If ( note if... this is not a subject I know very well, apologies  ) you can't use a single channel table for connecting to the same qmgr using 3 different channels) you could have 3 different channel tables, specified differently in the environments of the 3 apps using MQCHLTAB as in the first link above.
To create 3 client channel tables:
1. on the server, define the CLNTCONN channel
2. save a copy of the table. This is copy 1
3. define the CLNTCONN channel again, with new details
4. save a copy of the table. This is copy 2
5. define the CLNTCONN channel again, with new details
6. save a copy of the table. This is copy 3
... these 3 channel tables can be transferred to the client, and given distinct names - eg. channeltable1, channeltable2, channeltable3 - just use the MQCHLTAB env var to tell the app which one to use. |
|
| Back to top |
|
|
| mqrules |
| Posted: Thu Sep 21, 2006 1:25 pm Post subject: |
|
|
Centurion
Joined: 01 Jun 2005
Posts: 100
Location: US
|
mvic,
I thought about doing exactly that. But I have 3 apps on the same machine-1 trying to connect to qmgr QM1 on machine-2. I can only set, on machine-1, the Env variable MQCHLLIB to point to only one directory, and MQCHLTAB to only one chltab. So, what to do?
Thanks.
MR |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Sep 21, 2006 1:31 pm Post subject: |
|
|
Guest
|
You can use single channel table to establish a variety of connection options - including multiple connections to the same qmgr. Usually this is done to enable multiple listeners (in case one goes dead) or multiple transport protocols.
You create the table on the server (with all the possible connections); then export it to the client; then set the environment variables.
The application programmer can 'pick' the right qmgr connection (at MQCONN) - specifically or generically or first-available. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Sep 21, 2006 1:39 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqrules wrote: |
| the Env variable MQCHLLIB to point to only one directory, and MQCHLTAB to only one chltab. So, what to do? |
Each process has its own environment.
So, for example, start app 1 from a .bat program thus:
| Code: |
@echo off
setlocal
set MQCHLLIB=whatever
set MQCHLTAB=channeltable1
c:\myprogramdir\myprogram.exe |
and start app 2 from a .bat program thus:
| Code: |
@echo off
setlocal
set MQCHLLIB=whatever
set MQCHLTAB=channeltable2
c:\myprogramdir\myprogram.exe |
There are, of course, other ways of setting the environment - eg. if writing in C or C++, you can call the Win32 function SetEnvironmentVariable() before the call to MQCONN or MQCONNX. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Sep 21, 2006 1:41 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| You can use single channel table to establish a variety of connection options - including multiple connections to the same qmgr. Usually this is done to enable multiple listeners (in case one goes dead) or multiple transport protocols. |
But the MQCONN or MQCONNX will only use the first match for the qmgrname it finds in a linear scan of the table - I think. (Please correct me if I'm wrong.) This doesn't meet mqrules's Requirement for each app to use a different port for the same qmgr I think. |
|
| Back to top |
|
|
| mqrules |
| Posted: Thu Sep 21, 2006 1:53 pm Post subject: |
|
|
Centurion
Joined: 01 Jun 2005
Posts: 100
Location: US
|
Thanks for the responses...
mvic: I was thinking just now exactly what you suggested... having a .bat file to set the env variables... I just needed some coffee...
However, I would have another problem: When I create the CLNTCONN channels on the same qmgr they will all get put on the same AMQCLCHL.TAB. This would be OK for the first channel (assuming there is no other channel apart from de default one in the AMQCLCHL.TAB). I could then copy and rename it CHLTAB1. But when I create the 2nd CLNTCONN on the same qmgr, it will get added to the same AMQCLCHL.TAB... which I would not want.
In the mainframe it is very easy to create separate channel tables having specific clntconn channels on the SAME qmgr. But I don't know how to do this on the distributed platform.
Any ideas?
MR |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Sep 21, 2006 1:54 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Sorry, I haven't read this thread in detail, but I feel compelled to add :
1. If you do use channel tables, the application uses MQCONN (MQCONNX not needed) and only specifies the qmgr-name, never the channel name.
2. You can specify a QMNAME on the clntconn definition THAT IS DIFFERENT THAN THE QMGR YOU WANT TO CONNECT, if you specify the qmgname name starting with an "*"... I've written here (mqseries.net, that is) about that capability before and it really does give you a lot of flexibility.
3. the match by MQNAME is alphabetical by channel name
4.
| Quote: |
| There are, of course, other ways of setting the environment - eg. if writing in C or C++, you can call the Win32 function SetEnvironmentVariable() before the call to MQCONN or MQCONNX. |
No, I don't believe that correct. We've tried that in the past (10 yrs ago maybe) and it didn't work then, I think its an issue of scope of the env variables ....
_________________
-wayne |
|
| Back to top |
|
|
| mqrules |
| Posted: Thu Sep 21, 2006 1:56 pm Post subject: |
|
|
Centurion
Joined: 01 Jun 2005
Posts: 100
Location: US
|
Maybe what I should do is have a back-up of the AMQCLCHL.TAB file, and use it every time I need a different channel file.
MR |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Sep 21, 2006 1:59 pm Post subject: |
|
|
Guest
|
CLNTCONN definitions can include a QMNAME name. Take a look at MQSC manual.
MQCONN from the client application can specify a specific qmgr (MQCONN QM1) or a generic (MQCONN *INNER) or no qmgr (MQCONN ' ').
In the first case, the channel table QMNAME will be searched for an exact match of QM1 that answers up (listener running, qmgr running, ...).
In the second case, the client table QMNAME will be searched for any qmgr called INNER.
In the last case, the first qmgr (listener) that answers up will be the one the channel connects to. |
|
| Back to top |
|
|
| mqrules |
| Posted: Thu Sep 21, 2006 2:31 pm Post subject: |
|
|
Centurion
Joined: 01 Jun 2005
Posts: 100
Location: US
|
Wayne,
| Quote: |
Quote:
There are, of course, other ways of setting the environment - eg. if writing in C or C++, you can call the Win32 function SetEnvironmentVariable() before the call to MQCONN or MQCONNX.
No, I don't believe that correct. We've tried that in the past (10 yrs ago maybe) and it didn't work then, I think its an issue of scope of the env variables ....
_________________
|
I have tired this On Windows and it worked. I created a .bat file to set the MQSERVER and then ran the amqsputc. So, if it works for MQSERVER then it should work MQCHLTAB/MQCHLLIB also.
MR |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Sep 21, 2006 3:40 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| mqrules wrote: |
Wayne,
| Quote: |
Quote:
There are, of course, other ways of setting the environment - eg. if writing in C or C++, you can call the Win32 function SetEnvironmentVariable() before the call to MQCONN or MQCONNX.
No, I don't believe that correct. We've tried that in the past (10 yrs ago maybe) and it didn't work then, I think its an issue of scope of the env variables ....
_________________
|
I have tired this On Windows and it worked. I created a .bat file to set the MQSERVER and then ran the amqsputc. So, if it works for MQSERVER then it should work MQCHLTAB/MQCHLLIB also.
MR |
No, thats not what I think mvic is suggesting ...his idea was to dynamically set those variables by using a Windows call SetEnvironmentVariable() from WITHIN the same program that would then make the MQCONN... I don't think THAT will work...but, of course, you should try it and let us know....
_________________
-wayne |
|
| Back to top |
|
|
|
|
