| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| amqsputc fails |
« View previous topic :: View next topic » |
| Author |
Message
|
| PaulClarke |
 Posted: Mon Dec 08, 2014 1:20 am Post subject: |
 |
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Inforz,
It always amuses me when you see someone go to the time and trouble to raise a question on this forum and explain the problem they are having. Then, when the subject matter experts go to the time and trouble of suggesting a solution the answers are largley ignored. Curious.
Let me explain my solution in a different way. If you have an application that tries to connect to QM1 as in your example. eg. amqsputc LQ QM1
but the channel resolves to a different QM. eg. QM2 then you will get a failure. If you really want to connect to a QM that has a different name than the one specified on the MQCONN verb then you would need to specify amqsputc LQ *QM1. However, this would be a crazy thing to do. Channels should refer to the QMs they are going to etc not the QM they were defined on, that is largely irrelevant.
Having said that I have re-read your note and something needs clarifying. You say that you have "unset/nullified MQSERVER and MQCLNTCF vairables(by setting them to '') "
which is it? There is a world of difference between an environment variable not being define and it being defined as ''. You need to make sure that the variable is not defined at all. Setting it to an empty string is still regarded as 'defined' by MQ.
Regard,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
 |
| Inforz |
| Posted: Mon Dec 08, 2014 1:57 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2011
Posts: 139
Location: Chennai, India
|
I tried with amqsputc LQ QM1 and amqsputc LQ *QM1 and both resulted in a mqrc 2058.
I have assigned the variables MQSERVER and MQCLNTCF to ''. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Dec 08, 2014 2:08 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Inforz wrote: |
I tried with amqsputc LQ QM1 and amqsputc LQ *QM1 and both resulted in a mqrc 2058.
I have assigned the variables MQSERVER and MQCLNTCF to ''. |
export MQSERVER=' ' is different to export MQSERVER= is different to unset MQSERVER
_________________
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 |
|
|
| PaulClarke |
| Posted: Mon Dec 08, 2014 2:44 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Inforz,
Let me re-iterate what I said in my previous note. If you do not pay attention to the replies that people give you they will stop replying. I think I a more or less at that point now.
Read and then re-read the responses you get. If you don't understand the response then say so but don't just dismiss the replies offhand.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Dec 08, 2014 7:06 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Inforz wrote: |
| bruce2359, but what does the texts "QM3" imply in the graphic. |
QM3 is the name of the queue-manager on HOST1. On QM3, there is an SVRCONN channel called CCC3. I presume that QM3 has a listener running, but that is not depicted on the graphic.
HOST2 in the graphic is another o/s instance with MQ client software installed. HOST2 has a client channel table (CCDT) with a CLNTCONN channel with the same name as the SVRCONN on QM3 queue-manager. NOTE that a CCDT is just a small table, and not a queue-manager. If the environment variables are set correctly, when APPL1 on HOST2 MQCONNects, the MQ client software will search the CCDT, and try to reach across the network to the SVRCONN on QM3 on HOST1.
| Inforz wrote: |
Its confusing now.
fjbsaper, I am just using the idea on the graphic but my requirement is to achieve on the same host. |
If you have bound APPL1 with client-bindings (amqsputc is the client-bindings version of amqsput), and you have set the environment variables correctly, and the CCDT contains a correct CLNTCONN definition, and a correct SVRCONN channel exists on QM3, then APPL1 will work.
| Inforz wrote: |
As of now, to try the basic test, I am just creating svrconn,clntconn pair for QM1, copy its CCDT file and place in say /tmp/ccdt and referring it to MQCHLLIB. MQSERVER and MQCLNTCF are null. And still I get 2058 for amqsputc LQ QM1
(lstr running for QM1)
 |
