| Author |
Message
|
| Sue_2828 |
 Posted: Fri Apr 17, 2009 11:04 pm Post subject: another MQ client question :D |
 |
|
Apprentice
Joined: 14 Feb 2009
Posts: 37
|
Guys,
I have both MQserver and MQclient installed on the same windows machine. When I try to do "amqsputc" I keep getting the following error :
MQCONN ended with reason code 2059
I have both variables for mqchllib and mqchltab sat correctly. Also, the client connection channel is created. when I do "amqsput" it works fine bu t not for "amqsputc" . Is this because I have both client and server running on the same box ? |
|
| Back to top |
|
 |
| Al Pacino |
| Posted: Fri Apr 17, 2009 11:29 pm Post subject: |
|
|
Centurion
Joined: 19 Aug 2005
Posts: 114
|
Error <2, 2059> may indicate an incorrect MQSERVER environment setting.
Did you set the MQserver variable ?
If so , make sure you have the correct IP address , the correct port and also make sure the listener is running?
It is OK to have both MQclient and MQserver on the same machine, and you should be able to do "amqsputc" if you have everything configured right .
Al
_________________
"We can't solve problems by using the same kind of thinking we used
when we created them." |
|
| Back to top |
|
|
| Sue_2828 |
| Posted: Fri Apr 17, 2009 11:45 pm Post subject: |
|
|
Apprentice
Joined: 14 Feb 2009
Posts: 37
|
| The listener was down and when I started and set the MQserver , I was able to you use "amqsputc" . However, by doing this , I am by passing th e the idea of using channel table. When I don't set the MQserver and try to use the channel table to figure out the channel information, I still get the same error. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Apr 18, 2009 12:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Sue_2828 wrote: |
| The listener was down and when I started and set the MQserver , I was able to you use "amqsputc" . However, by doing this , I am by passing th e the idea of using channel table. When I don't set the MQserver and try to use the channel table to figure out the channel information, I still get the same error. |
Read up: client manual and programmer manual +reference  A lot of good information there on the correct use of a client channel definition table (CCDT) Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Sue_2828 |
| Posted: Sat Apr 18, 2009 12:14 am Post subject: |
|
|
Apprentice
Joined: 14 Feb 2009
Posts: 37
|
fjb, I am doing this right now but just not clear about the MQServer variable , If I set it , do I still need to set the mqchllib and mqchltab as well. As I understand , if I set mqchllib and mqchltab then it will figure out the channels it need to use and no need to set the MQserver. Just want someone to clear this point for me plz.  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Apr 18, 2009 12:17 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Sue_2828 wrote: |
| fjb, I am doing this right now but just not clear about the MQServer variable , If I set it , do I still need to set the mqchllib and mqchltab as well. As I understand , if I set mqchllib and mqchltab then it will figure out the channels it need to use and no need to set the MQserver. Just want someone to clear this point for me plz. |
AFAIK setting the MQServer variable will override the channel tab for most non java languages. So no you should not have the MQServer variable set.
Just make sure to KNOW the content of your clientconn chl in the table. The manuals will guide you on how to use it to connect. Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Sat Apr 18, 2009 9:29 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| You can use MO72 to view and modify the contents of the CCDT without a QMGR. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Apr 18, 2009 9:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Using the MQCHLLIB and MQCHLTAB environment variables require that you unset the MQSERVER environment variable.
You will [need] the correct CLNTCONN definitions in the client channel table pointed to by MQCHLLIB and MQCHLTAB.
You will need CHAD enabled on the qmgr that is at the SVRCONN channel.
This is nicely documented in the WMQ Clients manual.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Last edited by bruce2359 on Sat Apr 18, 2009 3:14 pm; edited 1 time in total |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Sat Apr 18, 2009 9:50 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| bruce2359 wrote: |
| You will need CHAD enabled on the qmgr that is at the SVRCONN channel. |
IMHO you should never enable CHAD. That's bad. |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Apr 18, 2009 2:34 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
I have to question why...
| Quote: |
| ...You will need CHAD enabled on the qmgr that is at the SVRCONN channel... |
...as your statement implies that it wont work unless it is set, and I have only ever seen it set ON when needed because of clustering z/OS and distributed queue managers, which were using channel exits.
_________________
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 |
|
|
| bruce2359 |
| Posted: Sat Apr 18, 2009 3:13 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I have to question why... |
The CHAD(ENABLED/DISABLED) turns the facility on or off. If on, then the chad exit attributes take effect.
From the MQSC manual:
CHAD:
Whether receiver and server-connection channels can be defined automatically: DISABLED Auto-definition is not used. This is the queue manager’s initial default value. ENABLED Auto-definition is used. Cluster-sender channels can always be defined automatically, regardless of the setting of this parameter. This parameter is valid only on AIX, HP OpenVMS, HP-UX, Linux, i5/OS, Solaris, and Windows.
| Quote: |
| IMHO you should never enable CHAD. That's bad. |
A more detailed explanation would explain why. Please offer one next time. Like most things in life, CHAD is a choice; and you must live with the consequences of your choices. It's neither good nor bad until you talk about the risks and benefits.
CHAD poses a security risk, which is bad if you didn't know about it, or you didn't take appropriate action to mitigate the security risk. You might be required to enable CHAD to take advantage of its delightful feature of auto-defining SVRCONN or RCVR channel ends - which is good.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| exerk |
| Posted: Sun Apr 19, 2009 1:43 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
| ...You might be required to enable CHAD to take advantage of its delightful feature of auto-defining SVRCONN or RCVR channel ends - which is good... |
Is precisely why I am loathe to use it. It may be a delightful feature, but I prefer to manage the infrastructure and to do that requires a degree of control that auto-definition of non-cluster receivers removes from me.
Question: How do you know the provenance of clients, and prevent them from connecting if they are 'unauthorised'?
_________________
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 |
|
|
| bruce2359 |
| Posted: Sun Apr 19, 2009 7:06 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Channel security exits, CHAD exits and send/receive exits, offer opportunities to validate inbound attach requests, and to validate message flows and content.
If CHADs functionality is more important, I recommend a firewall queue manager to deal solely with CHAD connections. Validated (however it is done) messages can then be passed to the real-business queue manager next door.
I recommend caution (ok, extreme caution) when enabling CHAD. Somewhat less than extreme caution is called for when enabling regular channels: more when the other end is outside the security domain; less when it is within.
SSL helps authenticate channel ends. There are 3rd party offerings that, at the very least, offer the opportunity to have channel ends challenge each other at attach.
When I wear my consultant hat and tie, I don't have the luxury of telling my customer that CHAD bad. I have a responsibility to offer the benefits and risks; and if CHAD is their choice, offer alternative solutions to the risk.
I didn't say CHAD is pretty, did I? It's a choice.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Apr 19, 2009 8:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| I didn't say CHAD is pretty, did I? It's a choice. |
You actually said that it was REQUIRED in this case.
It's not.
And it shouldn't be used. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Apr 19, 2009 4:17 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
So far no one has mentioned looking in the MQ error log on the Client system. It contains more diagnostics about 2059 reason codes. On Unix its /var/mqm/errors/AMQERR01.LOG, on Windows its C:\Program Files\IBM\WebSphere MQ\errors\AMQERR01.LOG.
_________________
Glenn |
|
| Back to top |
|
|
|
|
