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 » RESOLVED-amqsputc is failing in mq 7.5

Post new topic  Reply to topic Goto page Previous  1, 2, 3  Next
 RESOLVED-amqsputc is failing in mq 7.5 « View previous topic :: View next topic » 
Author Message
exerk
PostPosted: Thu Oct 17, 2013 12:05 am    Post subject: Reply with quote

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
View user's profile Send private message
jeevan
PostPosted: Thu Oct 17, 2013 3:59 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Thu Oct 17, 2013 4:12 am    Post subject: Reply with quote

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
View user's profile Send private message
jeevan
PostPosted: Thu Oct 17, 2013 4:53 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Thu Oct 17, 2013 5:03 am    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Thu Oct 17, 2013 5:29 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
exerk
PostPosted: Thu Oct 17, 2013 5:31 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Thu Oct 17, 2013 5:38 am    Post subject: Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Thu Oct 17, 2013 5:40 am    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Thu Oct 17, 2013 5:46 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
exerk
PostPosted: Thu Oct 17, 2013 5:47 am    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Thu Oct 17, 2013 5:52 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
exerk
PostPosted: Thu Oct 17, 2013 5:57 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Thu Oct 17, 2013 5:58 am    Post subject: Reply with quote

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
View user's profile Send private message
jeevan
PostPosted: Thu Oct 17, 2013 6:42 am    Post subject: Reply with quote

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

MQSeries.net Forum Index » General IBM MQ Support » RESOLVED-amqsputc is failing in mq 7.5
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.