In your future posts, please include (copy/paste) your complete DEFinitions here so we may see exactly what you have defined, and where you have defined them. Also, copy/paste your environment variables, and your complete execution of the sample program.
You might want to first try only the MQSERVER= method as proof-of-concept; then, if successful, move on the the CCDT.
_________________
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 |
|
|
| Inforz |
| Posted: Tue Dec 09, 2014 2:33 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2011
Posts: 139
Location: Chennai, India
|
| exerk wrote: |
| Inforz wrote: |
I tried with amqsputc LQ QM1 and amqsputc LQ *QM1 and both resulted in a mqrc 2058.
I have assigned the variables MQSERVER and MQCLNTCF to ''. |
export MQSERVER=' ' is different to export MQSERVER= is different to unset MQSERVER |
Yes Agreed and no way I have conflicts. Please let me know which one is the correct way for the problem I face or atleast the one for me to try.
I tried both the cases and neither was the solution. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Dec 09, 2014 2:39 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Inforz wrote: |
| exerk wrote: |
| Inforz wrote: |
I tried with amqsputc LQ QM1 and amqsputc LQ *QM1 and both resulted in a mqrc 2058.
I have assigned the variables MQSERVER and MQCLNTCF to ''. |
export MQSERVER=' ' is different to export MQSERVER= is different to unset MQSERVER |
Yes Agreed and no way I have conflicts. Please let me know which one is the correct way for the problem I face or atleast the one for me to try.
I tried both the cases and neither was the solution. |
Did you, after un-setting and exporting the variables you think you have un-set/exported, check the values of all the variables you think you un-set/exported?
_________________
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 |
|
|
| Inforz |
| Posted: Tue Dec 09, 2014 2:49 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2011
Posts: 139
Location: Chennai, India
|
| bruce2359 wrote: |
| Inforz wrote: |
| bruce2359, but what does the texts "QM3" imply in the graphic. |
QM3 is the name of the queue-manager on HOST1. On QM3, there is an SVRCONN channel called CCC3. I presume that QM3 has a listener running, but that is not depicted on the graphic.
HOST2 in the graphic is another o/s instance with MQ client software installed. HOST2 has a client channel table (CCDT) with a CLNTCONN channel with the same name as the SVRCONN on QM3 queue-manager. NOTE that a CCDT is just a small table, and not a queue-manager. If the environment variables are set correctly, when APPL1 on HOST2 MQCONNects, the MQ client software will search the CCDT, and try to reach across the network to the SVRCONN on QM3 on HOST1.
| Inforz wrote: |
Its confusing now.
fjbsaper, I am just using the idea on the graphic but my requirement is to achieve on the same host. |
If you have bound APPL1 with client-bindings (amqsputc is the client-bindings version of amqsput), and you have set the environment variables correctly, and the CCDT contains a correct CLNTCONN definition, and a correct SVRCONN channel exists on QM3, then APPL1 will work.
| Inforz wrote: |
As of now, to try the basic test, I am just creating svrconn,clntconn pair for QM1, copy its CCDT file and place in say /tmp/ccdt and referring it to MQCHLLIB. MQSERVER and MQCLNTCF are null. And still I get 2058 for amqsputc LQ QM1
(lstr running for QM1)
|
In your future posts, please include (copy/paste) your complete DEFinitions here so we may see exactly what you have defined, and where you have defined them. Also, copy/paste your environment variables, and your complete execution of the sample program.
You might want to first try only the MQSERVER= method as proof-of-concept; then, if successful, move on the the CCDT. |
Thanks Bruce. I tried //MQSERVER=// and yet it didn't worked.
Finally I understood that changes to clntconn channels will not get reflected to CCDT tab file until the MQCHLLIB variable is null(I would probably say, export MQCHLLIB=, was done, not wanted to move into complexity  ).
After that changes to clntconn are updated to ccdt file and then I could use the file to connect as client. The following link helped on it.
http://www-01.ibm.com/support/docview.wss?uid=swg21460337
Bruce, to make it simple there are two QMs, QM1 and QM2, a clntconn was created in QM2 and corresponding svrconn in QM1. I used the CCDT of QM2 and made a connection to QM1 using a client, amqsputc. It worked now after following the steps in the link above and shall be happy to share definitions if you still need. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 09, 2014 6:18 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Inforz wrote: |
Bruce, to make it simple there are two QMs, QM1 and QM2, a clntconn was created in QM2 and corresponding svrconn in QM1. I used the CCDT of QM2 and made a connection to QM1 using a client, amqsputc.
It worked now after following the steps in the link above and shall be happy to share definitions if you still need. |
For clarity and precision, an MQ Client connection does NOT connect one qmgr to another qmgr.
Thus, you have NOT connected two qmgrs (QM1 and QM2 together. Rather, you have connected an application (amqsputc) to a qmgr.
If that application happens to exist on a platform that also has a qmgr, you still have NOT connected two qmgrs together.
_________________
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 |
|
|
| smdavies99 |
| Posted: Tue Dec 09, 2014 6:26 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| bruce2359 wrote: |
Thus, you have NOT connected two qmgrs (QM1 and QM2 together. Rather, you have connected an application (amqsputc) to a qmgr.
|
Which is exactly what I said in the first reply to the original post. Others have said exactly the same but the Poster seems to choose to ignore how MQ connects Queue Managers together.
_________________
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 |
|
|
| bruce2359 |
| Posted: Tue Dec 09, 2014 9:47 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
I find that developers and sysadmins new to MQ often believe that MQ applications run (execute) inside a queue-manager. Not so.
MQ applications execute in an o/s address-space different from that of the queue-manager. MQI calls (MQCONN, MQOPEN, etc.) issued by applications are sent to the queue-manager either cross-memory (server-bindings) or cross-network (client-bindings).
Apparently, the OP believes that his/her MQ client-bindings application is connecting two queue-managers. This is not the case.
_________________
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: Tue Dec 09, 2014 9:58 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| MQ applications execute in an o/s address-space different from that of the queue-manager. MQI calls (MQCONN, MQOPEN, etc.) issued by applications are sent to the queue-manager either cross-memory (server-bindings) or cross-network (client-bindings). |
Or in-memory(fastpath/trusted bindings). |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 09, 2014 10:43 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
| bruce2359 wrote: |
| MQ applications execute in an o/s address-space different from that of the queue-manager. MQI calls (MQCONN, MQOPEN, etc.) issued by applications are sent to the queue-manager either cross-memory (server-bindings) or cross-network (client-bindings). |
Or in-memory(fastpath/trusted bindings). |
Specifying fastpath-bindings in the CNO is not going to fix the OP's issue or misconception.
_________________
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 |
|
|
| tczielke |
| Posted: Tue Dec 09, 2014 11:09 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| bruce2359 wrote: |
MQ applications execute in an o/s address-space different from that of the queue-manager. MQI calls (MQCONN, MQOPEN, etc.) issued by applications are sent to the queue-manager either cross-memory (server-bindings) or cross-network (client-bindings).
|
When I hear the term "cross-memory", it makes me think of CMS or Cross-Memory Services on the z/OS architecture. I have never personally seen a distributed operating system and hardware environment that is sophisticated enough to support something like CMS. On distributed environments, they are usually using something less sophisticated like shared memory to allow two processes (or address spaces) like an application process and the queue manager agent process to pass data. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 09, 2014 1:12 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
Cross-memory services in z/OS usually means calling for services provided in another address-space - either through CSA (Common Service Area) and SCHEDule macro, or through a PC (Program Call) hardware instruction.
In MQ-speak, server- (or local) bindings means that the MQI calls are passed in a memory buffer as opposed to the MQClient-bindings via a network method.
May I take this opportunity to ask that we specify which -bindings mode: client-bindings or server-bindings.
Far too much MQ doc merely refers to "bindings mode." Since most (skipping Java) applications must be bound (link-edited, for mainframers) into an executable, "bindings mode" is not precise. "Server" and "Client" are each 6 characters. Surely we can type 6 more characters... ok, 7, if you count the dash.
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
