| Author |
Message
|
| exerk |
 Posted: Thu Oct 17, 2013 12:05 am Post subject: |
 |
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
| Did you unset the MQCHL* environment variables? |
No need to do so. In the connection method hierarchy the MQSERVER variable over-rides any setting of the MQCHL* variables - the CCDT never gets referenced.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
 |
| jeevan |
| Posted: Thu Oct 17, 2013 3:59 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| exerk wrote: |
| bruce2359 wrote: |
| Did you unset the MQCHL* environment variables? |
No need to do so. In the connection method hierarchy the MQSERVER variable over-rides any setting of the MQCHL* variables - the CCDT never gets referenced. |
I never set MQCHL* variables. I mentioned, that the /var/mqm/errors log file says, probably these variables could have missed.
This is what the log has:
AMQ9518: File '/var/mqm/AMQCLCHL.TAB' not found.
EXPLANATION:
The program requires that the file '/var/mqm/AMQCLCHL.TAB' is present and
available.
ACTION:
This may be caused by invalid values for the optional environment variables
MQCHLLIB, MQCHLTAB or MQDATA. If these variables are valid or not set then
record the name of the file and tell the systems administrator who must ensure
that file '/var/mqm/AMQCLCHL.TAB' is available to the program.
But as I mentioned, earlier, it know when I needed to set them. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 17, 2013 4:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Ok, so you forgot to export the MQSERVER variable, so it wasn't visible.
Since it wasn't visible, the client went looking for the CCDT, which it didn't find. |
|
| Back to top |
|
|
| jeevan |
| Posted: Thu Oct 17, 2013 4:53 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| mqjeff wrote: |
Ok, so you forgot to export the MQSERVER variable, so it wasn't visible.
Since it wasn't visible, the client went looking for the CCDT, which it didn't find. |
It is more of programming logic. why the code does not look for MQSERER first or at least when we get an error, it does not mention for MQSERVER but MQCHL* var, why it does not say anything about MQSERVER var? |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Oct 17, 2013 5:03 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| jeevan wrote: |
| It is more of programming logic. why the code does not look for MQSERER first or at least when we get an error, it does not mention for MQSERVER but MQCHL* var, why it does not say anything about MQSERVER var? |
Because of the hierarchy in what the Client code uses is clearly documented within the Info Centre. It's WMQ 101 that the MQSERVER variable always takes precedence over everything else so the code does 'look' for it first, but you could always raise an RFE to have the logs show what the Client code has enumerated through in its search for connection details.
Since WMQ V7.0 a lot moved into the mqclient.ini file and as far as I am concerned the use of the MQCHL* variables should be deprecated; they were no doubt left in because a lot of users wouldn't bother reworking their infrastructure to get rid of them.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Oct 17, 2013 5:29 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1964
Location: Bay of Plenty, New Zealand
|
| exerk wrote: |
| as far as I am concerned the use of the MQCHL* variables should be deprecated; they were no doubt left in because a lot of users wouldn't bother reworking their infrastructure to get rid of them. |
Yes, we always have problems removing stuff from MQ. I think we don't like the sounds of the screams from our customers when we do it. 
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Oct 17, 2013 5:31 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| hughson wrote: |
| Yes, we always have problems removing stuff from MQ. I think we don't like the sounds of the screams from our customers when we do it. |
Some people just want to watch the world burn... 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 17, 2013 5:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| Some people just want to watch the world burn... |
His name, is Michael Caine.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Oct 17, 2013 5:40 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| hughson wrote: |
| exerk wrote: |
| as far as I am concerned the use of the MQCHL* variables should be deprecated; they were no doubt left in because a lot of users wouldn't bother reworking their infrastructure to get rid of them. |
Yes, we always have problems removing stuff from MQ. I think we don't like the sounds of the screams from our customers when we do it. |
IMHO, the channel table files are a great way to do several things which may not be possible with the .ini solution (I've had no need to investigate so far)
firstly how do you specify what are the multiple servers that a client can connect to if one becomes unavailable where the MQ client libraries handles the reconnection.
Then there is setting the range of ports that a connection uses once the initial handshake with the listener has been done. some Cisco firewalls need this...
finally, they are difficult if not impossible for a 3rd party to edit. Text files are just open invitations to fiddle with if the connection does not succeed.
both methods have their place and for what my opinion might be worth (yeah, 2p or less) it helps to have a choice.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Oct 17, 2013 5:46 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1964
Location: Bay of Plenty, New Zealand
|
| smdavies99 wrote: |
| IMHO, the channel table files are a great way to do several things which may not be possible with the .ini solution |
I think what was being referred to was just the ability to indicate where the CCDT was but putting it in the mqclient.ini file instead of using the environment variables.
mqclient.ini file cannot on its own, replace the use of CCDT.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Oct 17, 2013 5:47 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| smdavies99 wrote: |
| IMHO, the channel table files are a great way to do several things which may not be possible with the .ini solution (I've had no need to investigate so far) |
I fully agree with you, but I think you may be misapprehending what the mqclient.ini file does, which is specify the location and name of the CCDT files and SSL key store related files. It's a lot more flexible than the MQCHL* and MQSSL* variables and, in the case of multiple discrete Client applications hosted on the same server, can actually abstract the requirement for those applications to set their environment at run time.
I thoroughly recommend to anyone still using the variables to give the appropriate section of the Info Centre a good read.
EDIT: Morag beat me to the punchline 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Oct 17, 2013 5:52 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1964
Location: Bay of Plenty, New Zealand
|
| exerk wrote: |
| EDIT: Morag beat me to the punchline |
Sorry 
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Oct 17, 2013 5:57 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| hughson wrote: |
| Sorry |
Me being a gent, ladies first...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 17, 2013 5:58 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| exerk wrote: |
| hughson wrote: |
| Sorry |
Me being a gent, ladies first... |
It's gotta be the tie. |
|
| Back to top |
|
|
| jeevan |
| Posted: Thu Oct 17, 2013 6:42 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| exerk wrote: |
| Since WMQ V7.0 a lot moved into the mqclient.ini file and as far as I am concerned the use of the MQCHL* variables should be deprecated; they were no doubt left in because a lot of users wouldn't bother reworking their infrastructure to get rid of them. |
I absolutely agree with you and I think IBM should not have a big issue of doing this. But it is upto them. |
|
| Back to top |
|
|
|
|
