| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Using the C# code sample remotely |
« View previous topic :: View next topic » |
| Author |
Message
|
| fishlips |
 Posted: Wed Jan 04, 2012 4:50 am Post subject: |
 |
|
Apprentice
Joined: 21 Dec 2011
Posts: 36
|
| zpat wrote: |
| If by client, you mean MQ client - these don't hold queues. |
Yes, I see that now. So, to start afresh, I have a machine, where I can ping the MQ server by IP address. The MQ Server has a running Server-connection channel, and I wish to use this to connect to the queue manager TAS_AMC1, connect to the queue AMC_EGW1 and read message in the queue.
If I run amcqsgetc, I get this error:
| Code: |
Sample AMQSGET0 start
MQCONN ended with reason code 2058 |
The error I see suggests that the specified queue manager name is incorrect, but I know for a fact that TAS_AMC1 is the name of the queue manager.
Maybe I'm going about this all wrong, if I want, as an client application, to connect to a queue manager and read messages from a queue (via the Server Connection Channel), how do I go about it? |
|
| Back to top |
|
 |
| fishlips |
| Posted: Wed Jan 04, 2012 4:54 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2011
Posts: 36
|
I should probably also mention that, the guide states:
| Quote: |
| For any exchange of information to take place, there must be a program on the server machine whose role is to ‘listen’ on the communications line for any activity. If there is no program doing this, or there is one but it is not configured correctly, the MQCONN or MQCONNX call fails, and the relevant reason code is returned to the WebSphere MQ client application |
I can confirm that a TCP listener has been defined, and is running. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jan 04, 2012 4:56 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| fishlips wrote: |
| Hi Exerk, sorry for any confusion, I definitely mean client applications, as apposed to client queue managers. |
Thank you for the clarification and apologies if I seemed pedantic - but perhaps you can understand why?
| fishlips wrote: |
| Currently, we have two channels set up which both have SVRCONN in the name. One, which already existed before today, is of channel type "Server-connection", and is running. |
Which may show your client application is connected and functional, but may be your MQ Explorer session for all we know.
| fishlips wrote: |
| The other, is the sender channel that I set up earlier today, which I named "REMOTE.SVRCONN". I'm guessing that I don't need this one. |
Don't guess 
| fishlips wrote: |
| Quote: |
| as you have found the PUT sample, go seek and find the GET sample |
Ok, well this is interesting, if I run
| Code: |
| amqsget AMC_EGW1 TAS_AMC1 |
i get this error:
| Code: |
| This application has failed to start because MQM.dll was not found. Re-installing the application may fix this problem. |
If I run
| Code: |
| amqsgetc AMC_EGW1 TAS_AMC1 |
I get this error:
| Code: |
Sample AMQSGET0 start
MQCONN ended with reason code 2058 |
|
I should have been more specific and stated the client GET sample 
| fishlips wrote: |
| So, to clarify, we do have a Server-Connection channel set up, and it is running. Is there something else I need to do, in order to allow my client application to connect? |
Not on the face of it, no - provided your client application is using the channel you have stated is running (one way to be sure is to check the status of that channel and see what application is using it). Better to define a separate SVRCONN for the client and for the client to use that channel.
Search this site for information in regard to CCDT files, and read the Clients manual, and Intercommunication manual for the exact detail.
_________________
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 |
|
|
| fishlips |
| Posted: Wed Jan 04, 2012 6:29 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2011
Posts: 36
|
| exerk wrote: |
| I should have been more specific and stated the client GET sample |
I'm sorry, but you've lost me now. The only samples I can see, under IBM\WebSphere MQ\tools\dotnet\samples\bin\, are
- SampleConfigCS.exe
- SampleConsumerCS.exe
- SampleProducerCS.exe
Isn't SampleConsumerCS.exe the client GET sample ? Sorry if I'm missing the obvious. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 04, 2012 6:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fishlips wrote: |
| Sorry if I'm missing the obvious. |
I believe my most worthy associate was refering to your use of the amqsputc sampile to test your configuration. As indicated in
Am I barking up the wrong tree by using amqsputc to verify my set up?
| fishlips wrote: |
| I ask, because amqsputc seems to imply that I'm trying to put a message on a queue. This isn't what I'm trying to do. All I need to do is read messages from a queue. |
You're quite correct, that sample does put to a queue. It's the other sample that gets from one.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fishlips |
| Posted: Wed Jan 04, 2012 6:33 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2011
Posts: 36
|
| exerk wrote: |
| fishlips wrote: |
| Currently, we have two channels set up which both have SVRCONN in the name. One, which already existed before today, is of channel type "Server-connection", and is running. |
Which may show your client application is connected and functional, but may be your MQ Explorer session for all we know. |
[/quote]
You're right about this, I've closed my client, and gone onto the server, and the status is now Inactive rather than running. Is this good / bad ? |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jan 04, 2012 6:35 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| fishlips wrote: |
| exerk wrote: |
| fishlips wrote: |
| Currently, we have two channels set up which both have SVRCONN in the name. One, which already existed before today, is of channel type "Server-connection", and is running. |
Which may show your client application is connected and functional, but may be your MQ Explorer session for all we know. |
You're right about this, I've closed my client, and gone onto the server, and the status is now Inactive rather than running. Is this good / bad ? |
SVRCONNs are only active during the time the client application is using it.
_________________
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 |
|
|
| fishlips |
| Posted: Wed Jan 04, 2012 6:37 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2011
Posts: 36
|
| Vitor wrote: |
| You're quite correct, that sample does put to a queue. It's the other sample that gets from one. |
Ok, well I'm already there with that one, I've tried amcqsgetc, as stated here:
| fishlips wrote: |
If I run amcqsgetc, I get this error:
| Code: |
Sample AMQSGET0 start
MQCONN ended with reason code 2058 |
The error I see suggests that the specified queue manager name is incorrect, but I know for a fact that TAS_AMC1 is the name of the queue manager. |
So my next question is, why does amcqsgetc fail with an "incorrect queue manager name" error. I know the obvious answer is that I've specified the queue manager name incorrectly, but I'm 100% certain that
| Quote: |
| TAS_AMC1 is the name of the queue manager. |
BTW, if I haven't already said it, thank you very much for your assistance so far. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 04, 2012 6:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fishlips wrote: |
| I know for a fact that TAS_AMC1 is the name of the queue manager. |
And the 2058 means I know for a fact that the name of the queue manager amqsgetc finds when it uses your client configuration isn't that name. So you've specified TAS_AMC1 as the name to the code, the code is expecting to find that queue manager, doesn't find it and throws a 2058 because it wants TAS_AMC1.
So either you're pointing at a different queue manager or no queue manager.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 04, 2012 6:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
To summarize this increasingly unwieldy thread:
- you need a channel of type SVRCONN. It can be called FLOPSY_THE_CALICO_BUNNY for all the difference it makes but <something descriptive>.SVRCONN is more traditional.
- you need a client configuration that points to that SVRCONN & identifies the network location it can be found at
- this configuration must be available to the client application (e.g. environment variables in scope for the shell)
This is all in the documentation.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fishlips |
| Posted: Wed Jan 04, 2012 7:09 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2011
Posts: 36
|
| Vitor wrote: |
- you need a channel of type SVRCONN. It can be called FLOPSY_THE_CALICO_BUNNY for all the difference it makes but <something descriptive>.SVRCONN is more traditional.
|
Ok, well I've definitely got this. It's called AMC.SVRCONN, and appears as running when I connect remotely via MQ Explorer. When I connect on the MQ server itself, it does not show as running, which correlates with what you explained earlier, so this appears to be ok.
| Vitor wrote: |
- you need a client configuration that points to that SVRCONN & identifies the network location it can be found at
- this configuration must be available to the client application (e.g. environment variables in scope for the shell)
|
I don't think I have either of these two aspects. I have found the client configuration file in C:\Program Files\IBM\WebSphere MQ\, but I suspect I need to add more to it, this is what it currently looks like:
| Code: |
#* Module name : mqclient.ini *#
#* Type : WebSphere MQ client configuration file *#
#* Function : Define the client configuration *#
#* *#
#****************************************************************************************#
TCP:
# KeepAlive=Yes
ClientExitPath:
ExitsDefaultPath=C:\Program Files\IBM\WebSphere MQ\exits
ExitsDefaultPath64=C:\Program Files\IBM\WebSphere MQ\exits64
|
I don't really know, but would I be right to think that I need to complete the TCP STANZA section of the config file, seeing as I'm intending to connect to the MQ Server via the TCP/IP protocol? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 04, 2012 7:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fishlips wrote: |
| I don't really know, but would I be right to think that I need to complete the TCP STANZA section of the config file, seeing as I'm intending to connect to the MQ Server via the TCP/IP protocol? |
No you wouldn't. Selecting likely looking sections of the documentation is likely to lead to disaster. Given that you've "got" that you need a SVRCONN channel and you want your code to use it, I'd suggest that the Using Channels section slightly above it would be a better source of information. My most worthy associate warned you earlier about guessing.
The ini file you've somehow found is the configuration for your client installation, not the configuration for your application.
Also, if you don't really know, why are you attempting this? Why not take a step back, read the documentation, get some training / mentoring and then crack on? You've seen how far we've got down this thread and still haven't established a connection. Imagine how long drawn out and painful this is going to get once you've got a connection & start actually using the queue manager. This is not a straightforward piece of software to use.
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Wed Jan 04, 2012 7:26 am; edited 1 time in total |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Wed Jan 04, 2012 7:26 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
|
| Back to top |
|
|
| fishlips |
| Posted: Wed Jan 04, 2012 7:56 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2011
Posts: 36
|
| Vitor wrote: |
| The ini file you've somehow found is the configuration for your client installation, not the configuration for your application. |
Ok, I'm with you now. As it happens, I do have a config file for the application that I plan to write, it looks like this:
| Code: |
connection type: wmq
connection mode: client
queue manager: TAS_AMC1
hostname: 192.168.59.221
destination URI: queue:///AMC_EGW1
|
This is based upon my successful use of the C# sample application on the MQ Server.
I'm concerned at this point, that I haven't explained what's been asked of me, so let me explain as clearly & concisely as I can....Our customer is intending to send data to us via MQ. We have successfully configured a sender channel, and they are able to connect to it and send a message to our local queue.
I have been tasked with writing some code, in .NET, which will establish a remote connection to the Queue Manager, connect to a specified queue, read the messages delivered by our customer, and write the content into flat files. The C# sample provided with MQ, SampleConsumerCS.exe, clearly appears to do this, but I can only get it to work on the MQ Server, not from another machine.
What I find odd, is that it wasn't particularly difficult to establish a remote connection to the Queue Manager using the IBM Websphere MQ Explorer client using the info I've been given; why is it so difficult to connect using amcqsgetc or the .NET application? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 04, 2012 8:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fishlips wrote: |
| As it happens, I do have a config file for the application that I plan to write |
That's very nice. Once you've written it you can write the code to convert it into terms that WMQ can understand. WMQ is specific on how the client side is configured and you must use one of the methods specified in the .NET manual.
| fishlips wrote: |
| What I find odd, is that it wasn't particularly difficult to establish a remote connection to the Queue Manager using the IBM Websphere MQ Explorer client using the info I've been given; why is it so difficult to connect using amcqsgetc or the .NET application? |
Because the MQExplorer is (unsurprisingly) correctly coded to establish a client connection; as I indicated above there are specific needs and is using a SVRCONN channel defined automatically (and correctly) by the queue manager creation process.
Do not attempt to piggy back off the MQExplorer connection. It will work (probably) but will lead to major problems later.
The other answer is it's not difficult but has to be done in a specific way. The amqsgetc / amqsputc samples contain the correct code so your problems are with your configuration. You can't short cut this. Work through the documentation, don't guess at the steps or set up what you think you need.
As I said earlier, this is not a simple product and this is still the easy bit.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
